# Sending email failed with SMTPS port 465

**URL:** <https://meta.discourse.org/t/sending-email-failed-with-smtps-port-465/65787>\
**Category:** Self-hosting\
**Created:** [2017年七月7日 05:07 UTC](https://meta.discourse.org/t/sending-email-failed-with-smtps-port-465/65787 "2017-07-07T05:07:43Z")\
**Posts on this page:** 1\
**Showing post:** 14

<div class="post-metadata">

**Author:** ![vados](https://avatars.discourse-cdn.com/v4/letter/v/f04885/32.png) [@vados](https://meta.discourse.org/u/vados)\
**Post date:** [2022年十二月4日 04:58 UTC](https://meta.discourse.org/t/sending-email-failed-with-smtps-port-465/65787/14 "2022-12-04T04:58:12Z")

</div>

**只是想指出这一点，因为它似乎已成为一种普遍的误解——587 不是“未来”——而是 465 上的隐式 TLS。**

我通过这篇[帖子](https://linuxguideandhints.com/misc/port465.html)了解到这一[启示]。

在阅读了[2018 年的实际 RFC](https://www.rfc-editor.org/rfc/rfc8314#section-3.3) 后，情况很清楚——并不是 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）。

---

_[View the full topic](https://meta.discourse.org/t/sending-email-failed-with-smtps-port-465/65787)._