MTA-STS 与 TLS-RPT：强化邮件传输安全的下一代协议
给域名加完一条 _mta-sts 的 TXT 记录，就以为传输加密从此锁死——结果策略文件根本没挂到 HTTPS 端点上，或 TXT 里的 id 与策略文件对不上，对端在 enforce 模式下取不到策略，邮件开始在队列里堆积，而日志里那行提示看起来又不像"证书错误"，第一反应完全找错方向。资深一点的运维也会撞上另一面：策略紧急改完、DNS 也更新了，可对端还在按旧策略办事——因为策略文件早就被缓存在对方手里，调低 max_age 根本不能缩短那份已经生效的缓存寿命，撤回一条错策略比发布它难得多。
这两类故障指向同一件事：MTA-STS（RFC 8461）不是一条 DNS 记录，而是一套横跨 DNS 与 HTTPS 的双信道发布机制，外加一套由策略自己声明有效期、却无法被发布方召回的缓存结构。TLS-RPT（RFC 8460）则是配套的观测信道——它不堵任何洞，只把"洞在哪、有多大"报回来。下面按三组冲突拆开：双信道的不一致窗口、自引用缓存的不可召回性、以及与 DANE 之间那条信任锚的路线分歧。
一、MTA-STS 到底堵住了 STARTTLS 的哪个洞，又给自己开了什么口？
机会性 STARTTLS 的固有缺陷是：加密能力本身以明文在 SMTP 协商阶段声明——服务器在 EHLO 响应里给出"250 STARTTLS"，客户端看到才决定升级。主动攻击者只要抹掉这行声明，会话就回退到明文投递，而双方都无法区分"对端不支持 STARTTLS"与"中间人删了 STARTTLS"。MTA-STS 要堵的就是这个降级窗口：它让"必须加密"这件事本身以抗篡改的方式被获知，而不是依赖一次明文协商。根据 RFC 8461 的定义，该协议的设计目的就是防止 TLS 降级与中间人攻击。
它落地为两条叠加防线。第一条：策略本体经 HTTPS 获取，而不是在明文 SMTP 会话里谈——攻击者抹掉 SMTP 层面的 STARTTLS 声明，抹不掉一个已经通过 DNS 预先获知、且经 HTTPS 取到的策略。第二条：在 TLS 握手之上额外要求 MX 主机证书通过 WebPKI（公共 CA 体系）验证，并与策略文件 mx 字段列出的主机名做身份比对。"加密了"被升级为"加密给了正确的那个人"，而不是"加密给了一个拿着未知证书的对端"。
这里需要厘清一个定位：MTA-STS 不替换 STARTTLS。会话流程仍然是先明文建连、再升级 TLS，被强化的是"升级失败后能不能以明文继续"这个决策点。它是叠加在 STARTTLS 之上的一层策略约束，不是替换传输层的新协议。把它理解成"邮件加密方案"是职责混淆——它保护的是"发送方→接收方这一跳"的传输安全，不涉及邮件内容加密（那是 S/MIME 或 OpenPGP 的职责），也不涉及收件人之后的任何环节。
策略分三档：enforce、testing、none。enforce 是硬约束：TLS 或证书校验不通过，发送方不得明文投递，邮件留在队列里重试；testing 是过渡档：策略照常被评估、失败会被记录并可上报 TLS-RPT，但不阻止投递；none 是关闭强制但保留策略存在性。testing 这一档的存在，本身就是对"直接上 enforce 风险"的官方承认——直接 enforce 的代价不是静默丢弃，而是邮件延迟与队列堆积，严重时对端反复重试最终退信。
none 与"根本没有发布策略"在行为上有一条容易被忽略的边界。none 模式下，发送方确实查询到了策略、也完成了获取，只是按策略指示不强制；而未发布策略的域，发送方从不发起这次查询，直接停留在机会性加密。两者对外的投递结果相似（都允许明文），但对运维可见性的影响完全不同：none 域仍会进入发送方的 TLS-RPT 统计口径，未发布域则不会。把一条正在排障的策略改成 none，相当于"挂着观察档下线"，而不是"彻底消失"。
最后是防护前提：MTA-STS 只对声明了策略的域生效。对未部署该协议的域，发送方仍处于机会性加密状态——协议不会替那些域凭空变出安全性。它的保护范围以"对端支持并正确实现该协议"为边界，越出这条线，行为退回到 STARTTLS 的原始水准。
二、一条策略要经过几次查询才能拿到？——DNS 与 HTTPS 双信道的发布机制
MTA-STS 的策略发布横跨两条完全独立的信道。信道一是 DNS：在 _mta-sts.
信道一：_mta-sts TXT 记录（示意）<details> _mta-sts.example.com. 300 IN TXT "v=STSv1; id=20260116000000;"
信道二是 HTTPS：策略本体发布在 https://mta-sts.
信道二：mta-sts.txt 策略文件（示意） version: STSv1 mode: enforce mx: mail.example.com mx: *.example.com max_age: 604800
两条信道必须对得上：TXT 记录里的 id 与策略文件构成有效对应关系，id 不匹配会使策略整体被判无效；mx 字段列出的主机名是发送方验证对端证书身份时的比对依据。一次策略获取被拆成两次独立查询——先查 DNS TXT 得知"有策略"及版本号，再经 HTTPS 取策略本体，再校验 id 一致性，最后才按 mode 与 mx 列表约束投递。
为什么不直接把策略塞进 DNS TXT？TXT 记录在体积与表达能力上受限，而策略需要承载结构化字段（多个 MX、模式、有效期）。选择 HTTPS 是为了表达力与完整性，代价是引入了第二个可用性依赖。这个取舍的成本在 HTTPS 端点取不到时立刻显形：DNS 通告得再好，mta-sts 子域****证书过期或端点 503，策略依然拿不到。打个比方，这套结构类似包管理器的清单文件与制品仓库——DNS TXT 是清单，声明"有什么版本"；HTTPS 是仓库，提供实体；仓库挂了，清单写得再漂亮也白搭。
最容易排错排错方向的，是"DNS TXT 存在但 HTTPS 取不到"这个分支在 enforce 与 testing 下的不同行为。testing 模式下，取不到就是一条失败记录，投递照常进行。enforce 模式下则要分两种历史状态：发送方此前从未成功获取过该域策略时，它手里没有可执行的策略，不构成强制依据；发送方此前已缓存过一份有效策略时，按 RFC 8461，它继续执行那份旧缓存策略，而不是"因为这次取不到就放行明文"。反直觉的结论在这里：enforce 模式下"这次取不到策略"不等于"可以明文投递"——对已有缓存的对端，它比"根本没有策略"更严格，邮件会继续卡在 TLS 约束之后重试。这也是初级运维最常误判的一点：日志里看到的不是证书错误，而是策略获取失败，行为却像"证书错误"一样把邮件压住了。
双信道是 MTA-STS 最核心的结构特征，也是最主要的故障面。排查"策略不生效"时，必须先定位失败落在哪一段：DNS 记录未发布、记录格式错误（v 字段不是 STSv1、id 缺失）、HTTPS 端点不可达、id 与策略文件不匹配、策略文件字段不合法。这五类原因的排查手段完全不同——前两类查 dig，中间两类查 curl 与 TLS****，最后一类才是读策略文件本身。把所有现象都归因为"证书问题"，是这类故障排错的第一大效率杀手。
还有一条潜伏的依赖链必须点破：策略经 HTTPS 获取，而 HTTPS 本身依赖 WebPKI 信任链。这意味着 MTA-STS 的信任根最终落在公共 CA 体系上——这一点在第五节与 DANE 对比时会成为关键分水岭。
三、为什么"改小了 max_age"也撤不回一条错策略？——自引用缓存与生效时序
max_age 写在策略文件里，由接收方策略自己声明，表示发送方可以缓存该策略的最长时间（单位秒）。示意值 604800 对应一周量级。这是一个自引用结构：缓存时长由被缓存的对象自己规定。发布方对自己策略的缓存行为只有"声明权"，没有"撤回权"。它像一份自己规定了保质期的食品——生产商事后改标签上的日期，并不能缩短已经卖出去、正在顾客手里那批货的保质期。
策略内容变更时，协议给出的工程解法是另一套机制：必须同步更新 DNS TXT 记录里的 id。发送方通过观察到 id 发生变化，才决定重新去 HTTPS 拉取策略。这构成一个两层缓存模型——用"短 TTL 的 DNS 存在性声明"去驱动"长缓存期的 HTTPS 策略内容"更新：DNS TTL 管"策略还在不在、版本变没变"，max_age 管"策略本体缓存多久"。两套时间参数服务于两个不同的缓存对象，不可混为一谈。
由此推出本节最硬的一个结论：紧急情况下把 max_age 从较大值改为极小值，对已经缓存了旧策略的对端不生效。已经存在于对端缓存里的那份策略，其寿命由旧文件里写的旧 max_age 决定，新文件里的新数值要等对端重新获取之后才谈得上生效。撤回一条错策略，只能靠两条路：一是等旧缓存自然到期，二是变更 id 触发对端重新获取——但重新获取拉到的是新策略，不是"撤回"动作。协议里不存在"通知所有对端扔掉缓存"的信令。
一次策略变更因此必须同时动两处：策略文件本体（含新 max_age）与 DNS TXT 记录里的 id。只改策略文件不改 id，对端观察不到版本变化，继续用缓存，新内容永远不生效；只改 id 不改文件内容，对端会重新拉取到相同内容，但这一次会刷新缓存时钟——相当于把"旧策略的剩余寿命"重新拉满。只动一处的结果，要么是变更不传播，要么是错误策略的有效期被无谓地延长了一周。
反过来，max_age 设得过短也有代价。重取频率上升，直接带来 HTTPS 端点查询负载上升、单次获取失败概率上升，以及"取不到策略"这个状态出现的频率上升。而在 enforce 模式下，"取不到策略"恰恰是上一节那个会压住邮件的严格分支。max_age 不是越小越安全：它在"变更传播速度"与"获取失败暴露面"之间做权衡，缩短它等于把策略可用性的波动更频繁地传导到投递链路上。
把时序边界画清楚：从"运维决定撤回策略"到"所有对端都不再执行旧策略"之间，存在一段无法消除的延迟窗口，它由旧缓存的剩余寿命决定。运维能做的是把这段时间在设计要求内控制住（比如上线初期就配较短 max_age、保持 id 变更纪律），而不是指望任何一个参数把它消灭掉。
四、TLS 连接失败了，对端怎么知道？——TLS-RPT 的报告信道与日志识别
MTA-STS 能约束发送方，但接收方自己看不到"发往本域的投递在 TLS 环节失败了多少次、因为什么失败"——除非它自己主动探测。TLS-RPT（RFC 8460，SMTP TLS Reporting）解决的就是这个可见性缺口：让支持该协议的发送方把 TLS 连接情况以聚合报告的形式回传给接收方指定的地址。
报告接收地址同样走 DNS 发现，但那是一条独立于 _mta-sts 的记录——_smtp._tls.
信道三：_smtp._tls TXT 报告接收地址记录（示意） _smtp._tls.example.com. 300 IN TXT "v=TLSRPTv1; rua=mailto:reports@example.com"
三条信道至此必须分清：_mta-sts TXT 是策略存在性声明，/.well-known/mta-sts.txt 是策略本体，_smtp._tls TXT 是报告回传地址——三者是独立记录，可以只配前两个不配第三个。这意味着"部署了 MTA-STS 但没有报告通道"是一个完全合法的状态，此时接收方的可见性缺口在于：它只能看到自己主动探测的结果，看不到第三方发送方视角下真实发生的失败分布。
报告形态是聚合的，不是逐条告警。发送方按周期（RFC 8460 建议覆盖完整 UTC 日）把统计汇总成一份 JSON，经 gzip 压缩后作为邮件附件投递（媒体类型 application/tlsrpt+gzip），里面区分成功会话计数与失败会话计数。聚合而非逐条，是由邮件传输这个场景的量级决定的：失败频次高到逐条通知会造成告警疲劳，而报告本身也要占用邮件信道，逐条发送等于把观测流量灌进被观测的链路。
报告里的失败分类必须以 RFC 8460 的枚举为准，不能凭印象罗列。该协议把 result-type 分成三组，瞬态错误（网络繁忙、TCP 超时等）按 RFC 规定不要求上报；成功也不是一个 result-type，而是由独立的 total-successful-session-count 字段计数。具体枚举如下：
| 分组 | result-type | 含义（据 RFC 8460） |
|---|---|---|
| 协商失败 | starttls-not-supported | 接收 MX 不支持 STARTTLS |
| 协商失败 | certificate-host-mismatch | 证书身份不满足 MTA-STS 或 DANE 策略约束，如主机名不匹配 SAN |
| 协商失败 | certificate-expired | 证书已过期 |
| 协商失败 | certificate-not-trusted | 一类统称，覆盖不受信 CA、名称约束、证书链错误等；应配合 failure-reason-code 给出细因 |
| 协商失败 | validation-failure | 不属于上述类别的通用验证失败，同样配合 failure-reason-code |
| DANE 策略失败 | tlsa-invalid | 关联 DANE 策略的 TLSA 记录校验失败，RRset 中无有效记录 |
| DANE 策略失败 | dnssec-invalid | 递归解析器未返回经 DNSSEC 验证的记录 |
| DANE 策略失败 | dane-required | 发送方被配置为强制 DANE，但目标 MX 无 DNSSEC 验证的 TLSA 记录 |
| MTA-STS 策略失败 | sts-policy-fetch-error | 获取 MTA-STS 策略失败，如策略主机不可达 |
| MTA-STS 策略失败 | sts-policy-invalid | MTA-STS 策略整体校验错误 |
| MTA-STS 策略失败 | sts-webpki-invalid | 策略本身无法通过 PKIX（WebPKI）验证 |
对照这张表排日志，才能分清两个常被混为一谈的层次："MTA-STS 策略生效"指的是发送方查到了策略、id 校验通过、并按模式与 mx 列表做出了投递决策；"TLS 握手成功"指的是单次会话完成了加密。前者是策略层结论，后者是传输层结论，两者同时成立才算一次合规投递；sts-policy-fetch-error 与 certificate-host-mismatch 对应的是完全不同的故障域，不能都归为"TLS 失败"。
最后给 TLS-RPT 定个性：它是观测能力，不是防护能力。报告机制本身不阻止任何降级、不拦截任何失败——把它当成防护措施，与把监控当成防火墙是同一类错误。它还有一个自引用成本：报告本身是一封邮件，要通过 SMTP 投递；RFC 8460 专门规定，发送 MTA 在投递这些报告时不得遵守 MTA-STS 或 DANE TLSA 的失败判定，否则一个 TLS 配置坏掉的域会同时收不到失败报告——观测机制在被观测链路坏掉时会跟着失明。
五、MTA-STS 和 DANE 是同一条路吗？——两种信任锚的对比与共存
两者解决的是同一类问题：强化 SMTP 传输安全、防止降级、确认"对面确实是那个 MX"。把它们讲成"新与旧"或"二选一"，是这条线上最常见的认知偏差。真正的分歧不在时间先后，而在信任锚扎在哪里——是信公共 CA 体系，还是信 DNSSEC。
MTA-STS 依赖 WebPKI：MX 主机证书由公共 CA 体系验证，策略本体的 HTTPS 获取同样依赖 CA 信任链。DANE（据 RFC 6698 的规范）则把证书或公钥的指纹以 TLSA 记录形式发布在经 DNSSEC 签名的 DNS 中，把信任锚从 CA 体系整体移交给 DNSSEC。前者相信"全球 CA 网络签出来的证书是对的"，后者相信"DNSSEC 签名过的 DNS 记录是对的"——这是两套互不隶属的信任假设，不存在一方在协议层面"取代"另一方的说法。
部署门槛因此落在不同的基础设施上。MTA-STS 的工作量在应用侧：发布一条 DNS TXT、提供一个 HTTPS 端点、维护策略文件并管理 id 变更。DANE 的前提是本域 DNS 已经启用 DNSSEC——这是一个更靠底层、牵涉面更广、对 DNS 服务商与解析链路都有要求的前提。未启用 DNSSEC 的域，DANE 路线不可行；这一前提约束本身，就在很大程度上决定了两种方案的实际部署广度。
失败面的结构也随之不同。MTA-STS 把可用性风险压在两个点上：HTTPS 端点可达性、以及公共 CA 体系的证书有效性；DNS 在它的架构里只承担"存在性声明"这一轻量角色。DANE 则把信任数据本身放进了 DNS——一旦 DNSSEC 链路或解析出现问题，TLSA 记录的可获得性直接受损。两者把"信任失效"的风险分别押注在 Web 公钥基础设施****与 DNSSEC 这两套不同的基础设施上，故障面不重叠。
共存关系是明确的：两者不是替代，可以同时部署、叠加生效，发送方对同一目标可能同时具备两套可验证的信任信息。RFC 8460 的报告 schema 也为此预留了空间——一份报告的 policies 字段是数组，允许同时记录 MTA-STS 策略与 DANE TLSA 记录。但两套信息同时在场时谁优先、如何组合，取决于具体 MTA 的实现，不同软件处理方式不完全一致——涉及这一层时只能说"取决于实现"，不能给出统一的确定性结论。
回到开头那两个坑，它们各自对应的处方其实已经藏在这组对比里。初级运维卡在"加了 TXT 就完事"，缺的是对双信道第二次查询（HTTPS 端点、id 一致性）的检查；资深运维卡在"改了参数对方不听"，缺的是对 max_age 自引用语义与 id 变更纪律的理解。MTA-STS 的复杂度不在"配置三条记录"，而在承认这三条记录分属两条会各自传播、各自缓存、各自失效的信道——排错的第一步永远是先问：这次失败落在哪一条信道上。
浙公网安备 33010602011771号