RFC 8689: SMTP 要求 TLS 选项

Standards Track Transport Security Published March 2026

ELI5: 普通的电子邮件加密就像问信使"如果装甲车有空的话，请使用它"。如果装甲车正在忙，信使耸耸肩，就用普通货车。REQUIRETLS 是信封上的一个戳记，说"装甲车或根本不要投递"。这条消息宁愿退回也不愿以未加密的方式传送。

为什么存在这个机制

服务器间电子邮件加密（通过 STARTTLS）默认是**机会性的**。如果接收服务器不支持 TLS，或者中间人攻击者剥离了 STARTTLS 功能，大多数发送服务器会回退到明文传递。邮件会送达，但没有加密。

MTA-STS 和 DANE 这样的技术在域级别解决了这个问题——它们让接收域声明"发往我们的所有邮件都必须使用 TLS"。但这些是**接收方**策略。**发送方**没有办法说"这条特定邮件需要在每一跳都使用 TLS"。

RFC 8689 用两个互补的机制填补了这个空白：

REQUIRETLS SMTP 扩展：SMTP 信封中的逐邮件标志，告诉每个中继服务器"除非下一跳支持带验证证书的 TLS，否则不要传递此邮件"。
TLS-Required 头：一个邮件头，表示相同的意图，在发送方不直接控制 SMTP 信封时使用（例如，通过 MSA 提交时）。

工作原理

REQUIRETLS SMTP 扩展

发送方在 SMTP 事务期间通过将 REQUIRETLS 作为参数添加到 MAIL FROM 命令来声明其意图：

# 服务器在 EHLO 中公告 REQUIRETLS 支持 S: 220 mx.example.com ESMTP C: EHLO sender.example.org S: 250-mx.example.com S: 250-STARTTLS S: 250-REQUIRETLS S: 250 OK # 先升级到 TLS C: STARTTLS S: 220 Go ahead # ... TLS 握手及证书验证 ... C: EHLO sender.example.org S: 250-mx.example.com S: 250-REQUIRETLS S: 250 OK # 带 REQUIRETLS 标志提交 C: MAIL FROM:<alice@example.org> REQUIRETLS S: 250 OK C: RCPT TO:<bob@example.com> S: 250 OK

每一跳的处理流程

当中继服务器处理带有 REQUIRETLS 标志的邮件时，必须在转发前执行这些规则：

TLS 是强制性的。到下一跳的连接必须使用 TLS。如果下一个服务器不支持 STARTTLS，邮件不能被传递——它会被退回。
证书验证是必需的。下一跳的 TLS 证书必须有效且与服务器主机名匹配（通过 DANE/TLSA 或 Web PKI）。自签名或不匹配的证书会导致邮件被退回。
REQUIRETLS 标志会传播。如果中继服务器也支持该扩展，它必须将 REQUIRETLS 参数传递到下一跳。如果下一跳不支持 REQUIRETLS，中继可以在能够通过 DANE 或 MTA-STS 验证 TLS 的情况下仍然传递。

TLS-Required 头

对于通过 MSA 提交且不直接控制 SMTP 参数的发送方，TLS-Required 头提供了相同的信号：

TLS-Required: No ; 等等——"No" 意味着"不需要 TLS"？ ; 正确。该头有两个值： ; TLS-Required: No → 明确选择退出 REQUIRETLS ; （使用正常的机会性 TLS） ; 头的缺失意味着正常行为。 ; REQUIRETLS 信封标志是正信号。

TLS-Required: No 头是专门设计作为选择退出机制的。它告诉发送 MTA："即使 REQUIRETLS 通常会应用于这条邮件（例如，因为域范围策略），也不要对这条特定邮件强制执行。"这对于像密码重置或通知之类的邮件很有用，其中传递比保证加密更重要。

退回行为

