摘要

  • APNIC 公开路线图把 “Improve Whois IRT Validation” 列为 2026 年第三季度目标：持续追踪所有 IRT 邮箱，并在登录时检查当前有效性，而不是依赖静态账号锁定标记。
  • 这项计划改变的是访问决定的事实来源和读取时点；公开资料没有表示它会取代六个月验证周期、15 天后标记 Invalid 或 30 天后限制 MyAPNIC 的现行规则。
  • 邮箱地址、验证挑战、IRT 对象、成员账号与登录决定是五种不同状态。把它们压成一个布尔值，正会产生路线图希望消除的漂移。
  • 一张保护隐私的 IRT 访问决定回执，可以记录登录时使用的状态版本、政策时钟、聚合规则和决定来源，而不暴露邮箱地址或验证码。

账号在门口需要的是此刻的证据

设想同一个 APNIC 成员账号有两幅画面。一幅是账号保存着早先 IRT 验证结果衍生出来的锁定标记；另一幅是底层联系人此后已经完成验证。如果登录服务只读取前一幅画面，限制原因消失后，账号仍可能继续受限。反过来也一样：相关联系人状态变化后，旧的“未锁定”结论仍可能残留。

APNIC 并未声称某个具体账号已经遭遇这类错误。它在公开路线图中把“防止账号持续处于错误锁定或错误解锁状态”列为预期结果，并给出明确方案：持续追踪全部 IRT 邮箱，在登录时检查其有效性，而不是依靠静态账号锁定标记。项目由 Membership 团队负责，涉及 APNIC Login 与 Whois，目标为 2026 年第三季度。

这不是把页面上的状态图标刷新得更快。静态锁定标记是一个派生结论；当前 IRT 邮箱有效性才是这个结论所应依据的状态。把检查移到登录时，能够缩短证据改变与访问决定改变之间的距离。

不过，“当前”仍需被定义。路线图没有公布最终数据模型、第三季度内的上线日期、一个账号关联多个 IRT 对象时的合并规则，也没有说明一个 IRT 对象包含多个邮箱属性时该如何判定。路线图也没有宣称功能已经上线。这些不是可以用猜测填补的空白，而是控制设计真正成立与否的关键问题。

现行规则已经有三只时钟

登录时检查将进入一个已有政策历史的系统。APNIC 把 prop-125 记录为已实施。现行互联网号码资源政策要求每个资源记录都登记一个 IRT 对象；其中的 email 与 abuse-mailbox 联系地址必须受到监控，发往这些地址的滥用投诉须被及时回应。

联系人验证至少由三只时钟约束：

  1. APNIC 定期或每六个月验证一次 IRT 联系人。
  2. 账号持有人收到验证邮件后有 15 天完成检查；验证失败时，IRT 对象会在 Whois 中被标记为 Invalid。
  3. 30 天后仍未通过验证，MyAPNIC 访问会受到限制，直至联系人完成验证。

APNIC 的 2019 年实施公告称该制度自 2019 年 6 月 30 日起实施。公开的验证页面要求收件人输入邮件中的唯一验证码。这个事件能证明有人在挑战时点取得了该邮件，并据此推动有效状态前进。

路线图没有说登录时检查会取消三只时钟。六个月周期决定何时需要新证据；第 15 天影响 Whois 对象的公开状态；第 30 天触发账号访问后果。登录只是读取这些结果、作出决定的时刻。政策生成状态，登录服务消费状态。

若把这些时刻混为一谈，新的歧义就会出现。成员将无法判断限制访问究竟因为六个月期限已到、挑战已经过期、15 天规则把对象标成 Invalid、30 天后果已经生效，还是登录服务读取了旧状态。更及时的检查只有在保留理由时才真正有价值。

一个布尔值装不下五种状态

IRT 体系至少包含五类可以分别识别的对象。

第一类是邮箱地址记录：它出现在 IRT 对象中，包含敏感地址及其历史。第二类是验证挑战：它有签发时间、投递尝试、到期时间以及验证码成功或失败的事件。第三类是 IRT 对象本身：它有名称、版本与属性。APNIC 的 IRT 对象指南明确区分 e-mail 与 abuse-mailbox，并用 mnt-by 指向有权变更该对象的维护者。

第四类是成员账号及其范围：哪些资源、IRT 对象和联系人会影响该账号的访问。第五类是登录决定：在某一时间、依据某一规则版本完成评估，返回允许或限制，并给出理由。

