为什么 SMTP 中端口 587 比端口 465 更受青睐？

Question

我最近一直在开发一个通过 SMTP 服务器发送电子邮件的 C# 客户端。但是，我一直搞不清楚不同术语的含义，例如：STARTTLS/TLS/SSL... 脱离上下文，我隐约知道它们的含义，但对于电子邮件，我完全没有头绪。

经过进一步调查，我发现 SMTP 客户端以两种不同的方式（两种加密方式）与服务器通信；显式 SSL/TLS 和隐式 SSL/TLS。

据我所知，显式 SSL/TLS 就是 STARTTLS 的工作方式，它会在不安全的连接上询问服务器是否支持 TLS，如果支持，则继续使用加密连接。然而，隐式 TLS 从连接开始到结束都是安全的，它永远不会不安全。

我可能错了，如果错了，请纠正我。

问题是为什么端口 587（显式 SSL/TLS）比端口 465（隐式 SSL/TLS）更受欢迎。

我知道端口 465 已被弃用，但我可以看到端口 587 的用处，它既可以加密也可以不加密，并且由客户端来找出服务器支持什么。

但我很少看到有利于易用性的安全更新，这就是我感到困惑的原因。为什么我们要从完全安全变为部分安全？

我希望我的问题有意义。

Answer 1

为什么首选 587 端口？

任何声称如此的文件都是历史性的。今天，首选端口 465。

它曾经被偏爱的原因（部分运营商，并非所有运营商）是：

• 在 STARTTLS 正式化之后，兼容性和安全性考虑有所不同
• 已重新分配合适且已使用的 TCP 端口号IANA

我们现在都应该选择隐式 TLS 的原因是：

• 在原本强大的安全机制上添加不必要的变通方法和兼容层被认为是不可取的
• 一个备用端口使用 已分配解决端口冲突
• 我们现在几乎没有什么用例可以提供选修的运输安全

每个人建议迁移到隐式 TLS。请仅使用安全传输发送邮件。请阻止或删除不必要的复杂性和故障模式。

Answer 2

目前情况正好相反。关于为什么，RFC 8314，3理由如下：

虽然已经部署了此 [ STARTTLS] 机制，但在单独端口上启动连接时立即协商 TLS 的替代机制（在本文档中称为“隐式 TLS”）已更成功地部署。为了鼓励更广泛地使用 TLS，并鼓励在 TLS 的使用方式上更加一致，此规范现在建议对 POP、IMAP、SMTP 提交以及 MUA 和 MSP 之间使用的所有其他协议使用隐式 TLS。

Answer 3

SMTP 使用端口 25 进行服务器到服务器的通信，使用端口 587 进行客户端到服务器的通信。

这里的协议没有真正的区别，但较大站点的管理员可能希望对接收来自其他域的邮件和接收可能发往其他域的自己的客户的邮件采用不同的策略，这就是为什么存在两个不同的端口：它允许防火墙规则轻松区分。

接收邮件的邮件服务器永远不需要验证用户的凭证，因此他们不需要被授予访问该数据库的权限，而发送邮件的邮件服务器需要验证本地用户，因此他们做需要这种访问权限——但无需从世界各地都能访问到。

端口 465 是端口 25 的 SSL 专用变体，但已经可以通过STARTTLS对命令的响应协商的机会加密很好地处理EHLO，并且该STARTTLS命令比首先尝试端口 465、遇到超时然后再尝试端口 25 更快。

端口 587 从未分配仅 SSL 变体端口，并且其用例仍然相关。

服务器到服务器的传输使用机会加密，如果失败则可能回退到未加密传输——通过加密邮件本身来提供端到端安全性，因为即使服务器之间有加密连接，邮件也会在每台服务器上进行处理。

客户端应该使用端口 587，协商加密，并制定合理的策略来确定协商失败时该做什么，例如，可以继续使用质询-响应身份验证方法并传输未加密的邮件，而如果没有下面的加密层，密码身份验证方案将变得不安全。