摘要

  • RIPE 数据库的滥用联系人制度源于 2011 年获社区通过的政策提案 2011-06：每个资源对象通过 organisation 对象引用一个含受保护 abuse-mailbox 属性的 role 对象，维护责任落在资源持有者（LIR 或代理 LIR）身上。
  • 在成员未行动时，RIPE NCC 曾于 2013 年 12 月起代设占位 abuse-c——直接使用成员名录中的邮箱地址；2014 年 11 月起又为被赞助资源代填赞助 LIR 的滥用联系人。
  • 2016 年，RIPE NCC 自己承认："abuse-c 在 RIPE 数据库模式中并非必填属性"，政策层面的强制与模式层面的执行之间存在被文件记录的落差。
  • 验证数据是量化的：RIPE 87 会议记录显示约 90,000 个不同 abuse-c 联系人、每周约 2,000 封验证邮件、6%–8% 失败；RIPE 80 显示 77,168 个属性中 93% 通过、7% 未通过——但验证只测试邮箱能否收信，不测试是否有人处理。

一条从提案到数据库的责任链

abuse-c 制度的起点是一份 2011 年的社区政策提案。提案 2011-06 规定：inetnum、inet6num 与 aut-num 对象引入 abuse-c 属性，引用一个包含 abuse-mailbox 属性的 role 对象；abuse-mailbox 在被任何资源对象引用期间受保护、不可删除；实现分两个阶段——先对新对象与更新执行强制，再由 RIPE NCC 定期联系缺少滥用联系人的资源持有者做数据清理。这一设计把"保持联系人正确"定义为资源持有者的维护义务。

后续政策文件（ripe-563 及现行的 ripe-705）延续并细化了同一模型：aut-num 必须有 abuse-c；由于 IP 地址对象的层级性质，至少每个直接分配的 inetnum/inet6num 都需要 abuse-c；RIPE NCC 每年至少验证一次 abuse-mailbox 并对不正确者跟进。

注册机构亲手代设的占位联系人

实施记录显示，责任链条上有一段特殊的代管期。据 RIPE NCC 实施页面与 RIPE Labs 文章，自 2013 年 12 月起，对于 LIR 未自行设置 abuse-c 的分配资源，RIPE NCC 直接使用该 LIR 在成员名录中的电子邮箱地址代设滥用联系人；到 2014 年 11 月（第二阶段），NCC 又自动把赞助 LIR 的滥用联系人加入未被维护者更新的被赞助资源的 organisation 对象——持有者随时可以修改这些数据。

模式与政策之间的被记录的落差

2016 年 1 月的 anti-abuse-wg 邮件列表讨论是最直白的一份自述。RIPE NCC 的 Tim Bruijnzeels 写道：第一阶段于 2013 年 12 月完成、第二阶段于 2014 年 11 月完成，此后 LIR 与终端用户负责确保 organisation 存在 abuse-c——但"实践中已证明难以强制执行，因为 abuse-c 在 RIPE 数据库模式中并非必填属性"，导致新的组织仍会没有滥用联系人。

同一讨论还记录了占位联系人设计的社会成本：当占位 abuse-c 使用赞助 LIR 的邮箱时，许多 LIR 发现自己莫名出现在被赞助组织的滥用联系人位置上，感到"不愉快的意外"；陈旧的赞助方邮箱引用也长期无人清理。自当年 3 月 1 日起，新 LIR 激活时自动创建滥用联系人——可修改但不可删除。

转售链条中的空壳角色对象

对于最常见的投诉场景——终端用户地址——责任链条通过代理关系延长。RIPE NCC 的 FAQ 说明：LIR 通常为客户的 assignment 对象做维护，须自行添加 organisation 引用；客户的 role 对象甚至不需要引用任何 person 对象，是公开且无查询限制的，其全部内容被默认为业务数据。换言之，一个无任何自然人关联的空壳角色对象，即可以是投诉的最终收件人。

量化的验证结果

公开数据把这套制度的实际表现摆在了桌面上。RIPE 87 会议记录中，注册服务部的 Marco Schmidt 给出：约 90,000 个不同的 abuse-c 联系人，约 20,000 个位于 LIR organisation 对象、约 58,000 个位于资源对象、约 15,000 个位于独立资源对象；分摊到年度验证，每周约 2,000 封验证邮件，"约 6% 到 8% 的邮件失败"——失败不必然意味着联系失效，有时只是超时。对于无法联系到责任人的资源与独立资源联系人，NCC 会将邮箱替换为 LIR 或赞助 LIR 的可用滥用联系人。

更早的 RIPE 80 演示材料给出了第一轮完整数字：77,168 个不同 abuse-mailbox 属性中，71,711（93%）通过自动验证，5,457（7%）未通过；2019 年约 8,000 个属性被更新。同一份材料明确指出：现行政策并未对 abuse-mailbox 的实际可用性提供充分验证，政策意图也不包括查看邮箱如何被监控、案件如何处理。

推动年度验证制度的 2017-02 提案则记录了制度诞生前的顾虑：ripe-563 未设验证安排，abuse-c 信息"常常过时或不准确"，NCC 每年收到数百份无效联系人报告；当时数据库中约 70,000 个不同 abuse-mailbox 属性，初步随机抽测提示 10%–25% 可能错误或失效。该提案于 2018 年 6 月获社区通过。

责任链的终点在哪里

把以上材料并排阅读，一个结构性图景浮现出来：政策把维护义务交给资源持有者，实施历史把代设责任交给注册机构，验证机制把发现问题的责任交给自动化工具，而"是否有人阅读并处理"被明确排除在政策意图之外。当被命名的保管人是一个无人查看的角色账户时，公共记录显示的唯一修复方式是——NCC 在验证失败且无法联系责任人时，把邮箱替换回 LIR 的可用联系人。

Sources