摘要

  • RIPE NCC 按 ripe-705 的要求至少每年验证一次 abuse-mailbox 属性，但自动检查只确认语法、域名和邮件服务器配置，而不是有人真的回应。
  • 公开文件描述了从书面通知、30 天与 60 天提醒，到 90 天后通知管理董事可能终止服务协议、注销资源记录并吊销 RPKI 证书的完整终局序列，但既有记录显示该序列长期未被真正触发。
  • 制裁范围按对象类别并不对称：对 LIR 组织对象可以导致成员资格关闭与资源注销，而对 LIR 资源对象和终端用户对象，登记机构只会在 RIPE 数据库中加一条注释。

一个每年运行、却无法证明结果的检查

RIPE 数据库要求每条资源记录带一个专门的滥用联系人，即强制的 abuse-c 属性。这项要求通过 ripe-705 落地，该文件同时规定 RIPE NCC 必须至少每年验证 abuse-mailbox 属性，并在认定该属性不正确时跟进处理（ripe-705）。

关键在于这个检查测什么。2017-02 提案于 2018 年 6 月 1 日达成共识，并在 2019 年 10 月 10 日被记录为全面实施；实施说明明确其自动化验证针对技术参数，例如语法、域名和邮件服务器配置，而不是人的回应行为（2017-02 提案页）。

因此，一个注册了可用域名、邮箱能接收探针邮件的 abuse 地址可以通过检查，即使该邮箱背后的工单系统从不处理任何上报。2021 年 11 月的进展报告把流程描述为已进入稳定状态：每周检查约 2,000 个联系人，其中约 6% 至 8% 未通过；年度范围覆盖约 19,600 个 LIR 组织对象、约 58,100 个 LIR 资源对象，以及约 15,400 个独立资源（RIPE 87 AAWG 材料）。这些数字描述的是联系人簿记的健康度，不是滥用处置的效果。

已经写明、却长期未使用的最终制裁

RIPE NCC 公开文件描述的终局序列相当完整：先是书面违规通知并给出三个月期限，随后在第 30 天和第 60 天发出提醒，若仍未解决，则在第 90 天通知管理董事，服务协议可能被终止，随之注销资源记录并吊销 RPKI 证书（ripe-858）。这是一条有明确节点、可被审计的流程，而不是一句笼统的威胁。

问题在于可查证的触发记录。在年度验证机制存在之前，登记机构每年会收到数百份关于滥用联系人信息失效的举报；RIPE NCC 同时说明，在过去五年中它调查并解决了 1,000 多份关于 abuse-mailbox 属性不正确的对外举报，而从未触发它所称的“最后手段”——关闭与注销程序（2017-02 提案页）。登记机构把这项制裁定位为最后手段是正确的；值得记录的观察是，公开材料并未显示它曾被使用。

谁真的会被追责：对象类别的不对称

同一套发布的升级说明按对象类别划分了完全不同的后果。对于 LIR 组织对象，不回应或拒绝配合最终可能导致成员资格被关闭、资源被注销，并且从关闭程序启动起，LIR 还有三个月时间更新其滥用联系人，否则成员资格将被终止。但对于 LIR 资源对象和终端用户对象，登记机构表示不会终止成员资格或赞助关系，而只会在 RIPE 数据库中加一条注释，说明该滥用联系人未通过验证（RIPE Labs：后续处理失效滥用联系人）。

这一区分把“可执行性”与“舆论压力”分开：真正可能失去号码资源的是成员组织本身，而承载实际流量的大量资源对象和终端用户对象，最终承受的只是数据库里一行公开标注。

数字很精确，衡量对象却不是处置效果

实施数据是公开且具体的：首轮全量验证覆盖 77,168 个不同的 abuse-mailbox 属性，其中 71,711 个（93%）通过自动验证，5,457 个（7%）未通过；2019 年共更新约 8,000 个 abuse-mailbox 属性，工作量在数月内需要三名临时全职人员，且 20% 至 25% 的工单需要人工跟进（RIPE 79 实施摘要）。更早的一份进展报告给出另一组口径：约 60% 的案例无需工作人员介入即解决，约 67,000 个被检查的联系人中有约 9,500 个被更新，另有约 50 个独立资源变更了赞助状态（RIPE Labs：abuse-c 验证进展与若干数字）。

分组数据同样公开：2019 年年中的分类统计显示，LIR 组织地址已完成验证 18,200 个，产生 3,500 张工单，其中 1,400 张人工处理；LIR 资源地址完成验证 3,200 个，产生 200 张工单，40 张人工处理，并新增 100 条数据库注释；终端用户地址仍在验证中，13,500 个产生 1,200 张工单，350 张人工处理（RIPE 78 abuse-c 更新）。

这些数字之间的变化本身值得注意：验证前的抽样估算认为 10% 至 25% 的约 70,000 个 abuse-mailbox 属性可能失效或无人值守；2018 年针对 900 个 LIR 组织对象的试点中，187 张工单（约 21%）中 106 张无需人工介入即解决、81 张需人工跟进；到 2019 年完成的整轮中失效率降至 7%，2021 年周度检查中约 6% 至 8% 未通过（2017-02 提案页、RIPE Labs：后续处理失效滥用联系人、RIPE 79 实施摘要、RIPE 87 AAWG 材料）。

空白处正是这里：每一组数字测的都是属性是否“看起来有效”，没有任何一组显示收到的举报被处置。后续一份政策提案自己也承认，现有检查无法证明滥用邮箱在实践中真的可用；其影响评估文本明确写道，该政策的目的并不是审查滥用案件如何被监控或处理，并预计完整的一轮循环可能需要超过 32,000 张工单，其中约 19,200 张需要人工核查（2019-04 提案页、RIPE 80 材料）。同一份材料重复了 77,168 个属性、93% 通过、7% 未通过以及 2019 年约 8,000 个属性被更新的标题数字，说明这些前置统计在后续社区讨论中并未被修正（RIPE 80 材料、RIPE 79 实施摘要）。

判断“修复是否持久”需要什么证据

要证明 abuse 联系人机制产生了持久的补救，而不是联系人簿记，需要几类公开证据：验证之后上报量的变化；未通过验证的对象在 90 天节点上实际被终止服务的记录；以及资源对象与终端用户对象在被标注注释后，其滥用举报模式的走向。目前发布出来的材料没有提供任何一项。

这不构成对登记机构诚意的指控，而是对可核查性的界定：一项被写进政策、带有明确期限和后果的制裁，如果在公开记录中长期无触发实例，那么它的实际约束力就仍是未经验证的。

关于本条目所属的目录对象，可见 RIPE ABUSE 目录条目。