TLS 1.3（RFC 8446）给 SMTP 带来了哪些实质变化？

TLS 1.3 相对 1.2 是一次大幅精简与收紧，与 SMTP 相关的要点包括：

• 握手缩短为 1-RTT，且大量握手消息被加密，握手延迟与可观测信息同时减少。
• 强制前向保密：静态 RSA 密钥传输与静态 DH 被移除，所有密钥协商都基于临时（ephemeral）密钥。这意味着即便服务器长期私钥日后泄露，历史会话也无法被解密——对邮件这种被长期存储的流量意义重大。
• 密码套件大幅裁剪：移除 RC4、3DES、静态 RSA、自定义 DHE 群、SHA-1 签名等一批陈旧或有缺陷的选项，全部套件均为 AEAD。
• 移除重协商与压缩：这两项分别是若干已知攻击的载体，直接删除比修补更彻底。
• Certificate 消息被加密：服务器证书不再以明文出现在握手中。
• 内建降级防护：在 ServerHello 随机数中放置特定哨兵值，使得试图把连接降级到旧版本的中间人能被检测到。

与之配套，RFC 8996 已正式弃用 TLS 1.0 与 1.1，邮件服务器不应再提供这两个版本。

一个常见困惑是"TLS 1.3 是否改变了 SMTP 的 STARTTLS 流程"。答案是不改变。RFC 3207 定义的 STARTTLS 是应用层的升级命令：客户端发出 STARTTLS，服务器应答 220，随后在同一 TCP 连接上开始 TLS 握手。至于握手内部协商出的是 1.2 还是 1.3，对这套流程是透明的。RFC 8314 提倡的隐式 TLS（连接即握手）同理。

但 STARTTLS 自身的固有弱点并未被 TLS 1.3 修复：STARTTLS 之前的 EHLO 应答是明文的，主动中间人可以直接抹掉能力列表中的 STARTTLS 通告，使客户端认为对端不支持加密而以明文投递——即 STARTTLS 剥离攻击。TLS 1.3 的降级防护只在握手已经开始之后生效，对"根本没能进入握手"的情形无能为力。

因此结论是明确的：TLS 1.3 不能替代 MTA-STS（RFC 8461）或 DANE（RFC 7672）。必须由这两者之一在带外声明"本域要求加密传输"，才能封住剥离攻击的入口。升级到 TLS 1.3 与部署 MTA-STS / DANE 是互补而非替代关系。

TLS 1.3 引入的 0-RTT 早期数据允许客户端在握手完成前就发送应用数据，以换取延迟收益。但规范本身在安全考量中明确指出：0-RTT 数据不具备重放保护，攻击者可以捕获并重复发送早期数据。

邮件传输恰恰是最不能容忍重放的场景之一：SMTP 的命令序列会产生持久副作用，重放可能导致邮件被重复投递、重复计费或重复触发下游业务流程。相比之下，SMTP 会话的建立延迟在整体投递时延中占比很小，为此承担重放风险毫无性价比。

运维建议直接明了：邮件服务器（无论是 25 端口的接收、587 的提交还是 IMAP/POP 访问）都应禁用 0-RTT 早期数据。若使用的软件默认开启，应显式关闭并纳入基线配置核查项。

Certificate 消息加密带来一个容易被忽视的运维副作用：被动流量分析不再能看到服务器证书。此前依赖旁路镜像流量来清点邮件出口证书、监控证书到期、发现异常证书的做法，在 TLS 1.3 下会失效。替代方案是转向主动探测（定期建立连接抓取证书）、依赖端点或 MTA 自身日志、以及使用 TLS-RPT（RFC 8460）从对端收集聚合报告。

迁移到 TLS 1.3 时的检查清单：

• 确认 MTA 与其依赖的 TLS 库版本均支持 1.3，并已启用；
• 关闭 TLS 1.0 / 1.1，评估 1.2 的保留期限（对端兼容性所需，通常仍需保留一段时间）；
• 显式禁用 0-RTT；
• 核对 OCSP 装订配置——TLS 1.3 中证书状态作为证书条目扩展传递，部分旧配置项语义已变；
• 更新依赖被动抓包的证书与协议监控，改为主动探测或基于日志；
• 确认 MTA-STS 策略与 DANE TLSA 记录仍然正确，切勿因升级 TLS 版本而误以为可以取消这两项。