摘要

  • IETF 执行董事 9 月 25 日表示，退信处理已暂停，此前因退信被停用的地址均已重新启用，等待问题修复。
  • 旧系统没有把退信送入邮件列表的处理环节，留下确实无法送达的地址；新系统又出现部分可能错误的退信通知。两类情况同时存在。
  • 公告没有给出受影响地址数量、错误退信比例、重启日期，也没有证明重新启用的地址全部可达。

邮件列表负责人收到“订阅者因退信过多被停用”的通知时，系统已经替他们作出了一项参与状态决定。9 月 25 日的 IETF 公告并非只说新邮件平台还需调试；它明确说，退信处理已被关闭，所有因此前处理而停用的地址都已重新启用。这是对自动化结果的撤回。名单上的地址恢复活跃，不意味着邮件已经补发，更不意味着每个邮箱现在都能收信。

为什么不能简单把停用全部判为误报？IETF 指出，旧基础设施没有把退信传到列表处理流程。因此，许多早已无法送达的地址仍保留订阅，新系统接手的是一笔真实的历史积压。与此同时，机构掌握了部分退信通知可能不正确的证据。若按通知直接停用，就可能把仍能接收邮件的人排除在日常列表通信之外。若一概忽略退信，积压也不会自行消失。公告没有拆分两类地址的规模；读者不应替它算出一个“全部误停”或“全部无效”的结论。

时间顺序也限制了对改造结果的判断。IETF 9 月 11 日宣布模块化邮件系统迁移完成，把更好的退信处理列作预期收益。两周后的执行董事说明才是当前状态的依据：退信处理暂停，另一项仍待解决的问题是垃圾邮件过多。公告还列出八项已修复问题，包括部分带 Precedence: Bulk 标记的邮件曾被无声丢弃。这些问题不能合并成一个退信事故，更不能据此推算个人漏收邮件的数量。VERP 也在调查期间停用；公告关于处理时间变化的句子方向不清，不能用它宣称系统变快或变慢。

IETF 自己说明，机构的大部分工作发生在五百多个邮件列表上。能否收到列表邮件，直接影响一个人能否跟上技术讨论。Mailman 的上游文档区分退信事件、暂停送达以及后续提醒；它只解释通用软件机制，不能证明 IETF 当前用了什么阈值或哪条地址具体遭到何种处理。正因如此，公众需要看到的是可审查的判断边界，而不是从软件功能名称推断结果。

恢复自动处理前，一个有限而有用的说明应回答：哪些证据足以认定地址不可达，怎样隔离疑似错误通知，停用后由谁复核、如何恢复？Daniel Kade 建议留下按类别和决策节点记录的处置依据，同时不公开私人地址、退信原文或安全规则。这是编辑提出的治理检验，不是 IETF 已发布的新制度。公告没有披露内部核查的全部内容，也不能据此断言内部没有核查。

资料来源