摘要

  • RIPE-705 要求至少每年验证公开的 abuse-mailbox 属性；若被认定有误，RIPE NCC 会按适用政策和程序跟进。这是一项登记资料维护机制。
  • 目录指针或邮件配置测试都不能证明真实举报抵达了正确团队、进入分流流程，或促成了处置。

目录提供的是路径，不是服务承诺

遇到来自某个网络的滥用流量时，受影响的人首先要知道向谁报告。RIPE 数据库以 abuse-c 属性指向 role 对象，再由 role 对象保存 abuse-mailbox 地址。沿着这条记录，查询者可以找到一个公开的举报入口。

这不是无关紧要的字段。邮箱写错、域名失效或邮件服务器配置异常，都会让求助路径在进入处理流程前就中断。RIPE-705 将该邮箱定义为接收与资源持有者网络中滥用行为有关的自动或人工报告，并要求通过 Whois、API 等方式不受限制地访问。

然而，公开记录只显示应当把消息送往哪里，无法显示组织收到邮件后做了什么。它没有说明谁在读这个邮箱、夜间和周末是否有人值守、投诉会转交给哪个安全团队，也不记录运营者是否改变了网络行为。这些内部流程可能运行良好；地址字段本身并未测量它们。

年度验证能说明什么

已发布的 RIPE-705 要求 RIPE NCC 至少每年验证一次 abuse-mailbox。若属性被认为不正确，RIPE NCC 会依适用政策和程序跟进。规则没有规定投诉的答复时限，也没有把注册机构变成持有人内部的安全事件服务台。

2017-02 提案的实施材料提到自动检查语法、域名、邮件服务器配置等技术参数。相关分析承认误报和漏报都可能发生：实际可用的地址可能被标错，技术检查通过的配置后来也可能无法使用。因此，验证结果只能说明配置检查的有限结论，不能担保每封邮件的结果。

还要给统计数字注明时间。RIPE NCC 对后来一项提案的影响分析描述了当时的工具：检查地址格式、DNS、可疑或蜜罐邮箱，并以技术方式判断邮箱似乎存在且可以接收邮件；工具本身不发送邮件。那一时期，92.5% 的地址通过了自动检查。它是历史方法的阶段性数字，不能冒充当前绩效，也不涉及投诉处理质量。

两周规则没有进入最终文本

2017-02 提案较早的版本曾写过：若两周内没有有效回复，包括邮件退回，abuse-mailbox 将标记为无效。官方修订记录显示，这段文字后来被删除。最终发布的 RIPE-705 只保留年度验证，以及被认为有误时依规则跟进的要求。

这一区别很重要。草案中的期限容易被误读成仍然有效的服务时限。已发布的规则没有要求资源持有者必须在两周内回应滥用投诉，验证状态也不是运营者处理投诉速度的公开评分。

2019 年的提案触及边界，最后撤回

2019-04 提案曾讨论更直接地验证邮箱是否能收到邮件，并缩短检查间隔。RIPE NCC 的影响分析明确指出，即使确认消息能够送达，也不能证明举报已经按提交者期望的方式处理；分析还说 RIPE NCC 没有授权介入资源持有者的内部滥用处理流程。

这项提案没有成为规则。RIPE 81 反滥用工作组会议纪要记载，讨论未达成共识，2019-04 已撤回。它可以证明各方讨论过监管边界，却不能证明其中设想的检查已经实施。

验证数量不是处置效果

RIPE NCC 的 2019 年报称，当年验证了 77,979 个邮箱地址，其中 73,023 个经自动流程检查，4,956 个需要人工跟进；另有 38,307 个 role 对象被创建或更新。这些数字说明登记维护的工作规模和自动化程度，但不统计收到多少投诉、多久确认、如何分流、采取了什么措施，或有多少案件悬而未决。

年报回答的是实施进度问题，并无不妥。不能把它改造成投诉响应成绩单：被检查的地址数和被处理的投诉数，分母与事件定义都不同。

把三种证据分开

网络运营者和举报者可以依次问三个问题：目录是否公布地址？邮件路径是否按技术预期工作？负责团队是否确认并处理了材料充分的举报？每个问题都需要不同证据。用一个绿色“有效”状态概括三者，会让数据质量信号承担它并不具备的含义。

合比例的办法是让注册机构职责保持清楚：公布联系人，检查技术配置，允许持有人纠正错误，并依据现行规则说明错误记录的后果。运营者可以另行公开服务承诺、确认时限与升级途径。统计送达、确认和分流时间，也能帮助评估服务，而不必让注册机构裁决每一项投诉。

争点不在于举报联系人重不重要，它显然重要。关键在于某项信号究竟证明了什么。年度验证保护的是目录这一层；举报是否得到救济，要看地址之后的处理流程。

资料来源