摘要

  • RIPE NCC 在 RIPE 93 报告约 8000 个无法投递的邮件地址；自 RIPE 92 以来，这个规模大致没有变化。
  • 同一场报告说，它们影响约 1% 的每日更新通知。RIPE Database 文档把邮件列为通知渠道。

数据库变更有两个去处：记录本身，以及需要知道记录变了的人。前者可以保存得很准确，后者却可能收不到消息。

RIPE NCC 的数据库团队在 RIPE 93 给出了这个落差的数字：约 8000 个邮件地址无法投递，与 RIPE 92 报告的水平大致相同。团队还说，这些地址影响每日更新通知的约 1%。他们会定期重新验证地址；恢复可投递的地址会被重新标记为可用。团队解释，更新通知很重要，因为它告诉用户数据库里发生了变化。

这两个数字不能混成一个分母。8000 是无法投递的地址数量；1% 指受影响的每日更新通知。它不等于 1% 的数据库对象有误，也不等于 1% 的更新失败，更不能推导出发往这些地址的每一封邮件都丢失。公开报告证明的是一个每天可测量的投递问题，而不是数据库遭到入侵或记录被篡改。

RIPE Database 通知文档把更新确认与通知分得很清楚。确认信息可以通过邮件或其他 HTTP 连接返回；通知则发给希望获知数据库对象操作的人，文档明确写明通知始终通过邮件发送。确认面对的是提交更新的人，通知面对的是被指定来观察对象的人。收到前者，不能证明后者也收到。

这条边界藏在日常操作里。维护者可以成功认证、提交更新，并收到一份正常确认。另一位负责观察该对象的人，可能仍在使用一个已经拒收邮件的地址。数据库留下了准确变更记录，通知链路却在读者面前断开。

RIPE NCC 说它会重新验证地址，并把恢复投递的地址改回可用状态。但公开会议记录没有给出验证间隔、失败通知总量、地址恢复率，也没有说明这些地址对应哪些持有人或数据库对象。任何一项都可能改变修复工作的优先顺序。目前能确认的范围很明确：约 8000 个地址无法投递，约 1% 的每日更新通知受影响。

真正的设计问题，是“邮件被拒收”和“有人修正联系人”之间发生了什么。退信只有进入有人查看的队列、能关联到依赖该地址的记录，并给正确的维护者一个可行的修复入口，才有用。重新验证可以发现地址后来恢复了，却不能自动把过期地址更新成当前地址。

RIPE NCC 可以公布一张简单的投递账表：每日失败数、重新验证的地址数、恢复数，以及未解决失败的持续时间。数据库也可以把投递失败显示给维护者，让联系人和受影响对象之间的关系一眼可见。对高后果变更，还可以研究用户自选的第二通知渠道。这些是编辑建议，不是 RIPE NCC 已宣布的计划。

问题不在于邮件技术已经过时。邮件仍然负责告诉分散在不同网络中的运营者，某条记录发生了变化。陷阱在于把数据库里的一个地址字段，当作一条确实通向读者的活链路。登记记录保存记忆；通知送达，才让相关人员有机会据此行动。

来源：RIPE 93 数据库工作组会议记录 · RIPE Database 通知文档 · RIPE 92 数据库工作组会议记录