在开发SMTP客户端时需要考虑哪些RFC？

理论上，注释请求集（RFC）包含开发人员构建SMTP客户端所需的所有信息。然而，要知道哪些RFC需要考虑，哪些RFC可以忽略并不总是容易的

有没有人制定了RFC路线图来指导开发人员完成这项任务？我所说的RFC路线图是指：

• 需要修改的RFC的完整列表 被阅读和理解，以便 开发SMTP客户端
• 指示哪些RFC不再有效 需要考虑，因为它们 已被取代
• 相关RFC的摘要
• 详细说明相关RFC如何 相互关联
• 逻辑顺序的一种表示 阅读并理解相关内容 RFC

---

有一个很好的相关RFC列表。

您应该先阅读RFC 5321，然后是RFC 5322。。。假设您已经知道如何处理DNS查询

---

以前的答案是2821，然后是2822。。。但它似乎已经被更新了

这就是我问这个问题的真正原因。关注一个RFC太容易了，但后来发现它的大部分或全部已经被另一个RFC取代。当SMTP服务器实现RFC时，当然还有延迟问题。由于实施滞后，有时有必要不要忘记旧RFC中包含的内容，即使在标准设置术语中，它们已被取代。好处是这些新RFC澄清了旧语言，并且更加完整。因为您只构建SMTP客户端，而不是垃圾邮件引擎或MTA，所以这应该是您所需要的全部。如果你写的是MTA或垃圾邮件引擎，这会变得更加复杂。虽然许多反垃圾邮件技术都是公开的，但很多都不是。新版本也概述了已经发生的变化以及应该如何适应（如果有的话）。一旦旧的RFC被淘汰，坚持使用新的RFC应该是相当安全的。