摘要

  • _mta-sts TXT 中的 id 只通知发送方重新抓取。它不包含或签署策略，也不能证明所有发送方已经刷新，更不能瞬间撤销尚未到期的旧缓存。真正被某个发送方执行的是一次经 HTTPS 认证、带抓取时间和本地到期点的具体策略字节。
  • 可复核的决定必须连接策略域、DNS 观察、策略主机证书、原始文件、缓存谱系、MX 顺序、STARTTLS、收件服务器证书、队列重试与最终处置。enforce 只约束一次 SMTP 运输选择，不证明邮件已送达、端到端保密、用户身份或业务授权。

“最新策略”不是一个全球状态

开篇是负向测试，不是事故报道。收件方看到 TXT 和网页都已更新，很容易认为迁移结束。甲看到新 id，认证 mta-sts.<域名>，下载新文件，从此拥有一段新的缓存寿命；新文件允许备用 MX。

乙无法刷新。RFC 8461 的抗降级设计要求：只要本地仍有未过期的有效缓存，即使实时 DNS 或 HTTPS 失败，也必须继续应用它。旧文件没有备用 MX，乙就应把该候选视为无效并暂缓投递。若刷新失败且从未取得过有效缓存，结果反而不同：发送方按未部署 MTA-STS 处理。

因此，不能只用收件域此刻的网页审计历史投递。决定时证据应回答：哪一个发送进程，在什么时间，凭什么认证了哪一组字节，并把它们视为仍然有效？

DNS ID 只负责提示变化

MTA-STS 把发现信息与策略正文拆开。_mta-sts.<策略域> 的 TXT 记录携带版本和实例 id；IANA 登记这些字段，使实现能够共享语义。登记不为某条记录背书，也不证明任何厂商已经执行。

id 不是文件摘要，不绑定 mode、mx 或 max_age。它不能说明新文件是否先于 DNS 变化部署，也不能说明不同权威 DNS 视图、CDN 节点和发送区域拿到相同内容。

顺序因此具有权限后果。先改正文却不改 ID，大量发送方会合法地留在旧缓存；先改 ID 后改正文，一部分发送方可能把旧正文重新抓取为一段新的有效寿命。只记录当前 TXT 值的仪表盘展示的是意图，不是被执行的事实。

HTTPS 把一份正文变成可用策略

策略固定放在主机 mta-sts.<策略域> 的路径 /.well-known/mta-sts.txt。发送方通过 PKIX 认证策略主机：证书在有效期内，链至其信任的根，DNS 身份与策略主机匹配。HTTPS 连接的 SNI 是策略主机，而不是之后连接的 MX。

文件提供版本、模式、寿命和允许的 MX 模式。除 none 外，至少要有一个 mx。证据库应保存原始响应、哈希、抓取时间、Content-Type、证书链、主机名验证、信任库版本、解析结果和到期计算，而不是只保存解析后的“已启用”。

首次接触仍有边界。如果攻击者压制 TXT 或 HTTPS，而发送方没有缓存，MTA-STS 不能凭空生成权威策略。它依靠一次成功的 HTTPS 获取建立后续抗刷新干扰能力；它没有把未签名 DNS 中的“没有记录”变成经过认证的不存在。

max_age 让多个现在同时成立

寿命从每个发送方成功抓取的时刻开始。它不是全网共用的截止钟。区域解析、网络可达性、进程重启、缓存复制和主动刷新节奏，会让相同文件产生许多不同到期点。

这是连续性机制，也是错误的耐久机制。若遇到刷新失败就删除缓存，攻击者只需阻断策略主机即可解除约束；若长期策略写错，一次成功抓取又会让错误在修复可见页面之后继续生效。

退出必须先发布通过 HTTPS 验证的 mode: none，使用较短寿命，修改 ID，并等待所有可能重叠的旧寿命结束，再撤掉 TXT 与策略端点。直接删除记录不是撤销；它可能留下仍在执行的旧 enforce，同时切断发送方取得解除策略的通道。

enforce 授权的是一条窄路径

发送方先按普通 MX 优先级遍历候选。候选主机名必须匹配已应用策略中的一个 mx；通配符只能覆盖最左边的一个完整标签，不能覆盖域名本身或两级标签。然后该主机必须提供 STARTTLS，SMTP SNI 携带 MX 主机名，证书未过期、链至发送方信任根并匹配该 MX 身份。

这些事实只证明某个发送方通过一条经过认证的 TLS 连接抵达允许的下一跳。它们不认证邮件作者、收件箱用户或内容，也不说明后续中继是否端到端保密。

错误候选应像暂时不可达一样处理，并继续正常 MX 顺序。遗漏的备用 MX 可能平时完全不显现，直到主节点故障才造成投递阻塞。因此只验证主 MX 的设置绿灯不等于策略完整。

队列决定了失败会造成什么

enforce 禁止向 MX 不匹配、没有 STARTTLS 或证书验证失败的主机投递，但不自动授权立刻永久退信。在永久失败前，发送方必须再次查询是否出现新策略 ID；否则沿用 SMTP 暂时失败与重试规则。

暂缓为收件方修复 MX、证书或策略保留时间；永久失败则关闭交易。审计必须同时保留队列 ID、策略哈希、候选顺序、具体失败、下次重试、最终 ID 检查和最后处置。只有 TLS 握手日志，无法证明邮件层发生了什么。

报告不是单封邮件的回执

RFC 8460 的 TLSRPT 可以汇总发现的策略、成功和失败会话及故障类型。Google 与 Microsoft 的当前文档展示了实际执行与报告界面，证明标准存在运行中的消费方。

报告覆盖仍取决于哪些发送方实现、哪些报告成功抵达、各组织如何聚合。一天的失败计数不是某封邮件的送达证明，也不能证明邮件被阅读、保存、在全部中继上保持秘密或获得后续业务批准。

需要对账的是三张表：收件方发布了什么，发送方实际执行了什么，报告方观察到什么。任意一张都不能单独升格为全局真相。

DANE 与 REQUIRETLS 划出相邻边界

SMTP DANE 使用 DNSSEC 和 TLSA 建立另一条认证路径。RFC 8461 明确禁止用 MTA-STS 覆盖失败的 DANE 验证。PKIX 路径成功不能成为绕过更强失败状态的借口。

REQUIRETLS 又是另一种权限：它表达单封邮件发起者的运输要求，并依赖支持它的中继。MTA-STS 是收件域向支持者发布的域级策略，不表达某封邮件的敏感程度。两者即便成功，也不会自动产生端到端内容加密。

因此，“MTA-STS 通过”不能被洗成“发件人要求保密”“收件方已接受”“用户已收到”或“业务交易已批准”。运行证据必须停在机制实际控制的动作上。

可重放的判定单元

最小证据单元以策略域、发送方、投递尝试和时间为键，连接 TXT 原文、ID、TTL 与 DNSSEC 状态；HTTPS 响应与证书；策略哈希、模式、MX、抓取与到期；MX RRset 和遍历顺序；SMTP SNI、STARTTLS 与证书结果；DANE 状态；队列变化；刷新与最终 ID 检查；TLSRPT 关联以及最后处置。

负向测试应覆盖：正文变而 ID 不变；ID 先于正文；有缓存和无缓存时分别阻断 HTTPS；缓存过期；主 MX 故障转入备用；策略主机证书错误；MX 证书错误；发布 none；以及 DANE 失败后企图以 MTA-STS 放行。

薄规则只定义共同语言；收件域发布提议；PKIX 认证某次抓取；发送方给它本地寿命；真实 SMTP 路径进行检验；队列赋予后果。最新 DNS 字符串没有更大的权限。

来源