要約

  • RIPEstat の Abuse Contact Finder は、プレフィックス、単一の IP アドレス、ASN を入力に取り、濫用連絡先（abuse_contacts）と管轄 RIR（authoritative_rir）を返す。ツール自身のドキュメントは、その情報が「多くの場合、不正確であるか、利用できない」（in many cases incorrect or not available）と警告している。
  • RIPE NCC によるポリシー 2017-02 の検証が確かめるのは、書式、DNS エントリ、ボギー／ハニーポット、ping によるメールボックスの到達性までである。メールは送信されない。廃案となった 2019-04 の提案ページは「この検証プロセスは、濫用事案がどのように処理されるかを確認しない」（This validation process will not check how the abuse cases are processed）と明記していた。
  • 実装記録では、abuse-mailbox 属性 77,168 件のうち 71,711 件（93%）が自動検証を通過し、5,457 件（7%）が失敗した。2023 年の RIPE 87 で報告された定常状態でも、週およそ 2,000 件を検査し、6〜8% が失敗し続けている。
  • 独立系の測定は、報告後の対応が報告者と事案の種類に強く依存することを示す。480 件の報告を用いた実験では、89 件のメール応答のうち明確に人間が書いたものは 12% にとどまり、無応答は未対応を意味しなかった。

報告者が出会うルーティング

Abuse Contact Finder は、プレフィックス、単一の IP アドレス、または ASN を入力として受け取り、該当する濫用連絡先のメールアドレスと、その資源を管轄する RIR を返す。ツール自身のドキュメントは、返される情報が「多くの場合、不正確であるか、利用できない」（in many cases incorrect or not available）と警告している（RIPEstat エンドポイント文書）。報告者にとっての使い方は単純だ。ウィジェットに IP アドレスを貼り付け、表示された宛先へログとタイムスタンプを添えて送る。2015 年以降、ウィジェットは ripe-563 に従って abuse-c のメールアドレスのみを表示し、報告メールにそのまま使える定型文も用意している（RIPE Labs の解説）。

CERT や濫用対応者のための指針である RIPE-658 は、RIPEstat の Abuse Contact Finder と Registry Browser を「最適な濫用連絡先」（best matching abuse contact）を見つける手段として挙げ、abuse-c を「あらゆる形態の濫用を報告する際の望ましい経路」（the preferred way to report any form of abuse）と位置づけている（RIPE-658）。

RIPE NCC 自身の説明はさらに踏み込んでいる。IP アドレスを RIPEstat に入力すれば、そのアドレスが属するネットワークの濫用窓口が分かる。責任を負うのはネットワーク運用者であり、RIPE NCC ではない。RIPE NCC が担うのは、RIPE Database 上の濫用連絡先が有効で最新であることを保証する部分に限られ、「ネットワーク運用者が返信しないことを選んだ場合、私たちにできることは何もない」（There is nothing we can do if a network operator chooses not to reply）と記している（RIPE NCC の濫用報告ガイド）。

検証が確かめているもの、確かめていないもの

ポリシー 2017-02 に基づく RIPE NCC の検証ツールは、書式エラーの検出、DNS エントリの確認、ボギー／ハニーポット型メールボックスの探索、そして ping による「メールボックスが存在し、メールを受け取れるか」の確認を行う。検証はメールを送信しない。通過した場合、運用者に求められる行動はない。レガシー資源はこのポリシーの対象外であり、RIPE NCC は「ネットワーク運用者が受け取った濫用報告をどう扱うかについて、私たちに発言権はない」（We have no say in what network operators do with any abuse reports they receive）と述べている（検証方法の解説）。

この境界線は、廃案となった提案 2019-04 のページに最も明快に現れている。6 か月ごとの再検証を求めたこの提案は、検証の対象を「abuse-mailbox が存在し、メッセージを受信できるかどうか」に限定し、「この検証プロセスは、濫用事案がどのように処理されるかを確認しない」（This validation process will not check how the abuse cases are processed）と記していた。RIPE NCC の影響分析は、約 93,000 件の abuse-mailbox 属性に対して 6 か月ごとの検証を行う場合、1 ラウンドあたり 32,000 件超（年間 64,000 件）のチケットが必要で、うち年間およそ 19,200 件が手作業になると試算した。提案は 2020 年 9 月 8 日に撤回され、同年 10 月 26 日、Anti-Abuse WG 共同議長の判断に対する異議申立てを WG Chairs Collective が退けた（ポリシー提案 2019-04）。