这些状态彼此关联，却不能互换。一个地址的验证码通过，不代表第二个地址也已通过。编辑 IRT 对象，可能改变需要检查的地址。一个账号可以对应多个资源记录，因而连接多个 IRT 对象。某次登录决定即使忠实反映了当时读取的状态，也会在下一次验证或编辑后过时。

持续追踪只有在连接关系明确时才有意义。登录服务必须知道决策范围包括哪些 IRT 对象、对象中的哪些邮箱属性相关、每项当前状态如何产生，以及用哪条规则合并结果。否则，系统只是用一条不透明的实时查询替代一个不透明的旧标记。

多地址聚合才是最难的政策界面

假设一个 IRT 对象含有两个滥用邮箱和一个普通邮箱：三者是否都必须有效？一个已验证的 abuse-mailbox 是否足够？同一邮箱被多个 IRT 对象复用时，一次完成挑战会更新所有出现位置，还是只更新发出挑战的那条记录？如果同一账号名下各资源的 IRT 对象状态不同，是最严格的状态控制整个账号、只限制受影响的功能，还是只影响相关资源？

公开路线图没有回答这些问题，本文也不会替 APNIC 发明答案。但答案必须有版本。“登录时检查有效性”只有在能够说明检查集合和合并规则时，才可复现。

较稳健的设计应把原始证据与派生决定分开。验证事件只陈述：某地址标识符的一次挑战在某时完成。状态记录说明：该地址从什么时间起有效，何时到期，或者被什么新事件取代。IRT 评估列出纳入考虑的地址状态。账号决定再引用这些 IRT 评估和规则版本。这样，每一层都可以纠正，而不必假装更早的证据从未存在。

恢复场景最能显示这种区分的价值。如果联系人 10:04 完成验证，成员 10:05 登录，支持人员应能确认登录是否读取了新状态。若没有，问题是传播或快照滞后；若已经读取，但另一个 IRT 地址仍逾期，问题就在范围或政策。这是两类事故，也应由不同团队负责。

控制邮箱不等于处理投诉

prop-125 把周期性邮件验证与一个运营目标相连：负责处理网络滥用问题的人应当可被联系。APNIC 政策还要求联系人受到监控，并及时回应发来的滥用投诉。但这些命题需要不同证据。

输入验证码能表明有人取得邮件并完成一次挑战，却不能证明此后的每份投诉都进入正确队列、绕过滤信、得到人工处理并最终解决。反过来，一次验证挑战逾期，也不能证明邮箱不存在，更不能证明某份具体投诉被忽略。投递、邮箱控制、监控、分诊与解决是不同观察。

区分它们，同时保护投诉人和成员。投诉人不应被告知“绿色有效状态”就足以证明滥用处理良好；成员也不应仅因政策验证时钟到期就被认定存在滥用行为。限制 MyAPNIC 是联系人验证所附带的账号控制后果，不是法院判决，不是资源撤销，也不是对网络行为的裁决。

因此，登录时评估可以消费联系人有效性证据，却不能夸大其含义。投诉响应表现可以有自己的测量与流程，但不应偷偷塞进邮箱挑战的定义里。

需要一张决定回执，而不是另一个标记

APNIC 可以用一张 IRT 访问决定回执，让拟议控制具有可审计性。这是本文的编辑建议，并非 APNIC 已经承诺的功能。回执无需显示联系人地址或验证码，但应暴露足够结构，使访问决定可以复现。

每次登录评估可以记录：

  • 时间戳与保护隐私的账号引用；
  • 纳入范围的 IRT 对象键与对象版本；
  • 每个被检查邮箱的遮蔽标识或哈希标识；
  • 各标识最近一次成功验证事件、当前状态与生效时间；
  • 对应的六个月到期日、15 天期限和 30 天后果日期；
  • 范围、聚合与政策规则的版本；
  • APNIC Login 实际读取的状态快照；
  • 允许或限制的结果、类型化原因代码与决定来源；
  • 后续纠正、人工复核或替代决定的链接。

迁移期间，“决定来源”尤其重要。它可以区分一项结果来自实时 IRT 状态评估，还是继承自旧的静态标记。APNIC 因而能够测量仍有多少登录依赖旧路径，在切换前比较冲突结果，并只在实时评估被证明完整之后停用旧标记。

回执还应按受众分层。成员可以看到对象标识、遮蔽后的联系人与期限；支持团队可以看到更多内部事件引用；如果有公开证明的需要，外部只需得到回执摘要与类型化状态。可审计并不意味着公开邮箱。

来源