要約

  • RFC 1173は1990年のインターネットにおける「口頭伝承」を記した情報文書であり、標準でもIABの政策でもない。ローカルおよび地域の方針がその慣行を補い、変更できると明記している。
  • postmasterやNOCは、観測された問題を適切なローカルな役割へ運ぶ宛先である。宛先は、事実認定、本人性、他組織への操作権限、結果のいずれも単独では保証しない。

連絡可能性を、支配の言葉にしなかった文書

RFC 1173の価値は、当時の運用上の不便を美化していないところにある。著者のJames VanBokkelenは、それをインターネット上の慣行についての自分の見解、すなわち「口頭伝承」の要約として出した。文書自身が、これは標準でもIABの政策でもないと述べる。さらに、個別のローカルまたは地域的な構成要素の政策は、この慣行を補足または修正できるとしている。

したがって、これは全ての接続先に同じ指示を送る設計図ではない。ルーティングのループ、誤った設定、メール・リレーの停止、電源障害のような局所的な出来事が、別の場所の利用者には到達不能という形で現れるとき、誰が話を聞き、どこで確かめるかを扱う文書である。

症状を見た側には、経路表、ホストのログ、設定、物理的な接続状態が見えないかもしれない。逆に、それを見られる側は、その症状が他所で既に観測されていることを知らないかもしれない。RFC 1173は、担当者がメールと電話で連絡可能であり、問題報告や診断の働きかけに応答すべきだとした。その連絡可能性は、分散した組織構造の中に置かれている。文中の「Ma Datagram」という単一の巨大な提供者への言及は、全ネットワークを上から管理する主体を想定していないことを印象づける。

連絡経路がするのは、問いを届けることだ。届けられた問いは、まだ原因の証明ではない。メールが失敗したという観測から、経路、DNS、設定、容量、利用者のアドレス、あるいは別の組織の状態のどれが原因かは直ちには分からない。連絡先は、推論の出発点を作るが、推論の終点を先取りしない。

担当者には、ローカルな能力が求められた

RFC 1173のネットワーク管理者像は、名簿に名前を載せるだけのものではない。接続された各IPネットワークまたはサブネットには、一人以上の責任者がいるべきで、連絡情報はInternet NIC、またはローカル・地域のトランジットネットワークのNICに提供・更新されるべきだとした。そして決定的なのは、管理者が当該ローカルネットワークに接続するホストやルーターについてシステム管理アクセスを持つか、あるいは、異常なホストを停止、再起動、物理的に切り離し、IPデータグラムの転送を無効化できる権限とアクセスを持つことだった。

これは、外部から警告した人に同じ操作権限を配る規則ではない。操作する資源の近くに、道具、状況理解、そして誤った操作の結果を負う立場を置く規則だった。遠隔の参加者は影響を報告し、調査を求められる。しかし、管理者の氏名やメールアドレスを知っただけで、そのルーターへの資格情報を得ることはない。

ホスト・システム管理者についても、RFCは構成、運用、アクセス制御に必要な権限、アクセス、道具を求める。責任だけで道具がなければ、連絡先は儀礼になる。道具だけでローカルな責任がなければ、変更の説明と訂正が難しくなる。RFC 1173は両者を組にするが、その組を他者の資源に対する一般権限へと広げない。

ここにはもう一つの重要な区別がある。担当者が連絡可能であることは、報告が正しいことを意味しない。深刻そうな報告であっても、停止や遮断が比例した反応であるとは決まらない。報告、ローカルな検証、決定、操作は、時間的にも責任の上でも別の出来事である。

postmasterは、問題の宛先だった

postmasterは、この仕組みを最も分かりやすく表す。RFC 1173は、ローカルネットワークの外へメールを扱うインターネット・ホストがこの名称のメールボックスを維持すべきだとし、配送問題の通常の連絡先として説明する。遠隔の保守者は配送上の異常をそこへ送れ、配送不能の自動メッセージも返信先としてこれを示し得る。定期的に読まれないメールボックスは、局所的な問題を大量の返送や喪失へ広げるため、文書は注意を求めた。

