RFC 2847状态
公开引用的 SMTP 服务器不得要求使用 STARTTLS 扩展来本地传递邮件。此规则可防止 STARTTLS 扩展破坏 Internet SMTP 基础架构的互操作性。公开引用的 SMTP 服务器是在 Internet 邮件地址右侧域名的 MX 记录（或 A 记录，如果不存在 MX 记录）中列出的 Internet 主机的端口 25 上运行的 SMTP 服务器。
因此，为了符合 RFC，我必须允许另一个代理可能尝试在不使用 TLS 的情况下连接到我的电子邮件服务器，然后以纯文本形式发送密码，对吗？
如果我违反此规则并只允许加密电子邮件连接（即在端口 454、993 和 995 上，但不允许其他端口），其他电子邮件服务通常可以发送到我的服务器吗？
答案1
您可以配置您的服务器，使其通过不同的端口 (587) 接受来自用户的外发电子邮件，并且仅允许在该端口使用 TLS。在标准端口 25 上，阻止任何类型的用户登录，这样就不会有人意外使用该端口并以明文形式发送密码。
据我所知，这并没有破坏 RFC，因为它讨论了其他服务器与您的服务器通信，以便向您的用户发送电子邮件。在面向用户的方面，您实际上不受任何 RFC 的约束，并且可以自由地执行您希望的任何策略，例如执行 TLS，因为它在所有主要客户端上都受支持。
答案2
为了获得最佳兼容性，您应该允许一般邮件进行未加密的连接，因为有些客户端不支持STARTTLS。
对于用户的邮件客户端（发送密码的地方），您应该要求尽可能最好的加密。
答案3
如果我违反此规则并只允许加密电子邮件连接（即在端口 454、993 和 995 上，但不允许其他端口），其他电子邮件服务通常可以发送到我的服务器吗？
不会。邮件服务器之间的邮件传递是通过查找负责收件人域的邮件服务器来完成的，使用 DNS 查找 MX 记录。此记录包含主机名，然后会在端口 25 处联系此主机。无法以某种方式配置不同的端口，即如果端口 25 上没有服务器，则传递将失败。
答案4
有两件事需要区分：
- MTA（邮件传输代理），将电子邮件从发件人转发到收件人，通常使用 TCP 端口 25、465 和 587
- MDA（邮件投递代理），允许用户下载/同步他们的电子邮件，通常使用 TCP 端口 110 和 995（用于 POP3(S)）以及 143 和 993（用于 IMAP(S)）
RFC 讨论了A publicly-referenced SMTP server，意思是 MTA。
MTA 通常会监听 3 个不同的 TCP 端口以进行 SMTP(S)：
- 二十五：可以支持 STARTTLS 的普通 SMTP，并且这是用于将电子邮件从一个 MTA 传递到另一个 MTA 的唯一端口
- 465：SMTP over TLS，供用户发送电子邮件
- 587：支持 STARTTLS 的普通 SMTP，可供用户发送电子邮件
对于 STARTTLS，如果我们以 Postfix 为例，您可以有 3 种不同的配置：
- 没有任何：服务器不会使用 STARTTLS
- 可能：服务器将建议并使用机会加密（STARTTLS）（如果可用）
- 加密：如果无法使用 STARTTLS，服务器将断开连接
现在真正的问题是：目前太多的 MTA 配置不当并且不支持 STARTTLS，这意味着在您的服务器上要求它可能会导致您的某些电子邮件无法送达，或者您的服务器将无法接收使用不支持 STARTTLS 的 MTA 的发件人的电子邮件。
为了加速这一进程，谷歌在其透明度报告显示传输过程中被加密的电子邮件百分比。他们甚至更进一步，现在当未加密时会显示红色挂锁。
但是，太多服务器仍然不支持 STARTTLS，这意味着您可能会在端口 25 上要求它时遇到太多问题。因此，我可以为您的配置提供以下建议：
- SMTP 端口 25：“可能”，既作为客户端，又作为服务器
- SMTPS 端口 465：为您的用户开放
- SMTP 端口 587：其实不需要
- POP3 端口 110：其实不需要
- POP3S 端口 995：为您的用户开放
- IMAP 端口 143：其实不需要
- IMAPS 端口 993：为您的用户开放