摘要

  • RIPE-563 让 inetnum、inet6num 与 aut-num 对象的 abuse-c 属性成为强制项：其引用的 role 对象必须包含唯一一个 abuse-mailbox 地址，该地址须公开可查（WHOIS 与各类 API）、能够接收邮件，且不得强迫发件人改用网页表单；该要求生效时不覆盖传统（legacy）互联网资源。
  • 依据政策提案 2017-02，RIPE NCC 至少每年主动验证 abuse-mailbox。验证由不发送任何邮件的自动化技术检查完成，其性质是格式与可达性检查，而非处置质量评估——通过验证只证明“这个邮箱能收到信”。
  • 邮箱未通过验证后会进入一条逐级升级的处理链：属性被标记为无效、生成工单、联系 LIR、按一周间隔两次重试、工作人员电话跟进，最后手段是成员关闭与资源注销。RIPE NCC 公布的早期试验提示约 10% 至 25% 的属性可能失准、后续轮次约 92.5% 通过自动检查，均为其自述，未经独立核实。

强制联系人：从“建议”到“必须”

RIPE-563《RIPE 数据库中的滥用联系人管理》把 abuse-c 属性设为 inetnum、inet6num 与 aut-num 的强制字段。它引用的 role 对象必须包含唯一一个 abuse-mailbox 属性；该地址必须能通过 WHOIS 与各类 API 公开查询、必须能接收邮件，并且不得强迫发件人使用网页表单（见 RIPE 数据库相关文档 与 相关说明）。

一个常被忽略的边界是：该要求在生效时并不延伸至传统互联网资源（legacy resources）。换言之，“必须有人可联系”的覆盖范围从一开始就是有条件的，而非全量的。

年度验证：一组不发送邮件的自动化检查

依据政策提案 2017-02（Regular abuse-c Validation，滥用联系人定期验证），RIPE NCC 至少每年对 abuse-mailbox 属性做一次主动验证（提案相关说明）。验证从一组不发送电子邮件的自动化技术检查开始：地址格式错误检查、DNS 检查、伪造或蜜罐（honeypot）地址的识别，以及一项邮箱能否接收邮件的测试（验证流程说明）。

这组检查的目标很明确：以最低成本找出“格式错、域名坏、地址是陷阱、邮件进不去”的联系人。它不检查什么同样明确——邮箱背后有没有人、举报到达后多久被处理、是否会被搁置了事。

检查的边界：可达性不等于处置

按流程设计，验证判定的是“属性是否存在、邮箱是否可达”，并不评估滥用案例收到后如何被处置（见 提案相关说明、验证流程 与 RIPE NCC 的说明）。这条边界值得重复：在验证记录上，一个可达但常年无人处置的邮箱，与一个运转良好的滥用响应入口无法区分。对调查者、受害者和平台而言，这是两种质量完全不同的承诺，却共享同一个“通过”标记。

失败之后：一条有记录的升级阶梯

当邮箱未通过验证，该属性会被标记为无效，并生成一张工单，随后按固定阶梯推进（RIPE NCC 的流程说明）：

  1. 负责该资源的 LIR（本地互联网注册机构）被要求检查；独立资源由其赞助 LIR 处理；
  2. 系统向该邮箱发送验证链接，让“功能正常但被判误报”的案例可以关闭；
  3. 若毫无回应，按一周间隔再尝试联系两次；
  4. 之后由工作人员尝试电话或其他替代联系方式；
  5. 作为最后手段，RIPE NCC 可启动成员关闭与互联网资源注销的程序。

这条阶梯结构清晰、有据可查。需要看清的是它的末端：注销资源与关闭成员不是普通运营动作，而是不易回退的制度性终局——这也意味着它更可能作为威慑存在，而非日常使用的常规手段。

已公布的数字，说明了什么

RIPE NCC 公布的验证数据（以下均为其自述，未经独立核实）：验证工具的早期试验提示，约 10% 至 25% 的 abuse-mailbox 属性可能不正确或已失活；随后一轮验证中，约 92.5% 通过了自动化技术检查（数据出处）。两组数字之间既有工具与判定标准演变的因素，也有登记库随时间自发清洁的因素，不能简单读作“质量改善”。

更关键的是 RIPE NCC 自己的表态：应当收集并定期发布关于“滥用案例如何被处置”的匿名统计数据（同上）。这句话本身就是对数据缺口的承认——现有公开数据衡量的是可达性，而处置仍然不可见。

结论

这套机制擅长把“联系方式失效”这类最常见的可检测故障清出登记库，并把联系人维护的责任明确交还给各 LIR。但真正构成服务承诺的那一步——举报到达之后就有人处理——依然只存在于每个成员组织自己的流程里，由内部制度而非注册库的年度检查来兑现。对监测者而言，下一个关键节点不是复核 92.5% 这个数字，而是看处置层面的统计何时、以什么粒度被公开。

关于该实体的持续记录，见 BTW 目录：RIPE 滥用联系人条目。