我正在运行一个电子邮件服务器，该服务器当前设置为在发送和接收电子邮件时尽可能使用 TLS。
当您阅读有关此内容的文档时，还会发现还有强制执行 TLS 且不接受纯文本电子邮件传输的选项。它还警告您某些邮件服务器可能尚不支持加密，强制加密可能会阻止这些服务器。
但这仍然是一个应该思考的问题吗？或者我们可以肯定地说，强制加密不再是问题吗？
是否可能有一些大型供应商已经在这样做了，或者您认为目前的最佳做法是什么？
答案1
实际问题是，并非每个符合 SMTP 标准（RFC 相当古老）的服务器都可以与您的服务器进行 TLS 通信，因此您可能会错过接收某些电子邮件消息。
这个哲学问题在于，不可能知道电子邮件在到达您的服务器之后（或之前）是如何中继的。
这意味着该电子邮件可能已经通过中继以纯文本形式传输。
任何认真保护电子邮件内容的人都应该加密正文。通过加密，邮件始终可以以纯文本形式传输。
因此，回答您的问题，在 SMTP 层强制加密可能是毫无意义的，会增加您丢失电子邮件的机会，并且不能保证带来有益的回报。
编辑：这指的是为了中继而强制执行 SMTP，不是提交电子邮件。在提交邮件时应强制加密，因为 SMTP 对话（而非实际电子邮件）可能包含身份验证凭据。
答案2
不
RFC 821 已有 33 年历史。您将要查找由不支持 STARTTLS 的程序中继的电子邮件。有时它们将是存根电子邮件发件人（例如内部脚本），有时是功能齐全的旧系统，已禁用/未编译 TLS，系统没有足够的熵……
不久前，我目睹了外发电子邮件失败，因为接收端配置为仅允许通过 TLS 进行 SMTP。这是发件人的问题（它不应该使用该配置），但表明这种情况确实会发生。
我只会限制来自手动配置的 IP 地址的传入消息。如果您的信用卡处理器无法启动 STARTTLS，您可能更愿意中止连接（并呼叫本地管理员以便他可以警告他们！），而不是接收未加密的（潜在敏感）数据。对于出站消息，如果您之前使用 STARTTLS 连接到该主机，您可能不想再不安全地这样做，而是将其视为潜在的妥协。您可能还有一个已知始终使用 STARTTLS 的主机列表，例如 gmail 或 yahoo。
有https://www.eff.org/starttls-everywhere项目提供了一个 smtp 服务器列表，您可以（应该？）自信地强制使用 starttls。
答案3
拒绝来自无法加密的人的电子邮件是完全没有意义的，并且可能有害。
只要您的服务器设置为与提供机会加密的任何对等方进行机会加密，您就可以获得两全其美的效果：在可用时进行加密，在不可用时通过纯文本发送电子邮件。
只要有服务器不支持加密，强制加密就意味着他们无法与您通信；这很糟糕。一旦每个人都支持加密，机会性加密和强制加密就没有任何区别了。
正如其他人指出的那样，在线加密和端到端加密是完全不同的两件事，针对的是不同的威胁模型。不要混淆这两者。
答案4
我确实同意使用机会性 TLS 的想法。不过，我也有一些想法要补充。有些人可能会对这些建议感到不安，但是，由于我在这里的建议不是轻率和未经充分考虑就提出的，因此在做出判断之前，我请您阅读附件链接中的完整讨论。
使用机会性 TLS 是目前为止最好的解决方案。反对它的 MITM 角度只是一种转移注意力的借口。毕竟，正如 MH 在评论中提到的那样，即使是具有 TLS 连接的“合法”SMTP 也可能被 MITM 攻击，而最终用户却一无所知，因为绝大多数邮件客户端都懒得验证证书，而且绝大多数执行 TLS 的 MTA 都使用自签名证书（至少如果您不使用 DNSSEC 和 TLSA/DANE）。由于这一点以及可能的其他因素，甚至可以说，在您和世界其他地方都实施 DANE/TLSA 和 DNSSEC 之前，在运行机会性 TLS 时，最好也启用匿名 diffie-hellman（同时使用 PFS）。至少部分（如果不是主要）是由于它仍将加密流量以防被偶然观察者发现。为了进一步支持这种配置（比我的解释更为详细），请参阅 Viktor Dukhovni 在 postfix 论坛中的这篇文章中的评论：禁用匿名 Diffie Hellman。
至于为什么人们会采纳 Viktor 的建议而不是其他人的建议，因为他不仅编写了 DNSSEC 和 TLSA/DANE 的 IETF 草案，还编写了 Postfix MTA 的 TLS 代码以及 DNSSEC、TLSA/DANE 代码。因此，我认为他在这件事上的意见很有分量，可能比大多数人的意见更有分量。