comfreak Asked: 2015-10-19 04:33:01 +0800 CST2015-10-19 04:33:01 +0800 CST 2015-10-19 04:33:01 +0800 CST 对 SMTP 实施加密是个好主意吗（还）？ 772 我正在运行一个电子邮件服务器，该服务器当前设置为在发送和接收电子邮件时尽可能使用 TLS。 当您阅读有关此的文档时，还可以选择强制执行 TLS 并且不接受电子邮件的纯文本传输。它还警告您，某些邮件服务器可能还不支持加密，强制加密可能会阻止这些服务器。 但这仍然是一个应该考虑的问题，还是可以肯定地说强制加密不再是问题？ 是否可能有一些大型提供商已经在这样做，或者您认为这些天的最佳做法是什么？ encryption 8 个回答 Voted Best Answer Matthew Ife 2015-10-19T04:43:09+08:002015-10-19T04:43:09+08:00 实际的问题是，并非每个符合 SMTP（RFC 很老）的服务器都可以与您的服务器使用 TLS，因此您可能会错过接收一些电子邮件消息。 哲学上的问题是，无法判断电子邮件在到达您的服务器之后（或之前）是如何被中继的。 这意味着电子邮件可能已经通过中继以纯文本形式传输。 任何认真保护其电子邮件内容的人都应该对正文进行加密。使用加密途中它总是合理的，它已经以纯文本形式传输。 因此，回答您在 SMTP 层强制加密的问题可能毫无意义，会增加您丢失电子邮件的机会，并且无法保证获得有益的回报。 编辑：这是指为了转发而不是提交电子邮件而强制执行 SMTP。在邮件提交中应该强制执行加密，因为 SMTP 对话（不是实际的电子邮件）可能包含身份验证凭据。 Ángel 2015-10-19T09:49:24+08:002015-10-19T09:49:24+08:00 不 RFC 821 已有 33 年历史。您会发现不支持 STARTTLS 的程序转发的电子邮件。有时他们会是存根电子邮件发件人（例如内部脚本），有时是成熟的旧系统，禁用/未编译 TLS，没有足够熵的系统…… 不久前，我目睹了出站电子邮件失败，因为接收端将其配置为仅允许 SMTP over TLS。这是发件人的问题（它不应该使用该配置），但表明它确实发生了。 我只会限制来自手动配置的 IP 地址的传入消息。如果您的信用卡处理器无法启动 STARTTLS，您可能更愿意中止连接（并呼叫本地管理员，以便他可以警告他们！），而不是接收未加密的（潜在敏感）数据。对于出站消息，如果您之前使用 STARTTLS 连接到该主机，您可能不想再次不安全地这样做，而是将其视为潜在的妥协。您可能还有一个已知始终使用 STARTTLS 主机的列表，例如 gmail 或 yahoo。 https://www.eff.org/starttls-everywhere项目提供了一个 smtp 服务器列表，您可以（应该？）自信地强制使用 starttls。 MadHatter 2015-10-19T07:38:49+08:002015-10-19T07:38:49+08:00 拒绝来自无法加密的同行的电子邮件是完全没有意义的，而且可能是有害的。 只要您的服务器设置为与任何提供它的对等方进行机会加密，您就可以获得两全其美的优势：可用时加密，不可用时通过纯文本发送电子邮件。 只要有服务器不支持加密，强制它就意味着他们不能和你说话；那很糟。一旦每个人都支持它，机会加密和强制加密之间就没有区别了。 正如其他人所指出的，在线加密和端到端加密是两个完全不同的东西，针对不同的威胁模型。不要混淆两者。 MikeyB 2015-10-19T06:29:56+08:002015-10-19T06:29:56+08:00 这是一个政策问题。 通常，当对入站和出站强制执行 TLS 时，它是针对一组有限的域完成的，这些域由各方同意以满足需求（例如，业务合作伙伴可能有一个协议来加密他们公司之间的所有邮件）。 除非有这样的协议，否则不要打开强制模式。 cnst 2015-10-21T02:20:05+08:002015-10-21T02:20:05+08:00 不，这是一个非常糟糕的主意。 事实上，事实证明，如果 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，而且如果您想确保互操作性，甚至可以谨慎地完全禁用它。 Mce128 2015-10-21T11:07:09+08:002015-10-21T11:07:09+08:00 我必须同意使用机会性 TLS 的想法。虽然，我也有一些要补充的想法。有些人可能会对这些建议感到不安，但是，由于我在此提出的建议并非轻率且没有经过充分考虑，因此在做出判断之前，请您阅读所附链接中的完整讨论。 使用机会性 TLS 是迄今为止最好的解决方案。MITM 角度作为反对它的论据是一个转移注意力的问题。毕竟，正如 MH 在评论中提到的那样，即使是带有 TLS 连接的“合法” SMTP 也可以是 MITM 的，并且最终用户也不会更明智，因为绝大多数邮件客户端都懒得验证证书，再加上绝大多数执行 TLS 的 MTA 正在使用自签名证书（至少如果您不使用 DNSSEC 和 TLSA/DANE。）由于这个和可能的其他因素，甚至可以说，直到您和世界其他地方已经实现了 DANE/TLSA 和 DNSSEC，在运行机会性 TLS 时，最好同时启用匿名 diffie-hellman（同时也使用 PFS）。至少部分（如果不是主要的话）是因为它仍然会加密流量以防止不经意的观察者。为了进一步支持这种配置（比我的解释更详细），请参阅 Viktor Dukhovni 在 postfix 论坛的这篇文章中的评论：http://postfix.1071664.n5.nabble.com/Disabling-Anonymous-Diffie-Hellman-td67965.html 至于为什么有人可能会接受 Viktor 的建议而不是其他人的建议，好吧，他编写了 TLS 代码以及 DNSSEC，用于 Postfix MTA 的 TLSA/DANE 代码，此外他还曾在这两个 DNSSEC 上编写过 IETF 草案和 TLSA/DANE。因此，我会说他在这件事上的话很有分量，可能比大多数人的更重要。 希望这可以帮助。 Scott 2020-09-15T08:04:55+08:002020-09-15T08:04:55+08:00 我们在公共邮件服务器上实施 SMTP (TLS) 加密已有两年了。我们了解到，所有“错过”的通信中有 99.99% 来自垃圾邮件发送者、网络钓鱼者和已知的被利用主机（我们检查每个 IP 地址）。我们只遇到了两家试图以纯文本形式发送电子邮件但被拒绝的合法公司。在我们通知他们后，他们更改了服务器或提供商以解决该问题。 在电子邮件服务器上实施 TSL 可以让世界更安全，并且实际上使垃圾邮件过滤器的使用过时，因为垃圾邮件发送者或网络钓鱼者永远不会使用证书来发送加密的邮件。它使我们的邮件服务器保持干净和快速。 在我们这样做之前，至少 96% 的收到的邮件被我们的过滤器标记为垃圾邮件，现在超过 99% 的收到邮件是合法的。只有垃圾邮件发送者会建议反对它。 ERM 2015-10-20T17:25:12+08:002015-10-20T17:25:12+08:00 从电子邮件营销的角度来看，当您知道 TLS 是通过整个交付链实施时，使用 TLS 是一种很好的做法并且是安全的。但是，如果安全性是您的首要要求，那么在发送之前加密电子邮件本身是最安全的选择（例如使用 PGP）。
实际的问题是，并非每个符合 SMTP（RFC 很老）的服务器都可以与您的服务器使用 TLS，因此您可能会错过接收一些电子邮件消息。
哲学上的问题是，无法判断电子邮件在到达您的服务器之后（或之前）是如何被中继的。
这意味着电子邮件可能已经通过中继以纯文本形式传输。
任何认真保护其电子邮件内容的人都应该对正文进行加密。使用加密途中它总是合理的，它已经以纯文本形式传输。
因此，回答您在 SMTP 层强制加密的问题可能毫无意义，会增加您丢失电子邮件的机会，并且无法保证获得有益的回报。
编辑：这是指为了转发而不是提交电子邮件而强制执行 SMTP。在邮件提交中应该强制执行加密，因为 SMTP 对话（不是实际的电子邮件）可能包含身份验证凭据。
不
RFC 821 已有 33 年历史。您会发现不支持 STARTTLS 的程序转发的电子邮件。有时他们会是存根电子邮件发件人（例如内部脚本），有时是成熟的旧系统，禁用/未编译 TLS，没有足够熵的系统……
不久前，我目睹了出站电子邮件失败，因为接收端将其配置为仅允许 SMTP over TLS。这是发件人的问题（它不应该使用该配置），但表明它确实发生了。
我只会限制来自手动配置的 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 握手失败
总结以上两篇文章中提出的问题：
同样，当您的主机充当服务器时，如果您决定启用 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）。至少部分（如果不是主要的话）是因为它仍然会加密流量以防止不经意的观察者。为了进一步支持这种配置（比我的解释更详细），请参阅 Viktor Dukhovni 在 postfix 论坛的这篇文章中的评论：http://postfix.1071664.n5.nabble.com/Disabling-Anonymous-Diffie-Hellman-td67965.html
至于为什么有人可能会接受 Viktor 的建议而不是其他人的建议，好吧，他编写了 TLS 代码以及 DNSSEC，用于 Postfix MTA 的 TLSA/DANE 代码，此外他还曾在这两个 DNSSEC 上编写过 IETF 草案和 TLSA/DANE。因此，我会说他在这件事上的话很有分量，可能比大多数人的更重要。
希望这可以帮助。
我们在公共邮件服务器上实施 SMTP (TLS) 加密已有两年了。我们了解到，所有“错过”的通信中有 99.99% 来自垃圾邮件发送者、网络钓鱼者和已知的被利用主机（我们检查每个 IP 地址）。我们只遇到了两家试图以纯文本形式发送电子邮件但被拒绝的合法公司。在我们通知他们后，他们更改了服务器或提供商以解决该问题。
在电子邮件服务器上实施 TSL 可以让世界更安全，并且实际上使垃圾邮件过滤器的使用过时，因为垃圾邮件发送者或网络钓鱼者永远不会使用证书来发送加密的邮件。它使我们的邮件服务器保持干净和快速。
在我们这样做之前，至少 96% 的收到的邮件被我们的过滤器标记为垃圾邮件，现在超过 99% 的收到邮件是合法的。只有垃圾邮件发送者会建议反对它。
从电子邮件营销的角度来看，当您知道 TLS 是通过整个交付链实施时，使用 TLS 是一种很好的做法并且是安全的。但是，如果安全性是您的首要要求，那么在发送之前加密电子邮件本身是最安全的选择（例如使用 PGP）。