RFC 8689《SMTP 服务扩展：强制要求 TLS》中文导读

1. 机会性 TLS 的缺口

STARTTLS 提供的是“机会性”加密：能用就用，不能就退回明文。这在多数场景下够用，但对某些敏感邮件（法律、医疗、财务）而言，“可能降级为明文”本身就是不可接受的风险。

RFC 8689 的 REQUIRETLS 扩展把“应当加密”升级为“必须加密且必须验证对端身份”：发件方在信封上打上 REQUIRETLS 标记，要求从本跳起到最终投递，邮件必须始终处于经过验证的 TLS 保护之下，否则宁可投递失败也不降级。

2. EHLO 通告与 MAIL FROM 参数

服务端在 EHLO 中通告 REQUIRETLS 关键字，表示它支持该扩展并能据此执行策略。发件方在 MAIL FROM 上附加 REQUIRETLS 参数：

C: EHLO client.example.org
S: 250-example.net Hello
S: 250 REQUIRETLS
C: MAIL FROM: REQUIRETLS
S: 250 OK

一旦 MAIL FROM 带上 REQUIRETLS，本事务后续的每一跳都必须满足：①使用 TLS；②对端证书经 DNSSEC/DANE 或 MTA-STS 做了有效性校验（即不是自签名、也未被中间人替换）。

3. TLS-Required 头字段与降级许可

默认情况下 REQUIRETLS 是逐跳强制的。但规范提供了一种“本地豁免”机制：邮件头字段 TLS-Required: No 表示该信件的发件方/策略允许本域在必要时不强制 TLS（例如对方确无 TLS 能力时允许降级）。

需要注意这是“反向开关”——头字段只在收件域明确同意降级时生效；而信封上的 REQUIRETLS 参数的强制力高于头字段，二者冲突时以更严格者为准。

4. 状态码：X.7.30 与 5.7.10

• X.7.30：邮件因策略要求使用 TLS 而未能成功投递（例如下一跳无 REQUIRETLS 能力，或证书校验失败）。用于把“强制 TLS 失败”与一般性拒收区分开。
• 5.7.10：对端要求加密但该连接未使用 TLS，故拒绝（常见于提交或中继侧要求 REQUIRETLS 的场景）。

这些增强码让发送方运维能够精确判断“是 TLS 策略导致失败，还是内容/信誉问题”，从而决定是调整策略还是联系对端。

5. 退信也必须受保护

一个容易被忽视的闭环要求：若一封 REQUIRETLS 邮件的投递状态通知（DSN）或处理通知（MDN）本身被生成，那么这些通知也必须带 REQUIRETLS——否则敏感邮件的失败回执反而可能以明文泄露“谁给谁发了什么、为何失败”的元信息。

规范明确指出：发送 REQUIRETLS 邮件所触发的任何 DSN/MDN，其生成方必须同样用 REQUIRETLS 投递，保持保护级别一致。

6. 部署依赖

REQUIRETLS 单独使用仍可能被主动中间人剥离（对方声称“无 REQUIRETLS 能力”而你又无法验证）。真正有效的强制，需要底层有可信的对端身份来源：

DANE（基于 DNSSEC 的 TLSA，见 RFC 7672）或 MTA-STS（基于策略发布与证书校验）。也就是说，REQUIRETLS 是“策略意图”，DANE/MTA-STS 是“验证手段”，二者配合才能抵御主动降级攻击。

对运维而言，启用 REQUIRETLS 前应先确认对端域已发布 DANE/MTA-STS，否则该功能只会让大量邮件因校验失败而卡住。

参考：https://www.rfc-editor.org/rfc/rfc8689.txt