要約

  • RFC 1211 では、不達通知が示すメールボックスが IETF の主リストに直接載っていない事例が続いた。主リストには展開用別名があり、下流のアドレスは別担当者の副リストに置かれていた。
  • Received 行、似たホスト名、SMTP の EXPN や VRFY は調査先を絞る材料になったが、利用不能や拒否も多かった。経路の手掛かりは会員であることの証明ではない。
  • 中央担当者は登録済み所有者や postmaster へ依頼を回せるだけだった。隠れた会員表を確認し変更できるのは遠隔側であり、依頼の送信は完了記録ではなかった。

見つからないことと、届かなかったことは両立した

RFC 1211 の調査手順は、まずエラーに記されたアドレスを主リストで探すところから始まる。単純な作業に見える。しかし検索が空になった瞬間、管理対象の境界が現れる。

当時の大規模リストには、別のリストを一つのメールボックスとして登録する仕組みがあった。exploder と呼ばれる別名にメールを送ると、遠隔サイトで複数の受信者へ展開される。外側のリストに見えるのはその別名だけで、内側の個人アドレスではない。

したがって、下流システムがある個人宛ての失敗を正しく報告し、主リストが同じ個人を正しく「未登録」と答えることができた。主リストの会員表、遠隔の副リスト、配送側の試行記録は、異なる保管者が持つ異なる事実だった。

RFC Editor の記録によれば文書は1991年3月の Informational であり、IETF Datatrackerでは Legacy stream に置かれている。これは一時代の運用報告であって、全リストが従う標準ではない。

大量の自由文を、人が状態に戻していた

Ann Westine と Jon Postel は、ISI で研究グループや IETF など約25のリストを維持し、月に約400件の追加・削除依頼と約300件の配送エラーを受けていたと記した。重複を除いても一日およそ10件を調べる必要があった。これは当時の現場値であり、インターネット全体の統計ではない。

通知の言葉は統一されていなかった。数日後まで再試行する遅延、利用者不明、ホスト不明、特定のOSでしか意味が通じない診断が混在した。一通の通知が複数宛先を含み、暫定状態と終端らしい状態を同時に運ぶこともあった。

そこで担当者は、文字列からまず案件の状態を判定した。一回の遅延を削除理由にはせず、同じホストで何日も続けば調査する。利用者不明に見えても、活動中の参加者なら追加確認する。エラーは作業の入口であり、会員表に対する命令ではなかった。

誤削除は静かに効く。本人が「なぜ届かないのか」と問い合わせるまで発見されないことがある。再登録しても同じ旧アドレスが再び失敗する場合もある。RFC は万能な削除基準を与えず、可逆な判断が必要だった理由を残した。

経路は質問先を示すが、会員表そのものではない

主ファイルに宛先がなければ、担当者は Received 行を読み、既知の exploder と似たホストを探した。UUCP や BITNET、ゲートウェイを越えれば、見える経路と実際の管理関係はさらに離れる。

この照合は有用だが限定的だった。同じ組織内の別部門や別建物が似た名前を使うことがある。中継は経路の一部しか見せない。ヘッダーに残った足跡は、遠隔会員表への登録操作を認証するものではない。

同時代の RFC 821 は、配送エラーを返すための reverse path と、利用者を確かめる VRFY、リストを展開する EXPN を定義した。ただし後二者は最小実装の必須機能ではなく、中継を越えて働く義務もなかった。

RFC 1211 の現場では、まさにそこが止まった。コマンド未実装、展開拒否、別プロトコル世界、接続不能。結果が得られなければ、経路から副リストを推定し、遠隔 postmaster に「もし存在するなら」削除を依頼した。この条件形は弱さではなく、観測していない事実を明示する表現だった。

所有者情報は責任への経路だった

ISI は副リストを受け入れる際、申請者の名を記録し、その人を所有者とみなした。exploder の下流で生じたエラーは現地所有者へ戻し、現地利用者の追加・削除もそこで扱うよう求めた。

外側の担当者が exploder 全体を消せば、多数の正当な参加者まで失われる。個別アドレスの修正には、内側の会員表を見られる側の判断が必要だった。所有者は単なる連絡先ではなく、変更権限を正しい保管場所へ結び付ける役割だった。

ただし連絡先は老朽化する。転職や役割変更で申請者が管理者でなくなる。代替先の postmaster さえ認識しないサイトがあった。RFC 2142 は後に postmaster など共通役割メールボックスの扱いを整理したが、過去のサイトに担当者がいたことや依頼が処理されたことまでは証明しない。

必要なのは、登録時申請者、現在の所有者、依頼の到達、受領確認、判断、適用、保存、後日の観測を分けることだった。古いメールアドレス一個から、その全工程を推測することはできない。

中央の request 宛先は、入れ子全体の管理画面ではなかった

会社の副リストを通じて受信している利用者も、変更依頼を中央の IETF request 宛先へ送った。中央担当者は個人を見つけられず、経路から候補の exploder を選び、依頼をその所有者へ転送した。

転送で責任の向きは整う。しかしデータはまだ変わっていない。遠隔側が記録を探し、申請との対応を確かめ、変更を認め、ファイルへ反映して初めて状態が進む。似たホスト名を取り違えれば依頼先が違い、所有者が古ければ受領すら起こらない。

利用者から見える入口が中央なので、中央が全配布木を操作できるように見える。RFC 1211 が示すのは逆である。調整する力と書き換える権限は同じではない。

後年のSMTPも未知を消さなかった

RFC 5321 は、安全上の理由で VRFY と EXPN を無効化できるとした。また、実際に検証した場合と、妥当そうでもリアルタイム確認できない場合を異なる応答にした。非公開や確認不能は「存在しない」ではない。

RFC 3464 の配送状態通知は expanded を非終端状態として扱い、その後も遅延や失敗があり得るとする。これは展開と最終配送を分ける後年の語彙だが、RFC 1211 の自由文通知を遡って構造化するものではなく、報告MTAに他組織の会員表を変える権利も与えない。

不達アドレス、外側の別名、経路証拠、照会結果、記録済み連絡先、現所有者、変更依頼、適用結果、次回配送は一続きであって一つではない。「不達なら削除」という短縮は、この連鎖の最も重要な部分――誰がその事実を保管し、誰が変えられるか――を失わせる。

出典