强制对SMTP进行加密是个好主意吗？

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

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

但是，这仍然是人们应该考虑的问题吗？或者可以肯定地说，加密不再是问题吗？

可能已经有一些大型提供商已经在执行此操作，或者您最近如何看待最佳实践？

实际的问题是，并非每个兼容SMTP的服务器（RFC都相当老）都可以对您的服务器使用TLS，因此您可能会错过接收某些电子邮件的机会。

与此相关的哲学问题是，无法确定电子邮件在到达服务器后（或之前）如何进行中继。

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

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

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

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

没有

RFC 821已有33年历史。您会发现由不支持STARTTLS的程序转发的电子邮件。有时，他们将是存根电子邮件发件人（例如，内部脚本），有时是较老的成熟系统，禁用了TLS /未编译TLS，并且系统没有足够的熵……

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

我只会限制来自手动配置的IP地址的传入消息。如果您的信用卡处理器无法启动STARTTLS，您可能更喜欢终止连接（并向本地管理员发送页面，以便他可以警告他们！），而不是接收未加密的（可能敏感的）数据。对于出站邮件，如果您以前使用STARTTLS连接到该主机，则可能不想再次执行不安全的操作，而是将其视为潜在的危害。您可能还会有一个始终可以使用的STARTTLS主机列表，例如gmail或yahoo。

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

拒绝不支持加密的同级的电子邮件是完全没有意义的，并且可能是有害的。

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

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

就像其他人指出的那样，在线加密和端到端加密是两种完全不同的事物，可以解决不同的威胁模型。不要混淆两者。

这是一个政策问题。

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

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

不，这是一个非常糟糕的主意。

实际上，事实证明，如果TLS连接无法协商，大多数STARTTLS服务器/客户端都不会在没有StartTLS的情况下实现任何种类的重试算法。

这样，即使宣传STARTTLS作为一种选择，也已经减少了您获取（和发送）电子邮件的机会！

只是搜索，您会发现许多人无法将任何电子邮件发送到* .protection.outlook.com群集处理的Microsoft Outlook域：

使用TLS时Microsoft拒绝的Sendmail消息

原因：403 4.7.0 TLS握手失败

总结以上两个职位中提出的问题：

• 可以将任何邮件发送到除Outlook处理的主机以外的任何主机（无论是否具有STARTTLS），
• 可以将没有客户端证书且没有STARTTLS的邮件发送到Outlook，
• 或带有零长度的客户证书，
• 但是没有提供Microsoft不喜欢的证书，并且在失败时，如果收件人的服务器的确发布了STARTTLS，则客户端（以及在客户端模式下运行的服务器）在没有STARTTLS的情况下不会尝试重新发送消息！

同样，当您的主机充当服务器时，如果您决定启用STARTTLS，则在您的控制范围之外可能会发生类似的情况-当客户端服务器发现服务器模式下的服务器提供STARTTLS时，他们会尝试协商TLS，但是如果协商失败，他们只是等待，然后再次尝试相同的步骤，一直失败，直到必须将邮件退回给发件人为止！

在STARTTLS领域的各个域中，这种情况确实经常发生！

可悲的是，就像我过去曾经是STARTTLS的支持者一样，我现在却被剥夺了我被认为是机会主义加密的无风险广告所误导的权利。

如果您要确保互操作性，则不仅不需要STARTTLS，而且甚至应该谨慎地完全禁用它。

我确实必须同意使用机会性TLS的想法。虽然，我也确实有一些补充。有些人可能会被这些建议打扰，但是，由于我在这里的建议不是很轻易就提出来的，没有经过适当考虑，所以在做出判断之前，请您阅读附件中的完整讨论。

迄今为止，使用机会性TLS是最佳解决方案。MITM角度反对它是一个红色鲱鱼。毕竟，正如MH在评论中提到的那样，即使是具有TLS连接的“合法” SMTP也可以进行MITM认证，并且由于绝大多数邮件客户端不费力地验证证书以及绝大多数邮件，最终用户就不是明智的选择进行TLS的MTA中有大量使用的是自签名证书（至少在不使用DNSSEC和TLSA / DANE的情况下）。由于这一因素以及其他可能的因素，甚至在您和世界其他地方都可以争论已实施DANE / TLSA和DNSSEC，因此在运行机会性TLS时最好也不要启用匿名diffie-hellman（同时也使用PFS）。至少部分（如果不是大部分的话）应归因于它仍会加密流量以防止偶然的观察者。为了进一步支持该配置（比我的配置更加详尽的解释），请在postfix论坛中的这篇帖子中查看Viktor Dukhovni的评论：http://postfix.1071664.n5.nabble.com/Disabling-Anonymous-Diffie-Hellman-td67965.html

关于为什么一个人可能会接受Viktor的建议，好吧，他除了为这两个DNSSEC编写IETF草案外，还为Postfix MTA编写了TLS代码以及DNSSEC，TLSA / DANE代码。和TLSA / DANE。因此，我要说的是，他在此问题上的话语具有很大的分量，可能比大多数人的意义更大。

希望这可以帮助。

从电子邮件营销的角度来看，当您知道在整个交付链中都已实施TLS时，TLS的使用是一种很好的做法，并且是安全的。但是，如果安全性是您的最高要求，那么在发送电子邮件之前先对其进行加密是最安全的选择（例如，使用PGP）。