对 SMTP 强制加密是一个好主意（还）吗？

Question

我正在运行一个电子邮件服务器，该服务器当前设置为在发送和接收电子邮件时尽可能使用 TLS。

当您阅读有关此的文档时，还可以选择强制执行 TLS 并且不接受电子邮件的纯文本传输。它还警告您某些邮件服务器可能尚不支持加密，并且强制加密可能会阻止这些服务器。

但这仍然是一个应该考虑的问题，还是可以说强制加密不再是问题？

是否可能有一些大型供应商已经在做这件事，或者你认为现在最好的做法是什么？

Answer 1

实际问题是，并非每个符合 SMTP 的（RFC 很老）服务器都可以与您的服务器使用 TLS，因此您可能会错过接收一些电子邮件消息。

与此有关的哲学问题是，无法判断电子邮件在到达您的服务器之后（或之前）如何转发。

这意味着电子邮件可能已经通过中继以纯文本形式传输。

任何认真保护电子邮件内容的人都应该对正文进行加密。通过加密在途中，它已经以纯文本形式传输总是合理的。

因此，回答您在 SMTP 层强制加密的问题可能毫无意义，这会增加您丢失电子邮件的机会，并且无法保证获得收益。

编辑：这是指用于中继目的的 SMTP 强制，而不是提交电子邮件。在邮件提交中应该强制执行加密，因为 SMTP 对话（不是实际的电子邮件）可能包含身份验证凭据。

Answer 2

不

RFC 821 已有 33 年历史。您会发现由不支持 STARTTLS 的程序中继的电子邮件。有时它们会是存根电子邮件发件人（例如内部脚本），有时是成熟的旧系统、禁用/未编译 TLS、没有足够熵的系统......

不久前我目睹了出站电子邮件失败，因为接收端将其配置为仅允许 SMTP over TLS。这是发件人的问题（它不应该使用该配置），但表明它确实发生了。

我只会限制来自手动配置的 IP 地址的传入消息。如果您的信用卡处理器无法启动 STARTTLS，您可能更愿意中止连接（并呼叫本地管理员以便他可以警告他们！）而不是接收未加密的（潜在敏感）数据。对于出站消息，如果您之前使用 STARTTLS 连接到该主机，您可能不希望再次不安全地这样做，而是将其视为潜在的妥协。您可能还有一个已知始终使用的 STARTTLS 主机列表，例如 gmail 或 yahoo。

有https://www.eff.org/starttls-everywhere提供的SMTP服务器，而您可以（应该？）自信地执行STARTTLS使用的列表项目。

Answer 3

拒绝来自无法加密的对等方的电子邮件是完全没有意义的，而且可能是有害的。

只要您的服务器设置为与任何提供它的对等方进行机会加密，您就可以两全其美：可用时加密，不可用时通过明文发送电子邮件。

只要有不支持加密的服务器，强制加密就意味着他们无法与您交谈；那很糟。一旦每个人都支持它，机会加密和强制加密之间就没有区别了。

正如其他人所指出的那样，在线加密和端到端加密是两种完全不同的事物，针对不同的威胁模型。不要混淆两者。

Answer 4

这是一个政策问题。

通常，当对入站和出站强制执行 TLS 时，它是针对一组有限的域完成的，这些域是各方同意以满足需求的（例如，业务合作伙伴可能有协议加密他们公司之间的所有邮件）。

除非有这样的协议，否则不要打开强制模式。