摘要

  • 2026 年 9 月的邮件迁移中，IETF 全局审核名单漏掉了已确认、却没有订阅任何邮件列表的地址；这些地址发出的邮件被扣在审核队列里。
  • 系统把“确认地址可发信”和“订阅某张列表以接收邮件”两种状态混为一谈。IETF 表示，修复方式是从全部已确认地址重建名单。

新邮件闸门拿收件名单当宾客名单。没有订阅的人即使已经拿到通行证，也被拦了下来。

IETF 执行主任 Jay Daley 在 9 月 25 日说明了这个故障：全局审核白名单没有收录那些已经确认、但未订阅任何邮件列表的地址。从这些地址发出的邮件会进入人工审核。修复后，名单按所有已确认地址重建。

确认地址和订阅列表回答的是两件事。确认表示地址持有人完成了系统发出的挑战；订阅表示持有人想接收某张具体列表的邮件。有人可以确认地址以便参与讨论，却不想每天收几百封邮件。前者证明地址通过发信验证，后者设置收件偏好。迁移程序却让后者冒充前者。

这不是某个邮件管理员的小毛病。IETF 运行五百多张邮件列表，并表示大部分工作通过这些列表开展。第一次订阅或首次发信需要完成挑战响应。迁移公告解释了原因：首次确认也用于记录参与者接受 Note Well 的规则。系统已有这份证明，重建名单时却把它扔在门外。

收件偏好不是发言许可

迁移前，邮件服务维护已完成确认挑战的全局地址记录。新架构中的组件会检查发件人是否已经批准；若是新地址，系统先保留原始邮件，等待地址持有人回应。验证通过后，邮件释放，地址也记录为之后可以使用。

故障发生在重建全局审核名单时。那些没有出现在任意订阅名单里的已确认地址，从名单里消失。列表看到发件人不在预期的审核表中，于是把邮件扣下来。官方说明列出了现象与修复。

系统缺陷本身已经清楚：订阅关系不是地址已通过发信挑战的证据。

一次迁移，八项修复，两项挂账

Daley 列出截至 9 月 25 日已修复的八项问题，以及仍在处理的两项。带有 Precedence: Bulk 标记的邮件曾被静默丢弃，主要影响 IANA。带 BATV 标记的邮件有时被误认为来自 IETF 中继。带大写字母的已确认地址被要求重新确认。某些特殊发件人格式的兼容规则根本无法运行；部分 Outlook 格式触发解析失败；Postorius 通知里的站点所有者栏为空；DMARC 在收件人过多的情况下也会失败，导致邮件无法送达。

未结项涉及退信和垃圾邮件。有一批无法送达的地址仍在订阅列表中；新的退信处理会停用账户，其中一些结果看起来有误。运维人员暂停处理，并在调查期间重新启用被停用的地址。Mailman 的 VERP 机制本用来识别哪位订阅者产生退信，但在这套系统里让处理速度慢了四到五个数量级，因此也被关闭。Rspamd 的规则仍在调校，因为上线后有过多垃圾邮件漏过。

迁移的责任链也值得看。邮件系统三年前立项，经历多次问题后改由新承包方收尾。Daley 说，早期项目留下的核心组件未被重写，其缺陷也未能在上线前发现。他写道：“那是我们的错误。”这句话有用，因为它指向具体遗留组件和缺失的上线检查。

邮件列表是标准制定的工作台

RFC 2418 写明，工作组大量工作通过邮件列表进行。邮件让无法参加现场会议的人也能参与；工作组流程必须容纳只能在线参与的贡献者。邮件存档公开，RFC 6778 对存档、网页浏览和搜索提出要求。

接收邮件与发出邮件因此不能共用一个状态。前者决定什么进收件箱；后者决定贡献能否进入工作讨论。反垃圾邮件和地址验证仍然必要。开放列表并不等于接受伪造发件人；它要求系统记住合法参与者已经完成验证。

公开记录的运行后果很具体：已确认发件人的邮件进入人工审核，等待运维人员放行。说明没有列出受影响地址和邮件数量，也没有审核耗时；这些记录将区分零星卡顿与更广范围的中断。邮件闸门把收件偏好当成了发言许可，最后让真人来拆解这个错误。

修复应保留状态边界

Daley 说，允许名单已重新囊括全部已确认地址。迁移公告还称，计划切换期间邮件存档和 IMAP 访问没有受影响。修复范围不大，却恢复了邮件列表闸门真正需要查询的状态。

一套邮件服务会分别记录地址确认、列表订阅、审核状态、退信、发件人重写和存档状态。这些字段各自回答不同问题。迁移时把它们合并，或许能少做一次转换；转换不完整时，也可能顺手抹掉另一个系统已经完成的工作。

可复现的验收场景很明确：一个已确认但未订阅的地址向开放列表发信；再单独测试有访问限制的列表；切换后核对审核、送达与归档结果。若只拿活跃订阅者做测试，盲点就会安然通过。

IETF 邮件列表不是技术流程旁边的装饰。它们承载辩论、流程公告和会后仍然存在的记录。反垃圾邮件闸门可以挡住伪造发件人，也可以让已确认的参与者发言。区别只在两种状态是否分开保存。迁移时，邮件系统只记住了其中一种。

来源