您描述的问题不是 STARTTLS 本身的使用，而是 STARTTLS 的可选使用。可以设置邮件系统，以便需要 TLS，在这种情况下，如果 STARTTLS 失败或对等方不提供 EHLO 中的 STARTTLS 支持，则不会传递邮件。所需的 STARTTLS 从一开始就与所需的 TLS 一样安全。

在大多数设置中 STARTTLS 不是强制性的原因是因为仍有足够多的系统不支持 TLS。谷歌当前的透明度报告显示，谷歌发送的所有邮件中只有 90% 是通过 TLS 发送的，这意味着 10% 的邮件被发送到不支持 TLS 的 MTA。

除此之外，即使使用强制 TLS，邮件也不会以足够安全的方式传递。TLS 仅在邮件传递期间的各个跃点之间使用，不提供 TLS 在 HTTPS 中提供的端到端安全性。这意味着路径上的每个邮件服务器都可以访问邮件的纯文本，并且可以读取和修改它，除非邮件受到 PGP 或 S/MIME 等端到端保护的额外保护。

降级攻击是主动攻击。

主动攻击比被动攻击更容易检测，并且通常更难以执行。

机会加密，例如 SMTP 中的可选 STARTTLS，主要防止被动监视，其中流量在传输过程中无法检测到，或者被存储以供以后分析。您完全正确，机会主义加密不能防止主动攻击。一般而言，机会加密根本不会试图防止攻击者能够并且愿意修改传输中的数据的攻击。这超出了它的范围。同样，机会主义 STARTTLS 不能防止流氓邮件服务器将数据传递给第三方。这超出了它的范围。

至少一些 SMTP 服务器（相当流行的Postfix 就是其中之一）可以配置为在发送（或接收）邮件时需要 TLS，无论是全局还是手动在每个 MX 基础上发送邮件。当这样配置时，如果 STARTTLS 失败或不可用（不管是什么原因），SMTP 会话可以根据本地配置的策略被拒绝。

虽然主动攻击确实会发生，但我们有充分的理由相信被动流量监控在当今的 Internet 上很普遍。无处不在的监控是一种攻击，通常可以而且当然应该在可能的情况下得到缓解。

因此，即使机会性加密对防止主动攻击者没有任何作用，它也是一种胜利，因为它可以防止被动流量监控和监视了解更多关于正在通信的数据的必要信息。同样的论点也适用于未经身份验证的 HTTPS，因为即使它不能抵御所有攻击，但从通信隐私的角度来看，它仍然是对完全明文通信的改进。

有一个标准RFC 8461 SMTP MTA Strict Transport Security (MTA-STS)，可用于指定给定域的邮件服务器流量需要TLS。该标准仍然很新（RFC 的日期为 2018 年 9 月），因此我希望对此的支持参差不齐，但同样，只要一切设置正确，发布 MTA-STS 政策在最坏的情况下，不会改善通信隐私（因为未实施 MTA-STS 的 MTA 只会像根本没有发布 MTA-STS 政策一样行事，而正确实施 MTA-STS 的MTA将能够接受已发布的MTA-STS 政策考虑到政策决定）。

此外，还有一个标准跟踪 SMTP 扩展REQUIRETLS，可用于指定传输层安全性应优先于消息传递。

即使使用纯粹的机会加密可能会进行降级攻击，但这并不意味着纯粹的机会加密毫无价值。这只是意味着存在纯粹的机会加密无法解决的威胁；这与存在需要加密无法解决的威胁这一事实没有什么不同。