邮件服务器之间使用的端口 25 是否使用 SSL/TLS 进行保护？

Question

MTA 使用的端口 25(smtp) 是否在纯文本/非加密下工作？

我找不到任何默认情况下使用 25 声明 smtp 是纯文本的资源。

（见代码部分S: <waits for connection on TCP port 25>...）

, 看来 25(smtp) 端口支持 STARTTLS，所以这是否表明

Answer 1

几个月后，我阅读了更多材料和一些 RFC，但我不同意 @Overmind 的一些答案。

Opportunistic_TLS或STARTTLS，我认为它们指的是一件事。也就是说，如果服务器支持 TLS 连接，那么客户端会更喜欢使用 TLS 连接，否则，客户端可以使用纯文本连接。

MTA 使用的端口 25 可能支持也可能不支持。这完全取决于邮件服务器。（如果服务器支持 TLS，您可以STARTTLS在telnet和之后看到选项EHLO。）

如果服务器 MTAa支持TLS，并且客户端 MTAb要求 TLS 连接，则将建立 TLS 连接。
如果服务器 MTAa不支持TLS，则b可以将客户端 MTA配置为继续以纯文本形式交谈或中止传送。（例如，MTA 软件Postfix似乎支持此类设置，并且可以将其设置为仅针对某些用户指定的域请求 TLS 连接。）

引入端口587最初是为了将25MUA（终端用户邮件客户端，例如 ThunderBird）中的端口替换为 MTA 邮件提交。它以Opportunistic_TLS方式设计。如果服务器支持TLS，请进来谈谈TLS。如果没有，那么我可以使用纯文本。

如您所见，Opportunistic_TLS或STARTTLS只是一种机制。此模式可用于MTAto MTA、MUAtoMTA或任何其他通信。它与协议无关。

而且我认为默认提交端口不应该587像@Overmind 所说的那样。邮件提交应该强制执行 TLS而不是Opportunistic_TLS。 强制 TLS是：如果服务器不支持TLS连接，那么客户端将不会与服务器通信。端口465用于强制执行 TLS要求。

所以在你的邮件客户端中，你应该总是使用465邮件提交。

这确实是有效的答案。关于端口 587 与 465，大多数可用资源都已过时，并且会错误地建议不要在 465 上使用强制/隐式 TLS，而是在 587 上使用机会/显式 (START)TLS。截至 2020 年，这不是最佳实践（长话短说：如果客户端和服务器端均未正确配置，STARTTLS 很容易受到中间人攻击，而隐式 TLS 在设计上是安全的。请在 https://tools.ietf.org/html/rfc8314 查看 RFC 8314（尚未验证，但正在路上），了解有关使用 TLS 以安全方式交换邮件的最新见解。 (4认同)