要約

  • RIPE政策 ripe-705「Abuse Contact Management in the RIPE Database」（2018年発効）は、すべての aut-num オブジェクトおよび直接割り当ての inetnum/inet6num オブジェクトに abuse-c: 属性を義務付け、参照先の role オブジェクトが単一の abuse-mailbox: 属性を持つことを要求し、whoisやAPI経由での無制限の参照可能性と、RIPE NCCによる最低年一回の検証を定めている [1]。
  • 政策提案 2017-02 は検証の範囲を abuse-mailbox の技術的正しさ（構文、ドメイン、メールサーバ設定）に限定し、「メールボックスは機能するが報告が報告者の望む通りにフォローアップされない」状況を範囲外と明示した。理由は、RIPE NCCに資源保有者の内部 abuse 対応手続きに介入する権限がないからである [4]。
  • 提案 2019-04 は、abuse-mailbox が実際にメールを受信すること、フォームの使用を強制しないことを要求し、匿名化されたエスカレーション統計の収集と定期的な公開を構想した。当時のNCC影響分析は、検証ツールがメールを送信しないこと、自動チェックで92.5%のアドレスが合格したことを記録した [5]。
  • RIPE 87 のNCCサービス資料（2023年11月）によれば、検証ツールは書式・DNS・メールボックスの存在を確認するがメールは送信しない。週に約2,000件を検証し、失敗率は6〜8%で、無効な abuse-c は機能するLIRのabuse-cに置き換えられる [12]。
  • RIPE 90 のレジストリハイライト（2025年5月）は、2024年に2,445件の Assisted Registry Check と約5,500件の是正措置（abuse-c政策遵守を含む）、メンバーサービスチケットの19.4%増（32,514件）、および organisation・レジストリ連絡先への検証拡大の意向を報告している [13]。
  • RIPE NCC自身の公開ページは、ネットワーク外部からのスパム・フィッシング等の報告はレジストリとしての責任範囲外であり、abuse報告の処理はネットワーク事業者の責任であり、「事業者が返信しないことを選んだ場合、我々にできることは何もない」と述べている [6][7]。
  • 手続き文書 ripe-858 は、特定のNCC要求への無反応を「無応答」と定義し、初回通知、30日・60日の催告、90日でのManaging Director名義の終了通知という段階的解約の梯子を定めている。ただしその適用対象は登録データの不正確さであり、第三者のabuse報告ではない [9]。

本稿の新しい部分は、この記録を「入口の検証」と「出口の計測」に分ける四層フレームワークそのものである。先行報道は検証キャンペーンの数字（入力指標）、escalation機構が第三者のabuse報告で発動したことがない事実、custodian連鎖、そして修復の欠落を確立してきた。ここでは、輸送・内容・手続き・統治という四つの層を評価基準として定式化し、RIPE自身の文書に適用する。

第一層：輸送（メールボックスはメールを受け取れるか）

ripe-705 が義務付けるのは、role オブジェクト内の単一の abuse-mailbox: 属性であり、whois・API経由での無制限の参照可能性である [1]。実装は2013年に始まり、organisation オブジェクトに紐づく資源はすべて abuse-c: を持つことになった [8]。検証は最低年一回とされる [1]。RIPE 87 の資料が示す週約2,000件・失敗率6〜8%の検証は、書式・DNS・メールボックスの存在確認であり、メールは送信されない [12]。したがって第一層の指標は、メールボックスが技術的に到達可能であることだけを証明する。

提案 2019-04 が指摘したのは、まさにこの層の検証の弱さである。「メールボックスは設定上存在するが、実際にはメールを受け取らない」「受け取ってもフォームの使用を強制する」状態は、構文とDNSのチェックでは検出できない [5]。提案の impact 分析が記録した92.5%という合格率は、設定の正しさの尺度であって、応答性の尺度ではない。

第二層：内容（応答は事案固有か、テンプレートか）

RIPEの政策文書は、abuse報告への応答内容に何らの基準を設けていない。ripe-705 の対象は属性の存在と検証可能性であり [1]、提案 2017-02 は報告のフォローアップを明示的に範囲外とした [4]。Database ドキュメントは、他のメールアドレスにコピーしても処理が速くならないと報告者に助言している [11]。つまり、第二層の品質 — 自動返信か、事案固有の調査か — を測る公開基準は存在しない。

第三層：手続き（終了が文書化された是正に紐づくか）

RIPEは手続きの梯子を持っている。ripe-858 は、特定のNCC要求への無反応を無応答と定義し、初回通知から30日・60日の催告、90日でのManaging Director名義の終了通知、さらに登録解除へと進む [9]。しかし定義を読むと、この梯子の対象は「不正確・曖昧な登録」に関するNCC要求への無反応であり、第三者のabuse報告への無反応ではない。提案 2017-02 が参照する解約手続きは、非応答・不遵守の保有者に対する「最後の手段」として記述され、過去5年間に1,000件超の外部からの不正abuse-mailbox報告が解約を発動させずに解決されたとされる [4]。Reporting Procedure は、スパム・フィッシング等のネットワークabuse報告を調査対象外と明示している [6]。手続き層は存在するが、abuse報告という入力に対して開かれていない。

第四層：統治（文書化されたエスカレーション経路と名前のある判断基準）

統治層の最強の判定基準は、エスカレーションの統計が定期的に公開されていることである。提案 2019-04 はこれを構想した — コミュニティがRIPE NCCへエスカレーションを報告し、匿名化された統計が収集・公開される — が、これは提案レベルの構想のままであり、採択された政策としては現れていない [5]。利用者向けページが述べるのは、検証された連絡先の存在と「返信しない事業者にできることは何もない」という限界の宣言だけである [7]。

RIPEの公開記録を四層に当てはめると

公開指標の全体像はこうなる。検証スイープの規模 — 先行報道が記録した2019年の77,168件、2023年の84,868件、2024年の83,509件、2025年の86,959件、そして手動介入の裾野の649件（2023年）から851件（2024年）、899件（2025年）への拡大 [14] — は第一層の入力指標である。RIPE 90 の2,445件の Assisted Registry Check と約5,500件の是正措置、32,514件のメンバーサービスチケット（19.4%増）[13] も、登録データの品質とメンバーサポートの活動量であり、abuse報告の処分結果ではない。第二層、第三層、第四層に対応する公開指標は一つも見つからない。第三層に相当する機構（ripe-858の梯子）は存在するが、定義上、第三者のabuse報告には適用されない [9]。第四層に相当する構想（2019-04の統計公開）は提案のまま止まっている [5]。

この偏りは偶然ではない。提案 2017-02 の範囲定義 — 「RIPE NCCには資源保有者の内部abuse対応手続きに介入する権限がない」[4] — と、Reporting Procedure の対象外宣言 [6] が、体系的に出口の計測を排除している。検証キャンペーンはその排除の上に立つ、法的に安全な計測装置である。

フレームワークが何を可能にするか

四層フレームワークの価値は、責めを新しい場所に移すことではなく、観測可能な問いに変えることにある。第一層だけが測られている現状では、「abuse-c制度は機能している」という主張と「苦情が無視されている」という主張が、同じ公開データの上で併存できる。輸送層の合格率が上がっても、内容層のテンプレート率、手続き層の処分分布、統治層のエスカレーション統計が公開されない限り、コミュニティはどちらの主張も検証できない。提案 2019-04 が匿名統計の公開を求めたのは、まさにこの検証可能性のためだった [5]。