要約

  • 公式 API 文書は、返される虐待連絡先情報が「多くの場合、不正確であるか、入手できない」と明記している。
  • ルックアップはボトムアップ方式で、最初に見つかった abuse-c を返すのみで、その運用者が実際に対応できるかは評価されない。
  • 五星評価は 2015 年に廃止され、不確実性の可視化は API 免責の一句に置き換えられた。

はじめに

虐待通報の宛先が誤っている場合、通報そのものが効果を失う。IP アドレスを RIPEstat に入力すると、その IP が属するネットワーク — つまり「ISP などのネットワーク運用者であり、虐待者ではない」— の虐待連絡先が表示される (RIPE NCC の公的案内)。しかし、表示されたアドレスが正しい運用者に届く保証はどこにあるのか。

「多くの場合、不正確または入手不可能」という API 自身の免責

RIPEstat の Abuse Contact Finder の公式文書は、エンドポイントが照会されたプレフィックス・IP・ASN に対して abuse_contacts（専用の虐待用メールアドレス）と authoritative_rir を返すと説明しながら、返される情報が「多くの場合、不正確であるか、入手できない」と明記している (API 文書)。ツールの提供者自身が精度の限界を宣言しているという事実は、依存する側がその限界を織り込むべきであることを意味する。

廃止された五星評価

かつての Abuse Contact Finder は五星形式の信頼度評価を持っていた (RIPE Labs)：5 星は照会した IP 上で ripe-563 に適合する abuse-c、4 星は関連オブジェクト内の abuse-mailbox、3 星は remarks 属性にのみ見つかる連絡先、2 星はより具体的または上位オブジェクト由来の abuse-mailbox（「正しい連絡先ではない可能性がある」）、1 星は「正しいとはかなり考えられない」。

2015 年以降、評価ヒューリスティクスは廃止され、RIPE 文書 563 に記載された abuse-c のメールアドレスをそのまま表示するだけになった (同上)。不確実性を表面化する仕組みが消え、資格のない単一のアドレスと API レベルの免責だけが残った。同じページでは、リソース保有者が提供する虐待連絡先を「訂正・検証する手続きが RIPE NCC 側にも利用者側にも整備されていない」という職員の返信が記録されていた。

ボトムアップ方式：最初に見つかった abuse-c が返される

ripe-563 の実装を説明する RIPE Labs の記事によれば、ルックアップはボトムアップで動作する (同記事)：INET(6)NUM オブジェクトからリンクされた ORGANISATION オブジェクト内の abuse-c: 参照を検索し、最初に見つかったものを返す。いずれかの abuse-c: 参照が見つかった場合、レガシーの abuse-mailbox: 属性は考慮されない。つまり、返されるのは「データベース上の最も具体的な abuse-c」であって、実際に対応できる運用者とは限らない。RIPE データベースの文書も、abuse-c: は組織オブジェクト内の属性であり、その組織を参照する inetnum・inet6num・aut-num はすべて同一の虐待用アドレスで覆われると説明している (RIPE Database 文書)。包含するオブジェクトに虐待連絡先が見つからない場合、結果は何も返されない。

ヒューリスティクス時代の文書化されたバグ

ripe-563 以前のヒューリスティック型 Abuse Finder は、1 回のルックアップでおよそ 30〜150 回の別個の RIPE データベース照会を行い (更新記事)、「ベストエフォートの提案」しかできず「信頼性がなく論争の的となっていた」。文書化されたバグには、プレースホルダーデータのせいで頻繁に誤って登記庁自身のプレースホルダーアドレスを返すもの、オブジェクト型間で主キーと索引キーが一意でないため入力と無関係な結果を返すものがあった。この系統の誤りは、プレースホルダーやレガシーデータが階層構造と交わる場所に誤経路リスクが集中することを示している。ripe-563 の実装記事は、データベースから得られる全アドレスに通報を一斉送信する行為を非生産的だとし、RIPE NCC がそうした做法を勧めないことを明示している (同上)。RIPE データベースの文書も、データベース内の他のメールアドレスへ通報を複写しても対応が速くなることはないと警告している (RIPE Database 文書)。

検証は到達可能性のみ：正しさは含まれない

ポリシー提案 2017-02 は、ripe-563 が abuse-c: 情報の検証を提供しなかったこと、RIPE NCC が毎年数百件の無効な連絡先情報の報告を受け取っていること、予備的な無作為検査で abuse-mailbox 属性の 10〜25% が不正確または非活性である可能性を示したこと、データベースに約 70,000 の個別の abuse-mailbox 属性が存在したことを記録した (提案 2017-02)。導入された自動検証は構文・ドメイン・メールサーバー設定を確認し、偽陰性・偽陽性の可能性を認める (同上)。RIPE NCC は検証の範囲を明確にしている：「動作するメールが存在し、メールサーバーがメールを受け入れられることを確認するだけ。ネットワーク運用者が受け取った虐待通報をどう扱うかについて、われわれに発言権はない」(RIPE Labs)。有効な abuse-c は、正しいまたは効果的な宛先を保証しない。

RIPE 80 の数字

RIPE 80（2019 年）の発表資料によれば (RIPE 80 スライド)、77,168 件の個別 abuse-mailbox エントリのうち 71,711 件（93%）が自動検証に合格し、5,457 件（7%）が不合格だった。不合格の内訳には、他組織の偽メールアドレス、一度も読まれないメールボックス、満杯またはバウンスするメールボックス、存在しない従業員が含まれていた。自動検証は到達可能性を測るものであり、通報が適切な当事者に届くかどうかは測っていない。

結論

Abuse Contact Finder のルックアップ層は、自身の文書が「多くの場合、不正確または入手不可能」と認める精度限界の上に立っている。五星評価の廃止により不確実性の可視性が失われ、ボトムアップ方式の最初の一つだけの返答、ヒューリスティクス時代に文書化されたバグ、および到達可能性しか測らない検証が重なり、虐待通報が誤ったメールボックスに届くリスクは構造的に残っている。依存する側は、この限界を宛先選択と通報設計に織り込む必要がある。