摘要

  • 第一稿 AFPUB-2018-GEN-001-DRAFT01 拟要求 AFRINIC 直接签发的 inetnum、inet6num 与 aut-num 记录都带有一个有效、受监看且积极管理的 abuse-c 联系邮箱，并在建立、更新、至少每三个月一次以及 AFRINIC 认为适当时接受验证。
  • 统一且客观可达的角色邮箱确有公共价值：它减少举报者、网络运营者与事件响应团队寻找正确窗口的时间，也能在真正的安全事件发生前暴露失效地址。这是登记资料准确性的正当核心。
  • 草案同时要求人工介入、禁止过滤、禁止强制举报者改用网页表单，并让收件人保证会采取措施和作出回应；再把五个工作日内的验证失败连到政策违约及尤其涉及资源撤销的程序，遂把邮箱检查变成了对运营行为的监督。
  • AFRINIC 只是依毛里求斯公司法运行的私人技术记账者与协调者，不拥有主权、立法、监管、警务、检控、惩罚、没收或公法裁判权。适当方案是只测客观投递能力，给予通知与有意义的修正期，公开标示资料质量，但绝不能因联系失败而损害号码资源控制、投票、转让、RPKI、反向 DNS、路由或客户服务。

L3 — 五个工作日的验证机器

先把时钟拨到第一天。AFRINIC 的验证程序向 abuse-c 邮箱连续发出两封纯文本邮件。第一封提供一个网址，第二封提供一枚唯一代码。负责该邮箱的人要打开网址，把代码填入受 CAPTCHA 保护的表单，并勾选一项远比“邮件已送达”宽泛的声明：他理解相关程序与政策，邮箱受到定期监看，收到滥用举报后会采取措施，而且举报会得到回应。草案给这一步不超过两个工作日。代码没有被使用，联系资料便被标成暂时无效，工作人员转而联系本地互联网注册机构；后者再得到不超过三个工作日。仍未更正，状态变为永久无效。日后重新验证又失败，则会被视为政策违约。这不是松散的行政提醒，而是一条预先编排的五个工作日轨道，资料状态、人员动作与后续制裁风险在同一轨道上逐站升级。

这一设计的起点并非凭空出现。AFRINIC 早已有专门承载滥用联系资料的 IRT 对象，inetnum、inet6num 和 aut-num 等资源记录可以引用它。问题在于，引用是可选的，政策以鼓励良好做法为主，并不保证每一个由 AFRINIC 直接签发的资源都指向清楚、现行而可用的举报窗口。当攻击流量、垃圾邮件、扫描活动或客户网络中的异常行为需要被转告时，举报者可能先在不同字段、网站和转售层级之间摸索；一个早已离职的个人邮箱，或者一封持续退信的邮件，会把本来可以迅速抵达网络运维台的信号消耗在寻找联系人上。

第一稿试图改变这个基线。它提出，凡由 AFRINIC 直接分配或指派的资源，其对应的 inetnum、inet6num 或 aut-num WHOIS 记录都必须包含 abuse-c。至少一个邮箱必须有效、受监看并被积极管理；子级记录可以继承上级记录的联系人，也可以另行公布自己的联系人。邮箱资料应当通过 WHOIS、接口以及未来采用的技术不受限制地提供。这一部分有清楚的登记逻辑：同一类字段降低查找成本，角色地址比某位雇员的名字更能经受人员流动，继承机制又避免每个下游记录都机械复制资料。对于需要报告问题的人来说，“去哪儿发”不应成为第一个障碍。

客观验证也有同样扎实的理由。一个数据库可以保存格式正确却实际无人接收的地址；仅检查字符串里有没有“@”，不等于维护了可信记录。若在创建或重大更新时发送普通测试邮件，观察是否退信、域名是否存在、投递是否成功，登记机构便能发现最基本的数据腐败。周期性复核还可以暴露域名过期、邮件系统迁移或岗位交接后留下的死地址。一个负责公开号码资源资料的机构，如果连所公布的运维窗口是否能收到邮件都不管，确实没有把地址簿维护好。强制一个可达的角色地址，以及对投递事实作狭窄、可重复的检查，属于技术记账工作的合理范围。

但第一稿没有停在“邮件是否到达”。它规定，发送到该邮箱的邮件必须在某个阶段需要人工介入，不得被过滤；允许先发自动回执，却不允许要求举报者必须使用网页表单。验证也不只确认地址掌握在资源持有人手中，而是要求确认邮箱受到定期监看、会采取措施、报告会得到回应。草案因而同时回答了两个本应分开的疑问：一是登记记录能否把信息送到相应组织，二是该组织收到信息后应当怎样配置安全流程、怎样筛选、怎样接单、怎样处置并怎样答复。前者可以由一次投递事实证明，后者涉及具体运营判断，无法由一枚验证代码证明。

