我并不像本网站上的大多数人那样精通技术，所以请记住这一点。我想了解有关电子邮件安全的更多信息，所以我做了一些研究，一切都符合我的理解，所以请在需要的地方纠正我。客户端和服务器（MSA/MTA？）之间的连接可以加密，但服务器到服务器（MTA 到 MTA？）之间的加密取决于每个服务器是否支持 STARTTLS。STARTTLS 也可以在客户端和服务器之间实现。
我发现 STARTTLS 的唯一弱点是连接可以通过加密或纯文本接受，因此在加密可以降级为纯文本的情况下，MITM 攻击似乎微不足道。此外，我知道证书存在伪造问题，但我不知道这是否与 MITM 直接相关。
我读到这是实施问题，而不是协议本身的问题。我遇到的一些解决方案涉及配置客户端，以便在连接未通过 SSL/TLS 发生时通知或完全断开连接。是否有适当的方法来实现 STARTTLS，以使 MITM 不可能发生（而不是在发生时对其做出反应，如果这有意义的话），以及在哪里发生？这些修复是旨在覆盖服务器到服务器的连接还是仅覆盖客户端到服务器的连接？我还想更多地了解伪造证书的问题，这种弱点是如何产生的，以及如何通过实施或其他方式解决它。
我最感兴趣的是服务器到服务器之间的安全性，因为服务器到客户端似乎不是什么大问题，而且大多数 ESP 已经处理好了。有没有比 STARTTLS 更好的替代方案？正如我提到的，我对这一切都很陌生，我需要对其中大部分内容的全面指导，包括如何实施/配置。如果没有人能在这里提供这些，我将不胜感激，只要有学习资源，我就能找到正确的方向。
另一方面......我也对了解实际的攻击/漏洞感兴趣，我想知道上面提到的 MITM（服务器到服务器）是否可以针对特定的连接（目标电子邮件地址？）或者更类似于抓住路过的任何东西。
答案1
以安全方式传输电子邮件存在几个问题，这些问题最好在 security.stackexchange.com 上提出。邮件可以在各个阶段被拦截：
- 显式 TLS（STARTTLS）和隐式 TLS（SMTPS）提供逐跳而不是端到端的安全性，也就是说，中间的每个邮件服务器都可以访问未加密的邮件。
- 邮件的下一跳是通过 DNS 查找 MX 记录来确定的。除非使用 DNSSec，否则这很容易被欺骗，而 DNSSec 大多情况下不会使用。如果被欺骗，即使在 TLS 握手中正确检查证书也无济于事，因为它会检查与错误 MTA 的连接是否正确。
- MX 仅定义为使用端口 25 上的服务器，即使用显式 TLS（STARTTLS）。由于发送 MTA 无法知道接收 MTA 是否支持 STARTTLS，因此中间人攻击者可以通过修改对 EHLO 命令的回复中支持的扩展列表或拒绝 STARTTLS 命令将连接简化为纯文本。即使黑客无法直接拦截连接，也可能能够在 TLS 握手开始时注入 TCP RST 数据包，这样客户端就会认为使用 TLS 存在问题并会恢复为纯文本。由于 TLS 握手实际上存在足够多的现实问题，因此客户端可能不会产生怀疑。
- 而且在 TLS 握手过程中，通常不会进行适当的验证。有时根本不会检查证书，有时只检查链，而不检查主机名是否匹配等。但同样，如果 MX 已被欺骗，则可能还是针对错误的服务器进行验证 :(
这意味着为了使逐跳加密至少足够安全，您必须在多个地方添加非平凡的修复，并且其中大多数都不受发送 MTA 的控制。
详细了解评论中的问题：
1.) STARTTLS 通常是在服务器之间实现的吗，还是从客户端-服务器开始，然后逐跳进行？
STARTTLS 必须在每一跳（MTA）上实现。只有当接收 MTA 支持 STARTTLS 并且发送 MTA 可以执行时，它才可以使用。它不依赖于邮件如何从客户端传递到初始跳（MTA）。通常，SMTP 的 TLS 仅加密跳之间的连接，因此如果它不是端到端加密（使用 PGP 或 S/MIME），则可以在每一跳上以明文形式读取。
2.) 通过 PGP 或 S/MIME 加密的邮件是否仍会被 MX 欺骗重定向？
是的，它仍然可以被重定向。但邮件本身仍然只能由真正的收件人（即目标密钥的所有者）解密。
3.) DNSSEC 是否必须大规模采用才能发挥作用，还是个人可以通过在自己的电子邮件服务器上进行配置而受益？
每一点都有帮助，但只有一点点。请注意，它不仅需要 DNSSec 记录，而且转发 MTA 必须实际使用 DNSSec。大多数 MTA 可能只做 DNS，并且不知道他们是否收到了欺骗性的 MX 记录。
4.) 您是否需要担心隐式 tls 的 TCP RST 注入或仅仅是显式的？
隐式 TLS 仅用于从客户端到 MTA，即到初始跳转。这是最安全的步骤，因为它实际上由客户端控制，并且客户端通常使用具有固定 TLS 设置的固定 SMTP 服务器，因此不存在 MX 欺骗和连接降级问题。如果客户端配置为仅在可用时使用 TLS，则攻击也可能针对隐式 TLS 起作用。
5.) 如果其他 MTA 不兼容 TLS，您是否无法将服务器/MTA 配置为断开连接（退回电子邮件），即从机会性切换到必需，或者这是否只能在客户端（如 Thunderbird）上执行的客户端-服务器连接？
大多数服务器都可以这样配置，但大多数服务器必须与各种服务器通信，而且它们事先并不知道服务器是否支持 TLS。但例如，sendmail 可以配置为仅与特定服务器通信 TLS，或不与特定的其他服务器通信 TLS。因此，此配置可以强化到已知的良好服务器，但这必须手动完成。
6.) 如果出现第 5 种情况且电子邮件被退回，发件人会收到“发送失败”通知吗？
是的，通常都是这样，就像所有交付错误一样。但与大多数其他交付错误一样，只有技术熟练的人才能理解这些错误消息。
7.) 至于证书未得到检查，这是否可以通过正确的配置/实施来解决。我读到其中一个问题是许多证书都是自签名的，大多数 MTA 默认接受它们，以便它们可以与更多 MTA 保持兼容。这是您所指的一部分吗？
这取决于服务器。上次我检查时发现 postfix 没问题，但 sendmail 无法根据证书正确检查主机名。是的，自签名是一个问题，另一个主要问题是缺少中间证书。但由于邮件传递无论如何都能正常工作（因为发件人会忽略证书错误），大多数管理员没有意识到配置不当或不在乎。
8.) 最后，假设所有重要的修复都已到位，并且我知道其他 MTA/客户端不受我控制。这些 MITM 和注入攻击能否针对往返于我电子邮件地址的特定连接？在这种情况下，他们还没有侵入我的服务器，他们之前也没有接触过我的联系人。
再次强调，这只是逐跳加密，邮件在每个跳点上都以明文形式可供阅读和修改。因此，在传输过程中涉及的任何跳点（通常至少两个，一个在发送方，一个在接收方站点）上的攻击者都可以拦截并修改邮件，当然也可以限制自己只处理选定的邮件。唯一的保护是使用 PGP 或 S/MIME 进行端到端加密。