それでも、メールボックスはメールボックスである。受信は、特定の人が読んだこと、報告が完全であること、あるいは障害の原因が判明したことを証明しない。配送不能は、満杯のディスク、別名、クォータ、名前解決、キュー、送信者から見えない条件から生じ得る。postmasterは観測をローカルな調査の入口へ運ぶ。入口自体が判決になるわけではない。

RFC 2142は後に、この種の役割名を整理した。組織内のサービスまたは役割に適した人員へ連絡するためのメールボックス名を定義し、NOC、SECURITY、ABUSE、POSTMASTER、HOSTMASTERを含めた。よく知られた名前の範囲は組織のドメインである。これは重要な制限である。役割名は、あるドメインの中で期待される責任へのルートであり、全世界で通用する本人確認でも、別ドメインへ変更を命じるAPIでもない。

RFC 5321も、SMTPの輸送層で同じ限界を保つ。メールを中継または配送するSMTP受信者は、提供するドメインに対して、大文字小文字を区別しないpostmasterを受け付けなければならない。ただし狭い安全上の例外はある。ここで要求されるのは宛名を受け入れることだ。誰かが調べること、申し立てを認めること、行動を選ぶこと、結果を出すことの保証ではない。

報告は、観測として大切だった

RFC 1173は日常の利用者を軽視していない。今朝は届いたのに今は届かない、という知らせは、運用者がまだ見ていない変化を示すことがある。しかし文書は、それを完全な事故記録にはしない。ネットワーク全体に影響し得る問題を、利用者関連、ホスト関連、ネットワーク関連に分けた。分類は、同じ症状から原因や意図を早急に決めないための構造である。

利用者関連ならメーリングリスト、プライバシー、侵入の試みがあり得る。ホスト関連なら旧いソフトウェア、設定、バグがあり得る。ネットワーク関連なら到達性の広告、ループ、ブラックホールがあり得る。外から見える一つの失敗は、このどれかを自動的に選ばない。ログ、トポロジー、設定、資源の範囲を確認できるローカルな側が、その空白を埋める必要がある。

安全性について、RFC 1173はさらに慎重である。安全は主観的であり、一つのサイトが単なる好奇心と見る行為を、別のサイトは敵対的な探査と見ることがある、とする。他サイトの懸念を真剣に扱うよう求めながら、各ホストの安全に最終的に責任を負うのはそのホストの管理者だとも述べる。聞くことは、無条件に結論を受け入れることではない。

分散した協力が守ったもの

RFC 1173を、遅い中央サポートの前史として読む必要はない。そこには、観測、連絡経路、ローカルな役割、検証材料、資源についての決定、説明可能な結果という連鎖がある。各段階は別の種類の誤りを留める。

報告を証拠として扱えば、仮説が技術的な処分になる。役割名を本人性として扱えば、別名が人についての断定になる。連絡先を権限として扱えば、助けを求めるメッセージが他者の資源への命令になる。RFC 1173の分散性は、協力の欠如ではない。協力が、証拠、所有、操作結果の負担を消してしまわないための配置である。

このRFCは、現在の当番体制、契約、適用法、ネットワークの所有者、メールボックスの背後の個人を決めない。今日の障害、侵入、意図、対応時間、導入状況、結果を証明もしない。歴史的な教訓はより限定的である。問題を知らせる道を開き、操作する権限を資源の近くに保つことで、協力は可能になり、判断の誤りも後から理解し訂正できる。

情報源と証拠の境界

凍結した情報源はRFC 1173、2142、5321である。RFC 1173は情報文書としての地位、分散した文脈、ローカル管理者の能力、postmaster、問題の分類と安全性の文脈を支える。RFC 2142はドメイン範囲の役割メールボックスを支える。RFC 5321はSMTPでのpostmaster受理を支える。いずれも、現在の可用性、本人性、権限、事故、決定、導入、結果を立証しない。