摘要

  • AFPUB-2026-GEN-004-DRAFT01 仍在讨论，提案把摘要回复造成的线程元数据丢失列为问题。
  • 草案将摘要订阅与列表总流量挂钩；RPD 当前订阅页仍提供每日摘要。

邮件摘要把多封来信合并成一封。读者直接回复摘要时，回复可能丢失原讨论的线程元数据，后续发言就难以归回同一主题。AFRINIC 在提案中把这列为问题，解决办法却转向发件量：列表此前两个月日均超过20封，才可开放摘要订阅。

把这条线和官方档案放在一起，差距很直观。提案于10月17日提交；往前数60天，也就是8月18日至10月16日，RPD 档案有173封独立邮件，日均2.88封，约为门槛的七分之一。按日均20封换算成60天，档案要达到约1200封才碰到门槛；眼下只有173封，约为目标的14%。这道开关瞄准的是总流量，草案点名的故障却是摘要回复丢失线程信息。20封这个数值没有公开推导过程。

读者在摘要里点“回复”，遇到的不是抽象的流量曲线，而是回复被丢弃，再收到一封自动通知，指向原信或新开主题的正确做法。3.4.1.3把这段恢复路径交给 AFRINIC 运营方配置；前两项则要求参与指南与 Mailman 版本公开，并以发件量决定摘要订阅选项。换句话说，运营方要把一条总量门槛接到订阅开关上，用户则要在回复被拒后自己找回讨论。

当前 RPD 页面显示 Mailman 2.1.15，仍提供每日摘要；提案目录则将新规列为讨论中。现在的订阅开关没有随草案改变，订阅者仍能在页面选择摘要。

公开档案能统计发件量，却没有摘要订阅人数，也没有被断开线程的记录。眼下可核实的结论很窄，也很硬：提案用一个约为档案日均近七倍的流量门槛，处理一个没有公开发生频率的线程故障。它量的是邮件总数，不是断线。

来源