在 Thunderbird 中（我认为在许多其他客户端中也是如此），我可以选择“SSL/TLS”和“STARTTLS”。
据我了解，“STARTTLS”的意思很简单“如果两端都支持 TLS，则加密，否则不加密传输”。“SSL/TLS”的简单含义是“始终加密，否则根本不连接”。它是否正确？
或者换句话说：
STARTTLS 是否不如 SSL/TLS 安全，因为它可以在不通知我的情况下恢复为纯文本？
答案1
答案基于 SMTP 的 STARTTLS RFC（RFC 3207） 是：
STARTTLS 不如 TLS 安全。
我不会亲自发言，而是让 RFC 自己说话，其中四个相关部分突出显示在大胆的：
可以通过从服务器删除“250 STARTTLS”响应来发起中间人攻击。这将导致客户端不尝试启动 TLS 会话。另一种中间人攻击是允许服务器宣布其 STARTTLS 功能，但更改客户端启动 TLS 的请求和服务器的响应。为了防御此类攻击，客户端和服务器都必须能够配置为要求所选主机的适当密码套件的 TLS 协商成功，然后才能成功传输消息。附加选项还应提供在可能的情况下使用 TLS 的实现。可能提供记录与给定对等方进行通信时使用 TLS 的功能，如果在以后的会话中未使用 TLS，则会生成警告。
如果 TLS 协商失败或者客户端收到 454 响应，则客户端必须决定下一步做什么。 主要有三个选择：继续进行 SMTP 会话的剩余部分，[...]
正如您所见，RFC 本身声明（不是很清楚，但足够清楚）没有任何内容要求客户端建立安全连接并在安全连接失败时通知用户。它明确地为客户提供默默建立的选项纯文本连 接。
答案2
这两种选择的安全性没有区别。
SSL/TLS 首先打开 SSL/TLS 连接，然后开始 SMTP 事务。此操作必须在尚未运行非 SSL/TLS SMTP 服务器的端口上进行；由于协议的性质，无法配置单个端口来同时处理纯文本和加密连接。
STARTTLS 启动 SMTP 事务并在对 EHLO 的响应中寻求另一端对 TLS 的支持。如果客户端在支持的命令列表中看到 STARTTLS，则它会发送 STARTTLS 并开始协商加密。所有这些都可以（并且通常会）在标准 SMTP 端口 25 上发生，部分是为了向后兼容，但也允许在支持但不一定需要它的端点之间进行机会性加密。
通常，SSL/TLS 仅用于终端客户端和服务器之间。STARTTLS 更常用于 MTA 之间，以保护服务器间的传输。
鉴于这两种实现方式，如果用户或管理员认为连接已加密但实际上并未将其配置为需要加密，则 STARTTLS 可能被视为不安全。但是，所使用的加密与 SSL/TLS 完全相同，因此除了这种类型的配置错误之外，它不会更容易或更不容易受到中间人攻击。
答案3
尤其是电子邮件，2018 年 1 月RFC 8314已发布，其中明确建议在 IMAP、POP3 和 SMTP 提交中优先使用“隐式 TLS”而不是 STARTTLS 机制。
简而言之，本备忘录现建议：
- TLS 1.2 或更高版本适用于 MUA 与邮件提交服务器之间以及 MUA 与邮件访问服务器之间的所有流量。
- MUA 和邮件服务提供商 (MSP) (a) 不鼓励使用明文协议访问邮件和提交邮件，以及 (b) 尽快弃用使用明文协议进行这些目的。
- 使用“隐式 TLS”（定义如下）与邮件提交服务器和邮件访问服务器的连接，倾向于 连接到“明文”端口并使用 STARTTLS 命令协商 TLS或类似的命令。
（强调添加）
答案4
是的，你掌握了基本知识。没错，STARTTLS 确实不太安全。它不仅可以在未通知的情况下故障恢复为纯文本，而且还容易受到中间人攻击。由于连接以明文形式开始，中间人可以删除 STARTTLS 命令，并阻止加密发生。但是，我相信邮件服务器可以指定仅在设置加密隧道后才进行传输。所以你可以解决这个问题。
那么为什么会有这样的事情存在呢？出于兼容性的原因。如果任何一方都不支持加密，您可能仍然希望连接能够正常完成。