我运行一个由标准 Postfix、SpamAssassin、ClamAV、SPF/DKIM 检查等组成的 MTA。此 MTA 仅用于入站电子邮件，不托管任何帐户，并将通过所述检查的任何邮件转发到共享网络主机。
我知道一些电子邮件服务在尝试将邮件传递到我的服务器时开始尝试在纯文本之前尝试 TLS 连接。
我意识到并非所有服务都支持 TLS，但我想知道它的采用程度如何，以便我可以满足我大脑的强迫症安全方面（是的，我知道 SSL 并不像我们曾经认为的那样安全...）。
Postfix 文档smtpd_tls_security_level声明RFC 2487规定所有公开引用（即 MX）的邮件服务器不强制 TLS：
根据 RFC 2487，这绝不能应用于公共引用的 SMTP 服务器。因此，此选项默认为关闭。
那么：文档（或 15 年前的 RFC）的适用性/相关性如何，我可以安全地在所有入站 SMTP 连接上强制使用 TLS，而不会锁定世界上一半的 ISP？
这是一个非常复杂的问题，因为世界上的邮件提供商并不容易提供有关其邮件服务器的统计数据。
自我诊断
要根据您自己的服务器/域对等方确定您的问题的答案，您可以启用 SSL 日志记录：
这假设您将邮件系统日志消息保存一段时间。如果没有，也许设置一个 syslog 归档策略并编写一个 shell 脚本来总结服务器上的 TLS 使用情况。也许已经有脚本可以做到这一点。
一旦您对所有对等方都支持 TLS 以及您愿意强制执行的密码和协议强度感到满意，那么您就可以做出明智的决定。每个环境都不一样。没有一种答案可以满足您的需求。
我自己的亲身经历
值得一提的是，我自己的个人邮件服务器强制执行 TLS。这具有否定大多数垃圾邮件机器人的有趣副作用，因为它们中的大多数不支持 TLS。（直到那个改变，我一直依赖 S25R 正则表达式方法）
更新
我回答这个问题已经一年了，我收到强制 TLS 的电子邮件的唯一问题是来自 Blizzard 的前端 Web 服务器（家长控制）和 Linode 的管理系统。我与之交互的其他所有人似乎都支持具有强密码的 TLS。
企业环境
在企业环境中，我强烈建议您启用 TLS 日志记录，并在执行 TLS 之前让其运行很长时间。您始终可以对 tls_policy 文件中的特定域名强制实施 TLS。
postfix 站点有一些关于 tls 策略映射使用的很棒的文档。即使 ISP 试图在初始服务器连接中去除 TLS 支持，您至少可以确保提供敏感信息的特定域是加密的。