电子邮件传输示例

Question

RFC 标准从字面上强迫我们接受端口上的未加密连接25。要了解原因，我们必须了解电子邮件的工作原理。但是电子邮件是一个相当复杂的话题，我创建了这个例子和一个表格来尝试理解一切。

任何人都可以阅读并告诉我解释的任何部分是否有误？因为我不太确定我对这个话题的理解是否正确。

---

例子

当用户（发件人）通过“邮件用户代理” （MUA ）发送电子邮件时，该电子邮件会立即转移到位于或不在单独机器上的“邮件提交代理”（MSA）。MSA 预处理电子邮件并将其交给同一台机器上的“邮件传输代理” (MTA)。MTA（发件人）然后使用 DNS 并确定应将电子邮件发送到哪个 MTA（收件人）。这部分传输仅通过 port 完成25。当 MTA（接收者）收到电子邮件时，它会将它处理到同一台机器上的 MSA，然后用户（接收者）可以使用 MUA 阅读电子邮件。

MUA & MSA 和 MSA & MTA 之间的通信可以使用安全端口，但 MTA 和 MTA 之间的连接不能。下表显示了使用或可以使用哪些协议以及可以为上述示例的每个步骤使用哪些端口。我们也使用 ? 和 ？可以选择指示现代设置应该使用什么。

#	发件人	接收者	我们可以使用的协议	各个协议的端口
1	通用汽车协会	海事局	(?) SMTP (?) SMTPS	(?) 25 (?)587
2	海事局	MTA	(?) SMTP (?) SMTPS	(?) 25 (?)587
3	MTA	MTA	(?) SMTP	(?) 25
4	MTA	海事局	(?) SMTP	(?) 25
5	海事局	通用汽车协会	(?) POP3 (?) POP3S (?) IMAP (?) IMAPS	(?) 110 (?) 995 (?) 143 (?)993

Answer 1

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

端口不表示加密，而是用于不同目的：

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

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

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

（下图CC BY-SA 3.0从Ale2006-从烯在维基百科消息提交代理）示出了不同的服务器角色，和蓝色箭头可以由不同的SMTP变化来实现。另请注意，同一服务器在传递消息时可以具有多个角色。

要增强您的桌子：

#	发件人	接收者	使用的协议和端口
1	通用汽车协会	海事局	(?)587使用STARTTLS (?) SMTPS465与隐式 TLS提交
2	海事局	MTA	内部交付（同一个服务器有两个角色）
3...	MTA	MTA（可能是MX）	(??) 未加密的 SMTP 25 (?) SMTP 25with STARTTLS (?) SMTP 25，STARTTLS使用 DANE 强制执行
N-1	MX	MDA?MS	内部交付（具有多个角色的同一服务器）
N	多发性硬化症	通用汽车协会	(?) IMAP143与STARTTLS (?) IMAPS993与隐式 TLS

最后两个步骤不能完全被视为发送者和接收者，因为消息用户代理MUA 连接到消息存储MS 并拉取消息而不是推送。最终的 MX MTA 使用称为消息传递代理(MDA)的功能将邮件传递给 MS 。该邮件提交代理（MSA）仅是指发送邮件。有关这些定义的更多详细信息可以在Internet 邮件架构 RFC 5598 中找到。