要約

  • RIPE NCCの年次検証は、abuse-mailbox属性の存在とメールボックスの到達性を、メールを送らない自動技術チェックから確かめる。
  • 検証は通報の処理を測らない。処理状況を示す匿名統計は、登録機関自身が「収集し、定期的に公表すべき」と述べる段階にある。
  • 不合格時の手順は、チケット発行、LIRへの照会、1週間間隔の再接触、電話など代替手段、最終手段としての会員資格停止・資源登録解除へと段階的に強まる。

義務づけられた「窓口」

ポリシー文書RIPE-563（Abuse Contact Management in the RIPE Database）は、inetnum、inet6num、aut-numの各オブジェクトにabuse-c属性を必須とし、発効時点では従来型（レガシー）インターネット資源に及んでいなかった。参照される役割オブジェクトには単一のabuse-mailbox属性が必要で、その窓口はWHOISとAPIを通じて公開され、メッセージを受信でき、送信者にウェブフォームの利用を強制してはならない（RIPE-563の要件）。

毎年行われる検証

2017-02「Regular abuse-c Validation」として提案された方針の下で、RIPE NCCはabuse-mailbox属性を少なくとも年1回、能動的に検証している（2017-02の検証方針）。個々の通報への対応とは別に、窓口そのものが維持されているかを定期的に確かめる仕組みである。

メールを送らない自動チェック

検証は、メールを送信しない自動技術チェックから始まる。アドレス形式の誤りの確認、DNSの確認、偽のアドレスやハニーポットの検出、メールボックスがメールを受け取れるかの試験が含まれる（自動チェックの内容）。確かめられるのは属性の存在と到達性であり、通報が届いた後の処理は評価の対象ではない。

不合格だったときに何が起きるか

検証に失敗すると属性は無効と印され、チケットが生成される。責任あるLIR（独立資源の場合はスポンサーLIR）に確認が求められ、窓口には検証リンクが送られ、実際には機能している窓口が誤って無効とされた場合にそれを解消できるようにする。応答がなければ1週間間隔でさらに2回接触し、その後は担当職員が電話や代替の連絡手段を試みる。最終手段として、RIPE NCCは会員資格の停止とインターネット資源の登録解除の手続きを開始することがある（不合格時の手順）。

公表されている数字とその限界

RIPE NCCの報告によれば、検証ツールの初期の試行では、abuse-mailbox属性のおよそ10〜25%が不正確または無効である可能性が示唆された。後の検証ラウンドでは、自動技術チェックを約92.5%が通過したとされている。同じ文書は、通報がどう処理されたかについての匿名化された統計を収集し、定期的に公表すべきだとも述べている（検証の実績報告）。いずれも登録機関自身が公表した数字であり、独立の監査を受けたものではない。測定方法やラウンドが異なるため、単純な改善の推移として読むことはできない。

到達性と対応のあいだ

この検証が答える問いは狭い。メッセージを届けられるか、という一点である。到達性は安価に自動化でき、資源全体の規模で点検できる。一方、届いた通報の処理は人間の判断を伴い、文脈に依存し、現在の検証手続きには含まれない。報告者の側から見ると、窓口への到達は確認できても、その先の行動は見えない。説明責任の可視範囲はメールボックスで終わっている。

エスカレーションの最終段階も、被害の回復ではなく資源の継続性に働く。会員資格の停止や資源の登録解除は重い手段であり、発動は遅く、対象は窓口の性質ではなく会員の地位である。また、発効時に要件が及ばなかった従来型資源では、窓口の空白が残りうる。92.5%という通過率も、残りの約7.5%がどうなったか、通過した窓口が通報をどう扱っているかについては何も語らない。

BTWディレクトリの関連項目（日本語版）はこちら。