摘要

  • IETF 9 月 25 日的通报列出切换后修复的八项故障，包括已确认发件人被送去审核、批量邮件被丢弃，以及 DMARC 导致的投递失败。
  • 退信问题暴露出旧系统积压的一批地址。新流程开始依据可能有误的退信停用订阅者后，IETF 暂停了处理，并重新启用受影响地址，等待修复。

先出现的是成功公告。9 月 11 日，IETF 表示新邮件基础设施切换已经完成。公告介绍了拆分部署的邮件过滤和重写功能、Kubernetes 调度、新的垃圾邮件软件、改进的证书处理，以及更好的退信处理。当天更新了标题和导语，宣布工作完成；大部分技术细节仍来自 8 月 28 日的原始说明。

这记录的是切换时点，不是运行情况。

运行通报在 9 月 25 日发布。IETF 执行主任 Jay Daley 表示多数问题已解决，并将八项列为修复、两项列为仍在处理。他还披露，项目三年前就已委托开展，期间多次遇到问题，后来由新承包方接手完成。原项目中的一个核心组件没有被新承包方重写，其中的缺陷也没能在上线前发现。Daley 写道：“这是我们的错误。”

这些并非一次壮观的全站故障，而是邮件列表与真实发件人之间一些不起眼的规则。一名已确认身份、却未订阅目标列表的发件人，未被写入全局允许列表，投稿因此进入人工审核。Precedence: Bulk 邮件在没有通知的情况下被丢弃，主要影响 IANA 邮件。BATV 地址处理错误。已确认的大写邮箱被当作新地址，要求重新确认。识别特殊发件人的规则无法触发。部分 Outlook 的 From 名称被拆成两段，第一段还被错误拼上 IETF 域名。Postorius 管理界面因站点所有者字段为空，通知使用了占位发件地址。DMARC 重写也会在某些收件人数下失效。

执行主任称以上八项已修复。这个数目是被点名的故障数量，不代表所有投递失败或受影响参与者的规模。通报没有提供相应分母。

更棘手的问题在退信处理。旧基础设施存在结构性限制，退信无法抵达列表供系统处理。因此系统不会停用对应地址。结果是，一批被描述为已经无法到达、却仍留在订阅名单上的地址积累下来。新流程开始清理时，列表负责人收到许多通知，称订阅者因退信过多将被停用。

此时，机器有了队列，也给出了判定，却还没有可靠的判定。IETF 表示，有迹象显示一些退信是错误的。它随即停用退信处理，并重新启用了此前因此被停用的全部地址，等待问题修复。短期内，它宁可保留一个可能已经失效的邮箱，也不让自动流程误删仍在使用的订阅者。这是明确的保护决定，却不能证明积压已经消失。

同一份通报还记录了另一项性能意外：Mailman 默认的 VERP 模式让邮件处理时间慢了四到五个数量级，IETF 因此在调查期间停用 VERP。公告没有给出基准时长、测试负载或绝对延迟。新垃圾邮件过滤器 Rspamd 仍在调整，因为仍有过多垃圾邮件通过。

事件顺序很重要。9 月 11 日的公告把改善退信处理、减少垃圾邮件机会列作预期收益。9 月 25 日的记录则说明，意图容易写，运行证据难取得：新处理暴露出历史积压和可疑信号，垃圾邮件过滤也还要调校。模块化的新基础设施既不会自动抹掉旧数据债务，也不会让第一批自动判定凭上线公告就变准确。

依赖公共邮件列表工作的组织都能从这次经历中看到一条清楚的界线。迁移完成是一个有日期的事件。可靠投递则要在发件人身份、审核、列表展开、地址重写、身份验证、退信判读和收件人到达等环节反复成立。每一站都可能通过自己的测试，最终邮件仍可能在下游失败。

公开通报让人看见了控制决定，却没有说明代价。IETF 没说重新启用了多少地址、多少退信被证实有误、退信处理停了多久、VERP 的测量基准是什么，或 Rspamd 何时完成调校。这些数字会改变我们对服务恢复程度的判断。现阶段能够确定的是：IETF 在退信证据不可靠时停止自动停用订阅者，并公开说明了这项纠正。

来源