摘要

  • IETF 已把邮件服务切换安排在 2026 年 9 月 11 日，预计邮件可能延迟最多 60 分钟，Mailman 网页界面将暂时不可用。切换尚未发生，因此这些是计划和预期，而不是已经验证的结果。
  • 新发件人完成挑战后，postconfirm 可以把暂存邮件重新送回邮件系统。这只证明一个本地规则获得满足，并不能证明列表接收、身份改写正确、签名有效、出站传输受保护或订阅者已经收到。

设想一封在维护窗口进入系统的投稿。postconfirm 发现发件人从未通过挑战，于是保存原始邮件并发出验证。发件人回复后，状态变为允许，邮件被重新注入。暂存队列少了一封，监控图表随即恢复绿色。

但邮件可能正在等待 Mailman，也可能在地址改写阶段被拒绝，或者已经完成签名却堵在某一台出站中继后面。队列减少只说明邮件离开了一个位置；它没有说明邮件进入了哪个位置。

IETF 8 月 28 日的公告把切换时间定在 9 月 11 日 22:00 UTC，覆盖 IETF、IAB、IRTF 与 RFC Editor 的邮件域。公告称切换期间列表网页界面不可用，存档与 IMAP 不受影响。它还提出更好的退信处理、减少垃圾邮件机会、消除开放中继风险等目标。所有这些都需要切换后的运行证据，不能由架构说明提前兑现。

邮件离开暂存区，只完成了一次保管转移

新架构让各项功能运行在 Kubernetes 调度的容器中，并通过 milter 协议协作；出站邮件则由多台独立虚拟机中继。postconfirm、Rspamd、地址改写、DKIM、DANE 证书管理与退信处理因而拥有各自的责任边界。

postconfirm 项目说明，未知发件人的邮件会在挑战期间保存；挑战成功后，发件人进入接受状态，保存的邮件被送回邮件系统。项目还区分 reject 与 discard：后者可能向 SMTP 客户端返回成功，却丢弃邮件。因此，“SMTP 成功”如果没有标明哪个组件、哪一种动作和哪一封邮件，就不能充当总回执。

切换台账至少要保留邮件指纹、入库时间、挑战状态、过期时间、放行尝试和重新注入确认。相邻服务必须确认同一指纹。只看队列长度，会把正常推进、过期清理与无解释消失混在一起。

改写后的身份是一项新事实

邮件列表由新的基础设施再次分发，原域的 SPF 策略未必授权这些出站地址。公告称，改写服务会检查 SPF 与 DMARC，并在必要时改写信封或头部发件人，再用相应域的 DKIM 密钥签名。

SPF说明某台主机是否符合域发布的发送策略；DKIM证明签名域对选定且规范化后的邮件材料作出签名，规范也明确签名者未必确认个人身份；DMARC结合标识对齐和接收策略，但不解决仿冒显示名与相似域名。

因此日志应同时记录改写前后的标识、触发分支的证据、签名域与选择器、受签字段以及下游验证结果。IETF 控制域下的有效签名，可以证明该签名者对签名形态负责，却不能倒推原始作者的真实身份、权限或陈述真伪。

下一张证书已经就位，不代表远端已经用上

公告中的 current + next 3 1 1 轮换方案，目的是在证书切换时始终保有可用于 DANE 的证书。danebot公开材料展示了 current 与 next 的分离处理。这是内部准备的证据。

真正的传输观察发生在远端。SMTP DANE让发送 MTA 通过 DNSSEC 验证的 MX 与 TLSA 发现 TLS 并认证下一跳。RFC 明确没有覆盖全部 SMTP 流量，抗降级又依赖 DNSSEC。运营者需要分别检查预期密钥、解析器实际看到的 TLSA、端点实际提供的证书，以及旧状态和新状态下的客户端握手。Kubernetes Secret 中有下一张证书，不等于互联网已经能使用它。

接受意味着承担有限责任

SMTP规定，接收方在 DATA 后回复 250 OK，便承担投递或中继责任。这比进程健康更强，却仍不是最终阅读证明。投递状态规范明确指出，delivered 可以只是交给邮件列表展开器，而且不表示邮件已被阅读；relayed 与 expanded 的责任又不同。

所以切换证据链必须点名每个说话者：入口 MTA、postconfirm、列表管理器、改写器、签名器、出站中继、收件 MTA 与测试邮箱。没有退信不等于已经送达，Pod 健康不等于下一条队列在前进，共享消息编号也不能在记录冲突时替代裁决。

这正是恒路所说的现实层级：配置、本地状态、协议接受、外部效果与用户结果不能互相冒充。运行代码优先要求在真正有能力接收、改写或投递的边界取证；数据的实际控制则属于能够读取队列、旋转密钥、恢复邮件和解释身份映射的人。

如果模块化让每一次保管转移都可以对账，它就是进步。如果它只是产生更多绿色面板，邮件仍可能消失在面板之间。

来源