摘要

  • RIPEstat Abuse Contact Finder的官方API文档明确声明，返回的滥用联系人信息“在许多情况下是不正确的或不可用的”，这是登记库自己写下的查询准确率免责条款。
  • 2015年之前，该工具以五星制显示查询结果的可信度；2015年起五星评分被移除，工具只按RIPE 563文件返回abuse-c邮箱地址，不再表达任何置信度。
  • 查询机制是自底向上的：它在INET(6)NUM对象所链接的ORGANISATION对象中搜索abuse-c:引用，返回找到的第一个；只要存在任何abuse-c:引用，旧的abuse-mailbox:属性就不再被考虑。
  • 登记库历史文件记录了具体查找错误：一个漏洞使工具因占位数据而频繁错误地返回登记库自身的占位滥用邮箱地址；另一个漏洞因主键与索引键在对象类型间不唯一而返回与输入无关的结果。
  • RIPE NCC员工曾在公开回复中承认，当时“没有任何程序”让用户或登记库去纠正或验证资源持有者给出的滥用联系人。

免责声明来自登记库自己

查询层的核心事实写在RIPEstat数据API的官方文档里。Abuse Contact Finder端点接受一个前缀、IP或ASN，返回两组数据：abuse_contacts（专用的滥用投诉邮箱地址）和authoritative_rir（对该资源有权威的RIR）。紧随其后的是一句声明：返回的滥用联系人信息“在许多情况下是不正确的或不可用的”。这不是批评者的评价，而是运营方RIPE NCC自己维护的文档对自身工具准确性的表述。

这句话的分量在于它在整个投诉链条中的位置。投诉者、自动化举报系统和企业安全团队把这个端点当作“寄往何处”的第一站；如果这一站给出的是错误邮箱，后面所有关于响应率、处理时长的讨论都无从谈起。此前BTW的报道已经指出，登记库对滥用联系人的验证只验证邮箱可投递、不验证是否有人回应——查询层的这句免责声明补上了链条更上游的一环：连“地址是否正确”这一层，登记库也从未给出可量化的保证。

被移除的五星评分

准确率的不透明并非一开始就如此。在历史版本的RIPEstat中，Abuse Contact Finder用五星制表达查询结果的可靠性：五星表示该IP对象上的abuse-c符合ripe-563规范；四星表示在相关对象中找到了abuse-mailbox；三星表示只在remarks字段里找到联系人；二星表示邮箱来自更具体或上游的对象，“可能不是正确的联系人”；一星则意味着找到的联系人“相当不可能”正确。

这个评分体系的信息价值显而易见：它把不确定性摆到了投诉者面前。但在2015年，RIPE NCC在RIPE Labs上宣布，Abuse Contact Finder不再提供评分启发式，只显示RIPE 563文件规定的abuse-c邮箱地址。换言之，工具从“返回一个带置信度的结果”退化为“返回一个不带任何限定语的结果”——而准确率的免责声明从界面上消失，转移进了API文档。2015年之后就查询准确率本身，本运行未找到任何公开发布的独立测量。

自底向上：只返回找到的第一个

今天的查询机制是结构性的，而非概率性的。按RIPE 563的实施，工具在INET(6)NUM对象所引用的ORGANISATION对象中搜索abuse-c:属性，返回找到的第一个。只要在任何被涵盖对象中找到abuse-c:引用，旧的abuse-mailbox:属性就不再被考虑——即使后者在层级上更贴近被查询的资源。按RIPE Database文档，abuse-c:是组织对象中的属性，指向一个必须包含abuse-mailbox:的role对象；任何引用该组织的inetnum、inet6num或aut-num都被该邮箱覆盖；若在被涵盖对象中找不到任何滥用联系人，则不返回结果。

这个设计的含义是：工具返回的是登记数据库中结构上最具体可得的abuse-c，而不一定是能够对滥用行为采取行动的运营者。当层级上最不具体的覆盖对象带有遗留数据或历史占位符时，错误路由的风险恰恰集中在这种交界处。RIPE Database文档同时警告投诉者：把投诉复制到数据库中找到的其他邮箱地址，不会让投诉得到更快的处理——换言之，一旦查询给出错误邮箱，投诉者没有官方推荐的兜底路径。

登记库自己记录过的查找错误

查询层的错误不是理论推演，而是登记库历史文件中的既有记录。在ripe-563之前，旧的Abuse Finder依靠启发式链：对每次查询执行大约30到150次独立的RIPE Database查询，官方文件承认它“只能给出尽力而为的建议”，并且“被证明不可靠且有争议”。其中两个已记录的漏洞尤其具体：其一，由于数据库中的占位数据，工具会频繁且错误地返回登记库自身的占位地址——一个并非真实投诉目的地的地址；其二，由于主要键与索引键在各对象类型间不唯一，工具会返回与输入无关的结果。2019年的RIPE 80会议材料还给出了当时验证行动的规模数据：在77,168条不重复的abuse-mailbox条目中，71,711条（93%）通过自动化验证，5,457条（7%）未通过，失败模式包括冒用其他组织的虚假邮箱、从未被阅读的邮箱、已满或弹回的邮箱，以及指向不存在员工的地址。

无人负责纠正的历史

2017年的政策提案2017-02记录了另一个结构性事实：ripe-563并未对abuse-c:信息提供任何验证，RIPE NCC每年收到数百份关于无效联系信息的报告，一次初步随机测试显示10%至25%的abuse-mailbox属性可能不正确或未启用，而数据库当时持有约70,000条不重复的abuse-mailbox属性。提案引入的自动化验证检查语法、域名与邮件服务器配置，并承认可能出现假阴性。而更早，在RIPE Labs页面上，一名RIPE NCC员工的公开回复承认：对于资源持有者给出的滥用联系人，当时“没有任何程序”让用户或登记库去纠正或验证。这一回复直接指向查询层的深层问题：即便工具如实返回数据库内容，数据库内容本身的正确性曾长期没有制度化的纠错通道。如今RIPE NCC公开指引允许用户报告无效或缺失的滥用联系人，但对“地址有效但错误”的情形，公开文档仍未记录相应的纠正程序。