要約

  • RIPEのabuse-c属性は、受理された共同体ポリシー提案2011-06に由来し、現行文書はripe-705である。aut-numと直接割り当てには必須で、より具体的な空間への階層的継承が定められ、RIPE NCCは最低でも年1回abuse-mailboxを検証することとされている。
  • 維持責任は資源保有者側にある。ただしabuse-c情報ページが示すように、保有者が対応しない場合、RIPE NCCは2013年12月から会員名簿のメールアドレスを、2014年11月からはスポンサーLIRのabuse連絡先を自動設定した。いわばNCC自身が作ったプレースホルダーである。
  • 2016年1月、RIPE NCCは「abuse-cはRIPE DBスキーマ上の必須属性ではないため実務上の執行が困難」と認めた（anti-abuse-wgスレッド）。ポリシーの義務とスキーマの執行の間には、記録に残る溝が存在する。
  • 量としての姿は明らかだ。RIPE 87の議事録でMarco Schmidt（RIPE NCC Registration Services）は約9万件の異なるabuse-c連絡先を挙げ、週約2,000通の検証メールの「6～8%が失敗する」と述べた（RIPE 87議事録）。2019年のRIPE 80では77,168件のabuse-mailbox属性のうち71,711件（93%）が自動検証に合格し、5,457件（7%）が不合格だった（RIPE 80資料）。
  • 検証は「メールボックスが存在し受信できること」を確認するだけである。RIPE 80の資料は自ら、現行ポリシーでは実際の可用性の検証が十分でなく、ポリシーの意図はケース処理の監視にないと明言している（RIPE 80資料）。

ポリシーの起源と維持の連鎖

abuse-cの設計は単純である。inetnum、inet6num、aut-numの各オブジェクトはorganisationオブジェクトを参照し、そのorganisationはabuse-mailbox属性を持つロールオブジェクトを指す。提案2011-06はこの属性を導入し、abuse-mailboxを保護属性として、参照されている間は削除できないものとした。ripe-563（2012年）とripe-705（現行）は、このモデルを確定した。

維持責任は契約のように階層化されている。割り当て資源ではLIRが、スポンサーLIR経由のPI資源やASNでは最終保有者が、連絡先を正しく保つ義務を負う。実装ページ（abuse-c情報ページ）は、連絡先メールを変えるには当該ロールオブジェクトのabuse-mailboxを編集すると明示する。

NCCが作ったプレースホルダー

記録が示す最初の転換点は、保有者の不作為に対するNCC側の対応だった。2013年12月、RIPE NCCはLIRが設定しなかった割り当て資源に、会員名簿に登録されたLIRのメールアドレスをabuse-cとして自動設定した。2014年11月の第2段階では、維持者が更新しなかったスポンサード資源のorganisationオブジェクトに、スポンサーLIRのabuse連絡先を自動追加した（abuse-c情報ページ）。

つまり、今日データベースに存在する連絡先の一部は、資源保有者の意思ではなく、RIPE NCCが記録の完全性のために作成した代理の役割アカウントである。2016年のanti-abuse-wgスレッド（スレッド記録）でNCCは、スポンサーLIRのメールが使われていると「最終保有者に対応インセンティブがない」、LIR側は自分のメールがスポンサード組織のabuse-cに現れて「不快な驚き」を覚えた、と書き残し、プレースホルダーの発信元をend-user組織のメールへ移す提案をした。新しいLIRの活性化時には自動的にabuse連絡先が作られるが、修正はできても削除はできない。

スキーマとポリシーの溝

同じスレッドで、RIPE NCCのTim Bruijnzeelsは次のように認めた。「実務上、これを執行することは困難であることが証明されている。abuse-cはRIPE DBスキーマの必須属性ではないからである」。2011-06が描いた「必須」は、2016年時点でスキーマ水準の強制を伴っていなかった。DB-WG共同議長のDenis Walkerは継承の仕組みを明確にした。より具体的なinet(6)numは、別のorganisationを参照しない限り、上位オブジェクトのorg/abuse-cを継承する。

再販チェーンの裸のロールオブジェクト

LIRが顧客への割り当てを管理する再販構造では、abuse-cに関するFAQによれば、通常LIRが割り当てオブジェクトを維持し、顧客のorganisation参照を自分で追加しなければならない。顧客用のロールオブジェクトはpersonオブジェクトへの参照を一切必要とせず、公開され照会制限もなく、その内容はすべて業務データとみなされる。つまり、名前も人も持たない連絡先アカウントが、公的申請先として正当に存在しうる。

検証の実際と限界

RIPE 87のAAWG資料（AAWGプレゼン資料）は検証の仕組みを示す。外部検証ツールは書式、DNS、そしてpingによるメールボックスの存在と受信可否を確認し、合格ならメールは送らない。不合格なら検証リンクをabuse-cアドレスへ送り、RIPE NCCにチケットを作成し、まず自動的、次に職員が（スポンサー）LIRに接触する。

その結果の量はRIPE 87議事録（議事録）にある。約9万件の異なるabuse-c連絡先は、LIR組織オブジェクトに約2万件、資源オブジェクトに約5.8万件、独立資源に約1.5万件と分かれ、年間検証を週に割ると約2,000通、うち「6～8%が失敗する」。ただし失敗は必ずしも機能しないことを意味しない。タイムアウトは次回の自動テストや検証リンクのクリックで解消しうる。責任者に到達できない資源の連絡先については、NCC自身がLIRまたはスポンサーLIRの稼働中のabuse連絡先に差し替える。2017年開始のASNクリーンアップでは、13か月間変化のなかった4,000超のASN保有者に連絡し、半数超が回収された。

2019年のRIPE 80資料（RIPE 80資料）は最初の全数回の数字を残す。77,168件のうち71,711件（93%）合格、5,457件（7%）不合格、2019年中に約8,000件が更新された。そして資料自体が、現行ポリシーはabuse-mailboxの実際の可用性を十分に検証しておらず、ポリシーの意図はケース処理の監視にないと述べている。

測定可能な到達可能性と、測定されていない応答

検証が確認するのは到達可能性である。メールボックスが受信することは分かっても、誰が読み、対応するかは検証対象外だ。提案2017-02がripe-563には検証規定がなく、年間数百件の無効連絡先報告、約7万件のabuse-mailbox、ランダム抽出で10～25%が無効または不活性の可能性、と記したとき、問題は「存在しない連絡先」と「読まれない連絡先」の二層に分かれていた。公開記録が測定しているのは前者に偏っている。悪用申請者の体験である応答性については、RIR側の運用統計以外の独立測定を本稿の調査では確認できなかった。

証拠の境界

本稿の定量はすべてRIPE NCC自身の資料と議事録に基づく運用数値であり、第三者測定ではない。なお本稿執筆中に確認した限り、RIPE-658はabuse連絡先データセットの概観文書であって検証結果報告ではなく、arXiv:2602.11102（WHEREIS）はRIR登録の地理整合性の測定研究であってabuse連絡先の応答率の測定ではない。両者を検証成績や応答率の証拠として引用することはしない。

出典一覧