“不得过滤”尤其揭示了边界。任何公开邮箱都会接收垃圾邮件、伪造通知、恶意附件、重复机器人举报与缺乏关键证据的指控。网络运营者可能根据自身威胁模型设置反垃圾规则、附件隔离、发送者信誉、速率限制或工单去重。过滤不是“不关心滥用”的同义词；过滤得当，反而能使真正紧急的信号不被噪声淹没。登记机构既看不到每个网络的流量背景，也不承担打开恶意载荷的风险，更不知道某条规则是在阻挡攻击还是误伤合法报告。把“邮箱可达”扩大为“不得过滤”，等于从核对公开资料跳到命令收件系统的防御架构。

禁止强制使用网页表单也有相同的问题。举报者当然不应被层层复杂页面、强制开户或无关资料挡在门外；把一个失效邮箱伪装成入口，再让来信者自行寻找另一套系统，也会损害可达性。然而，结构化表单可以收集时间戳、源地址、目标地址、日志片段、同意声明和附件类型，减少往返追问，并把敏感证据隔离进受控环境。对于规模较大的网络，它还可能把报告自动送到正确客户、地区或安全队列。合理的名录要求可以保证存在一个可联系的入口，却不能仅凭“网页表单”这一技术形式就断定流程无效。应当判断投递事实，还是规定接收方式，这两件事必须分开。

人工介入和回应承诺则把越界写得更直接。自动化并不天然缺乏责任：成熟的滥用台可能先自动解析、关联路由与客户资料、合并重复举报、隔离风险，再由人员处理需要判断的部分；也可能对证据不足的批量告警只保留记录，而对正在造成损害的事件立即升级。所谓“采取措施”究竟是封禁、通知客户、保存日志、请求更多证据，还是判定报告错误？所谓“回应”是自动确认即可，还是必须说明结论、时限和补救？第一稿没有、也无法在邮箱验证中可靠裁定这些差异，却要求验证者勾选一项包含行为结果的保证。勾选框由此不再只是控制地址的证明，而成了对运营实践的合规声明。

验证频率进一步扩大了这种持续关系。草案要求在记录创建或更新时验证，至少每三个月再验证一次，并允许 AFRINIC 在其认为适当时验证；某些测试还可以改变域名、主题和正文，以防收件系统只为已知测试样式开白名单。防止“只认考题”的假邮箱，是最有力的善意理由之一。如果每次测试都完全相同，持有人确实可能设置一条专门规则，让验证邮件通过而真实举报无人处理。然而，一旦测试目标从客观投递变成识别过滤策略、人工动作和回应习惯，变化的测试就带上了稽查意味。“认为适当时”又没有为频率提供可预测边界，使一个静态登记字段变为随时可能触发的合规互动。

草案还设计了升级与介入。举报者认为联系渠道没有产生结果时，AFRINIC 可在过程中居间；不合规会引出依照相关政策或程序进行更彻底的跟进，措辞特别指向与资源撤销有关的程序。这里必须精确：第一稿当时仍处于讨论之中，没有证据表明它已经获采纳、投入实施，或据此撤销过任何人的资源。它所造成的是提案层面的制度风险，而非已经发生的处罚事实。可风险本身仍然清楚，因为它把一项联系资料缺陷与登记机构最强的服务杠杆放进了同一条规范链条。

当时的工作人员评估印证了这一结构，而不是赋予它法律权威。评估把 mandatory abuse-c、直接签发记录、至少每季检查以及失败构成政策违约视为拟实施内容，并估计开发、测试和部署至少需要一个半月。评估同时没有记录法律顾问意见。这个估算说明机制不是在现有数据库里随手加一个字段：发送与追踪邮件、管理代码和状态、处理升级、安排复核，都需要新的操作能力。但技术上能够建成一套验证系统，并不能回答机构是否有权借这套系统审查回应行为，更不能创造把联系失败与资源惩罚相连的公法权限。

版本边界同样重要。AFPUB-2018-GEN-001-DRAFT01 于 2018 年 8 月 12 日由 Jordi Palet Martinez 提交，拟替换《综合政策手册》第 8.0 节；政策登记将它记为讨论中。第二稿直到 2018 年 11 月 20 日才出现。随后 AFRINIC-29 对已演变的提案展开争论，参与者谈到 MyAFRINIC 限制、投票影响、处罚是否相称，以及登记机构会不会充当“互联网警察”，共同主席记录为没有共识并退回邮件列表继续修订。2018 年年报也从较晚的生命周期回看提案。那些材料可以说明争议为何持续，却不能把第二稿后的每一项说法倒填进 8 月 12 日的第一稿。

后来总共记录了七个版本；第七稿及其后来的批准状态属于另一阶段。第一稿不是最终政策，后续文本、申诉安排、共识结论和批准不能被冒充为第一稿的内容。对这一点保持克制，反而能更准确地看见第一稿的意义：它在最初设计里就把必填字段、反复验证、回应保证、五日升级与撤销相关后果串在一起。问题不需要靠后来真实处罚的个案才能成立；边界已经写在所提议的机制中。