当 REQUIRETLS 阻止传递时，发送服务器生成一份未递送报告（退回）。退回本身也必须通过 TLS 发送——REQUIRETLS 也适用于 DSN（递送状态通知）邮件。如果退回无法安全传递，它会被静默丢弃而不是以明文发送（以避免泄露有关原始邮件的信息）。

# 下一跳不支持 TLS——REQUIRETLS 阻止传递 C: EHLO relay.example.org S: 250-mx.recipient.com S: 250 OK # 未公告 STARTTLS——无法通过 REQUIRETLS 传递 # 中继生成退回给 alice@example.org： # 550 5.7.30 REQUIRETLS support required but not available

关键技术细节

与 MTA-STS 和 DANE 的关系

机制	谁设置策略	范围	验证方法
MTA-STS	接收域	发往该域的所有邮件	Web PKI（HTTPS 获取）
DANE	接收域	发往该域的所有邮件	DNSSEC + TLSA 记录
REQUIRETLS	发送服务器/用户	逐邮件	每一跳的 DANE 或 MTA-STS

REQUIRETLS 是互补的，而非竞争的。MTA-STS 和 DANE 保护接收域的入站邮件。REQUIRETLS 保护特定的出站邮件。带有 REQUIRETLS 的邮件在每一跳使用 DANE 或 MTA-STS 进行验证——如果某一跳都不可用，传递失败。

TLS 版本要求

REQUIRETLS 需要 TLS 1.2 或更高版本。使用 TLS 1.0 或 1.1 的连接不满足要求，这与RFC 8996 弃用较旧 TLS 版本的规定一致。

增强状态码

代码	含义
`5.7.30`	需要 REQUIRETLS 支持但下一跳不可用
`5.7.31`	无法遵守 REQUIRETLS（例如，下一跳的证书无效）

常见错误

假设 REQUIRETLS 被广泛部署。采纳率仍然有限。大多数 MTA 还不支持 REQUIRETLS 扩展。对所有邮件使用它会导致许多收件人的邮件被退回。
混淆 REQUIRETLS 和 STARTTLS。STARTTLS 是将连接升级到 TLS 的机制。REQUIRETLS 是强制 STARTTLS 成功并验证证书的策略。没有 REQUIRETLS 的 STARTTLS 是机会性的；REQUIRETLS 使其成为强制性的。
期望端到端加密。REQUIRETLS 确保每一跳都使用 TLS，但邮件在每个中继服务器处被解密和重新加密。这是逐跳加密，而不是端到端加密。要实现真正的端到端加密，请使用 S/MIME 或 PGP。
不处理退回。当收件人的服务器不支持 TLS 或有证书问题时，REQUIRETLS 会导致合法的传递失败。你的应用必须处理这些退回，并可能重试而不使用 REQUIRETLS，或通知用户。
使用 TLS-Required: Yes。没有 TLS-Required: Yes 值。该头仅有 No 值用于选择退出。正信号是 REQUIRETLS SMTP 参数，而不是头值。
忘记关于退回。REQUIRETLS 也适用于 DSN 邮件。如果退回无法通过 TLS 传递，它会被静默丢弃。原始发送方可能永远不会知道传递失败。

可传递性影响

降低传递率。对所有邮件启用 REQUIRETLS 会导致对不支持 TLS 或有证书问题的服务器的传递失败。将其选择性地用于安全性比传递确定性更重要的邮件。
保护高价值邮件。对于财务通知、法律文件、医疗数据或任何受法规合规约束的邮件，REQUIRETLS 确保邮件永远不会以明文传输。
补充 MTA-STS。如果你的域发布了 MTA-STS，且收件人的域也有 MTA-STS 或 DANE，REQUIRETLS 在域级策略之上添加逐邮件保证。这种组合提供了 SMTP 中可用的最强传输安全性。
退回邮件也受保护。因为 REQUIRETLS 适用于 DSN，退回邮件中的敏感信息（可能包含原始邮件的部分）也受到保护，不会以明文传输。