摘要

  • RIPE 政策 ripe-705（2018 年生效，取代 ripe-563）要求所有 aut-num 对象及直接分配的 inetnum/inet6num 对象携带 abuse-c: 属性，指向含唯一 abuse-mailbox: 的 role 对象，并要求 RIPE NCC 每年至少验证一次该邮箱；验证仅限技术可达性，不检查举报是否被处理。
  • 政策提案 2017-02 明确把“邮箱工作但举报无人跟进”划出范围，理由是 NCC 无权干预资源持有者的内部滥用处理流程；提案 2019-04 曾提议收集并定期发布匿名化的升级统计，这一机制至今停留在提案层面。
  • RIPE 87 与 RIPE 90 的服务数据（2023 年 11 月、2025 年 5 月）显示验证工具不发邮件、每周检查约两千个联系人、失败率 6–8%，2024 年完成 2,445 次协助注册检查并执行约 5,500 项纠正——全部位于传输层。
  • 结论：被验证的邮箱是一个可用的入口，而非一套问责体系；用 RIPE 自己的文件即可证明，其全部已发布指标都停在传输层，而能区分“合规”与“问责”的流程层与治理层指标，要么不存在，要么只存在于未被实现的提案里。

政策如何只承诺入口

滥用投诉联系制度的法律骨架由两份文件先后搭建。ripe-563（2012 年，源自政策提案 2011-06）首次引入 abuse-c: 属性并使其对 aut-num 对象强制，但它不含任何验证要求——这一缺口正是后来社区反复指出的。2018 年生效的 ripe-705（源自提案 2017-02）补上了验证：abuse-c: 必须出现在所有 aut-num 与直接分配的 inetnum/inet6num 对象上，引用的 role 对象必须含唯一的 abuse-mailbox: 属性，该地址必须通过 whois 与 API 无限制可查，RIPE NCC 每年至少验证一次，对不合规条目按 RIPE 政策与程序跟进（ripe-705；ripe-563；实施时间线见 abuse-c Information）。数据库层文档同时说明了 abuse-c 在资源对象上会覆盖组织对象的取值，以及 -b 查询旗标可批量取回一段地址范围内的 abuse-mailbox（Abuse Contacts 数据库文档；abuse-c 常见问题）。

需要先做一处文献更正：早期检索曾把 ripe-686 标注为滥用联系人政策，但检索结果一致显示 ripe-686 是 2018 年收费方案，并非 abuse-c 政策；现行授权文件是 ripe-705。本文框架全部建立在 ripe-705、2017-02 与 2019-04 之上。ripe-658 则从投诉处理者一侧列出滥用联系信息的来源（ripe-658）。

验证工具到底测什么

RIPE 87 上公布的服务数据（2023 年 11 月）描述了验证工具的机制：它检查格式、DNS 与邮箱是否存在，但不发送邮件；每周检查约两千个联系人，失败率 6–8%；资源对象中的失效 abuse-c 会被替换为该 LIR 正常工作的 abuse-c（RIPE 87 NCC Services 演示材料）。更早的提案记录显示，当时 92.5% 的地址通过了自动化检查，且工具同样不发送邮件（提案 2019-04）。

到 RIPE 90（2025 年 5 月），数字扩展为：2024 年完成 2,445 次协助注册检查，约 5,500 项纠正行动（含 abuse-c 政策合规），成员服务工单上升 19.4% 至 32,514 件，并宣布计划把核验扩展到组织对象与注册库联系人（RIPE 90 Registry Highlights）。先前对验证战役本身的重建记录了逐年清扫规模——77,168（2019）、84,868（2023）、83,509（2024）、86,959（2025）——以及人工干预尾部从 649 增至 851 再至 899（BTW 先前报道，仅作先前覆盖语境）。这些是联系人质量指标，不是任何一封举报的处理结果。

出口由谁负责

注册机构在用户可见页面上明确划界：验证确保 abuse 联系人在数据库中有效且最新；处理举报是网络运营商的责任；“如果运营商选择不回复，我们无能为力”（如何查找滥用联系信息）。举报程序页面同样声明，来自 NCC 网络之外的垃圾邮件、钓鱼等网络滥用“不属于 RIPE NCC 作为注册机构的职责，不会被考虑调查”，只有数据库联系信息错误这类问题会被转交并跟踪（RIPE NCC Reporting Procedure）。提案 2017-02 把这一边界写进了政策推理本身：邮箱可用但举报未被按举报人期望处理，属于范围之外，因为 NCC 无权干预资源持有者的内部滥用处理流程（提案 2017-02）。

注册机构并非没有强制机器。ripe-858 为“不响应”成员规定了阶梯式终止程序：初始邮件（三个月内 SSA 终止）、30 天与 60 天提醒、第 90 天由总经理发出终止通知，随后进入注销与仲裁选项；“不响应”被定义为对 NCC 关于错误或含糊注册的特定请求不作反应，与其他请求的响应或继续付费无关。该程序要求 abuse-mailbox 地址有效——但触发它的是注册数据问题，而不是被忽略的第三方滥用举报（ripe-858）。

四层框架

把上述文件放进一个统一框架，可以区分四种被分开出售、也常被混为一谈的“响应性”：（a）传输层——邮箱能否收到邮件；（b）内容层——回复是否针对具体案件，还是模板化自动回复；（c）流程层——案件是否有处置记录，关闭是否与可审计的整改结果挂钩；（d）治理层——是否存在带命名角色与阈值的书面升级路径，以及升级是否发生过。按此框架逐层核对 RIPE 自己的发布记录：传输层有年度验证、有失败率、有逐年清扫数字；内容层与流程层没有任何公开测量；治理层唯一被提出过的测量机制——2019-04 提议收集并定期发布匿名化的升级统计——从未离开提案状态。已发布记录因此证明了联系人数据的合规性，而非举报的处理。

来源与限制

本文不声称掌握任何针对 RIPE 区域 abuse-mailbox 的实测投递率、回复内容、工单处置或升级路径使用数据；它呈现的是一个评估框架加上注册机构自己发布、经检索核对的文件与数字。RIPE 87 与 RIPE 90 的数字来自演示文稿的检索摘要，未全文核读；2019-04 的提案状态依据提案页面元数据，是否曾有匿名升级统计被发布，本文未能确立。文中对注册机构页面的引用是对立当事方的陈述，按其语境如实转述，不作为问责成立的证明。ripe-686 被确认为收费方案而非滥用联系人政策，仅用于文献更正。