数字が示す規模と定常状態

検証が実際に動いてきたことは、公表された数字から確認できる。2019 年 10 月 10 日の完全実装時点で、abuse-mailbox 属性は 77,168 件存在し、71,711 件（93%）が自動検証を通過、5,457 件（7%）が失敗した。2019 年だけで約 8,000 件の属性が更新され、初期検証には一時雇用のフルタイム 3 名を要し、チケットの 20〜25% は手作業のフォローアップを必要とした（2017-02 実装サマリ）。

2019 年 5 月の中間報告では、確認した約 67,000 件（重複を含む）のうち約 9,500 件の連絡先が更新され、約 60% のケースは RIPE NCC 職員の介入なしに解決した。約 50 件の独立資源がスポンサー状態を変更したことも記録されている（進捗報告）。

2023 年の RIPE 87 で示された定常状態はこうだ。年間で LIR 組織オブジェクトの約 19.6K、LIR 資源オブジェクトの約 58.1K、独立資源オブジェクトの約 15.4K の連絡先が検証され、週におよそ 2,000 件が検査される。失敗率は 6〜8% で推移する。資源オブジェクトの無効な abuse-c は、動作する LIR の abuse-c に置き換えられる。LIR 側の abuse-c が無効な場合は広範な調査が始まる。会員が長期にわたり応答しない場合、会員資格の停止もあり得る。ASN のクリーンアップでは 4,000 件超の ASN 保有者に連絡し、約 2,150 件（54%）の ASN が返却された（RIPE 87 の AAWG 資料）。

到達性の先にあるもの

検証が到達性で止まる一方、報告の「その後」については独立系の測定がある。480 件の濫用報告をランダム化比較の形で送った実験では、89 件のメール応答が得られ、そのうち明確に人間が書いたと判断できたのは 11 件（12%）だった。78 件（88%）は機械生成だった。注目すべきは、気づいた当事者が応答しないまま是正だけを行ったケースが多く、無応答が未対応と同義ではないという点である。詳細な報告はクリーンアップ率を有意に高めた（480 件の報告実験）。

2026 年の NDSS の研究は、ホスティング事業者の内部データを用い、顧客への通知と緩和措置が報告者と濫用のカテゴリーに強く依存すると報告した。児童性的虐待コンテンツやスパムに関する報告は緩和措置につながりやすい一方、著作権侵害やポートスキャンの報告は軽視されることが多く、個人による報告は「easily ignored」されやすい（NDSS 論文）。

報告者側の慣行も、この非対称性を前提にしている。CSIRT.CZ のインシデント報告 FAQ は、RIR データベースから IP アドレスの責任組織を特定し、割り当て先の登録済み濫用連絡先に報告する手順を示したうえで、数日以内に妥当な応答がない場合にのみ CSIRT.CZ へエスカレーションするよう求めている（CSIRT.CZ）。

公開記録に残る空白

公開記録には、埋まっていない部分がある。検証失敗の内訳（書式、DNS、ping のどれで落ちたか）を段階別に示す資料は見当たらない。2019 年 5 月の「約 67,000 件」と 10 月の「77,168 件」は範囲と時点が異なる。会員資格停止が実際に発動された事例は、公開されている資料からは確認できない。学術研究と NDSS の対象はホスティング事業者や DNS・ウェブの濫用であり、RIPE の abuse-c メールボックスそのものではない。2023 年の定常状態の数字が現在も同じとは限らない。そして、abuse-c に送られた報告の結果を独立に監査した公開指標は存在しない。

RIPEstat Abuse Contact Finder の位置づけと関連資料はディレクトリ項目にまとめている。