只是想指出这一点，因为它似乎已成为一种普遍的误解——587 不是“未来”——而是 465 上的隐式 TLS。
我通过这篇帖子了解到这一[启示]。
在阅读了2018 年的实际 RFC 后，情况很清楚——并不是 STARTTLS 是前进的方向，而是 SMTPS 不是前进的方向，而是在 465 端口（或 587 端口）上的隐式 TLS 是管理员未来应选择的方式。
支持 465 上的 TLS 不应被归类为（甚至可能不被优先考虑）“维护向后兼容性”或任何类似的概念。
端口 587 上的 STARTTLS 机制由于 465 端口的情况（在第 7.3 节讨论）得到了相对广泛的部署。这与 IMAP 和 POP 服务不同，在这些服务中，服务器上隐式 TLS 的部署比 STARTTLS 更广泛。希望随着时间的推移，将 MUA 软件使用的核心协议迁移到隐式 TLS，以保持一致性以及解决附录 A 中讨论的其他原因。然而，为了最大限度地利用加密进行提交，希望在过渡期内支持 STARTTLS 上的消息提交和隐式 TLS 上的消息提交这两种机制。因此，客户端和服务器在此过渡期内应在端口 587 上实现 STARTTLS，并在端口 465 上实现隐式 TLS。 请注意，如果实现正确，并且客户端和服务器都配置为在消息提交前成功协商 TLS，那么端口 587 上的 STARTTLS 和端口 465 上的隐式 TLS 在安全属性上没有显著差异。
过渡不是通过 STARTTLS 在 587 上进行“提交”，而是通过 465 上的隐式 TLS 进行“提交”（而不是现在已弃用的 465 上的 SMTPS）。