电子邮件传输示例

Question

RFC 标准实际上强制我们接受端口上的未加密连接25。要了解原因，我们必须了解电子邮件的工作原理。但电子邮件是一个相当复杂的主题，我创建了这个示例以及一个表格来尝试理解所有内容。

有人能读一下并告诉我我的解释是否有误吗？因为我不太确定我对这个主题的理解是否正确。

---

例子

当用户（发件人）通过“邮件用户代理” （MUA），此电子邮件将立即传送至“邮件提交代理”（MSA）是否在单独的机器上。MSA 预处理电子邮件并将其交给“邮件传输代理”（MTA）在同一台机器上。MTA（发送方）然后使用 DNS 并确定应将电子邮件发送到哪个 MTA（接收方）。传输的这一部分仅通过端口完成25。当 MTA（接收方）收到电子邮件时，它会将其处理到同一台机器上的 MSA，然后用户（接收方）可以使用 MUA 阅读电子邮件。

MUA 与 MSA 以及 MSA 与 MTA 之间的通信可以使用安全端口，但 MTA 与 MTA 之间的连接则不能。下表显示了上述示例的每个步骤中使用或可以使用的协议以及可以使用的端口。我们还使用 ✘ 和 ✔ 来表示现代设置应使用什么。

#	发件人	接收者	我们可以使用的协议	各协议端口
1	移动用户代理	管理咨询委员会	（✘）SMTP （✔）SMTPS	（✘）25 （✔）587
2	管理咨询委员会	大都会运输署	（✘）SMTP （✔）SMTPS	（✘）25 （✔）587
3	大都会运输署	大都会运输署	（✔）SMTP	（✔）25
4	大都会运输署	管理咨询委员会	（✔）SMTP	（✔）25
5	管理咨询委员会	移动用户代理	（✘）POP3 （✘）POP3S （✘）IMAP （✔）IMAPS	（✘）110 （✘）995 （✘）143 （✔）993

Answer 1

这是基于一个误解，即端口与加密有关。但是，我发现这是一个好问题，因为它提供了一个纠正这种误解的机会。

这些端口不是为了指示加密，而是用于不同的目的：

• 端口25用于 SMTP (RFC 5321）消息中继在 MTA:s 之间。
• 端口587用于留言提交（RFC 6409）从 MUA 到 MSA。
• 这两个都可以用STARTTLS（RFC 3207）。
• 此外，还有 SMTPS，它将 SMTP（从 MUA 到 MSA）包装在端口 上的 TLS 内465。该协议于 1997 年注册，但在 1998 年标准化时被撤销STARTTLS。然而，20 年后，即 2018 年，这一协议已被撤销，因为RFC 8314现在认为明文已过时，并带回用于 POP、IMAP 和 SMTP 提交的隐式 TLS。

当今大多数电子邮件在传输过程中（MTA 之间）都经过加密，Google 透明度报告。

MTA 之间的通信仍应批准未加密的连接以实现向后兼容性，因此，中间人很容易通过删除250-STARTTLS表示支持扩展的回复来降低连接级别。但是，如果发送者支持机会主义的丹麦人（RFC 7672) 并且接收方有TLSA记录表明他们不需要未加密的传送尝试（作为向后兼容的例外），则此类攻击将会失败。

下图 (版权声明：从Ale2006-来自-en在维基百科中消息提交代理) 显示了不同的服务器角色，蓝色箭头可以通过不同的 SMTP 变体实现。还请注意，同一台服务器在传递邮件时可以扮演多个角色。

为了增强你的餐桌：

#	发件人	接收者	正在使用的协议和端口
1	移动用户代理	管理咨询委员会	（✘）587使用STARTTLS （✔）465带有隐式 TLS 的SMTPS 提交
2	管理咨询委员会	大都会运输署	内部交付（同一服务器，两种角色）
3...	大都会运输署	MTA（可能墨西哥）	（✘✘）未加密的 SMTP 25 （✘）SMTP25带有STARTTLS （✔）SMTP 25，STARTTLS由 DANE 强制执行
N-1	墨西哥	MDA➔MS	内部交付（同一服务器具有多种角色）
否	多发性硬化症	移动用户代理	（✘）IMAP143带有STARTTLS （✔）IMAPS993带有隐式 TLS

最后两个步骤不能完全视为发送者和接收者，因为消息用户代理MUA 连接到消息存储MS 并拉取消息而不是推送。最终的 MX MTA 使用称为消息传递代理（MDA）。消息提交代理（MSA）仅指发送邮件。有关这些定义的更多详细信息，请参阅互联网邮件体系结构 RFC 5598。