RFC 标准从字面上强制我们接受端口上的未加密连接25。要了解原因，我们必须了解电子邮件的工作原理。但是电子邮件是一个相当复杂的主题，我创建了这个示例和一个表格来尝试理解所有内容。
任何人都可以阅读并告诉我我在解释的任何部分是否有误吗？因为我不太确定我对这个话题的理解是否正确。
例子
当用户（发件人）通过“邮件用户代理” （MUA）发送电子邮件时，该电子邮件会立即转移到位于或不在单独机器上的“邮件提交代理” （MSA）。MSA 对电子邮件进行预处理并将其交给同一台机器上的“邮件传输代理” (MTA)。然后 MTA（发件人）使用 DNS 并确定应将电子邮件发送到哪个 MTA（收件人）。这部分传输仅通过 port 完成25。当 MTA（接收者）收到电子邮件时，它会将其处理到同一台机器上的 MSA，然后用户（接收者）可以使用 MUA 阅读电子邮件。
MUA & MSA 和 MSA & MTA 之间的通信可以使用安全端口，但 MTA 和 MTA 之间的连接不能。下表显示了使用或可以使用的协议以及上述示例的每个步骤可以使用的端口。我们还使用 ✘ 和 ✔ 来表示现代设置应该使用什么。
| # | 发件人 | 接收者 | 我们可以使用的协议 | 各自协议的端口 |
|---|---|---|---|---|
| 1 | MUA | MSA | (✘) SMTP (✔) SMTPS |
(✘) 25 (✔) 587 |
| 2 | MSA | MTA | (✘) SMTP (✔) SMTPS |
(✘) 25 (✔) 587 |
| 3 | MTA | MTA | (✔) SMTP | (✔)25 |
| 4 | MTA | MSA | (✔) SMTP | (✔)25 |
| 5 | MSA | MUA | (✘) POP3 (✘) POP3S (✘) IMAP (✔) IMAPS |
(✘) 110 (✘) 995 (✘) 143 (✔) 993 |
这是基于一种误解，即端口与加密有任何关系。但是，我发现这是一个很好的问题，因为它提供了纠正这种误解的机会。
这些端口不是为了表示加密，而是用于不同的目的：
25用于MTA:s 之间的 SMTP ( RFC 5321 )消息中继。587用于从 MUA 到 MSA的消息提交( RFC 6409 )。STARTTLS（RFC 3207）加密。465。这在 1997 年注册，但在 1998 年STARTTLS被标准化时被撤销。然而，这在 20 年后的 2018 年被逆转，因为RFC 8314现在认为明文已过时，并为 POP、IMAP 和 SMTP 提交带回了隐式 TLS。谷歌透明度报告称，今天的大部分电子邮件在传输过程中（在 MTA 之间）都是加密的。
MTA 之间的通信仍应批准未加密的连接以实现向后兼容性，因此，中间人很容易通过删除
250-STARTTLS表示支持扩展的回复来降级连接。但是，如果发送方支持机会性 DANE ( RFC 7672 ) 并且接收方有TLSA记录表明他们不需要未加密的传递尝试（作为向后兼容性的例外），这种攻击将会失败。下图（维基百科消息提交代理中Ale2006-from-en的CC BY-SA 3.0）显示了不同的服务器角色，蓝色箭头可以通过不同的 SMTP 变体实现。另请注意，同一服务器在传递消息时可以具有多个角色。
要增强您的表：
587使用STARTTLS(✔)
465带有隐式 TLS 的SMTPS 提交25(✘)
25带有STARTTLS(✔) SMTP的 SMTP
25，STARTTLS由 DANE 强制执行143和STARTTLS(✔) IMAPS
993和隐式 TLS最后两个步骤不能完全被视为发送者和接收者，因为消息用户代理MUA 连接到消息存储MS 并拉取消息而不是推送。最终的 MX MTA 使用称为消息传递代理(MDA)的功能将邮件传递给 MS 。消息提交代理( MSA) 仅指发送邮件。有关这些定义的更多详细信息，请参阅Internet Mail Architecture RFC 5598。