要約

  • RFC 1465 は、X.500 による経路配布が整うまで、コミュニティ、ドメイン、中継 MTA、担当者、ネットワーク、プロトコル、優先度、有効期間を共通書式で扱った。
  • START は宣言が適用される日を表すだけで、各拠点の受領と導入、アドレス検証、接続、メッセージ引受、最終配送には別々の証拠が必要だった。

X.400 の MTA は同じ土台に乗っていなかった。X.25 上の TP0、CLNS 上の TP4、TCP/IP 上の RFC 1006 という具合に、複数の組み合わせが並存した。二つの MTA が通信するには共通のスタックだけでなく、相互接続された共通ネットワークも必要だった。宛先側で接続元を事前登録する場合もある。

1993年5月の RFC 1465 は、この複雑さを静的な調整文書に落とした実験仕様である。将来は X.500 ディレクトリが経路情報を保持する。その間は複数スタックを話す MTA を中継点にし、管理者が同じ形式の表を交換するという設計だった。

一つの表ではなく、四種類の責任

COMMUNITY 文書は共同体の識別子、調整窓口、文書サーバー、ネットワークとスタックの語彙を定めた。RELAY-MTA 文書は接続方法を記した。DOMAIN 文書は X.400 アドレスの部分木と担当者、中継、優先度を結んだ。PERSON 文書は連絡先を保持した。

参照がつながっても、対象は同一ではない。中継キーは管理ドメインの要素を含むことがあるが、RFC はそれをアドレスではなく参照用文字列と説明した。ドメインを担当する人、中継する MTA、配送先の利用者も別の主体である。

調整窓口は文書集合を配る。ドメイン管理者は担当範囲を申告する。中継運用者は接続を設定する。各サイトの管理者は受け取った情報をローカル設定へ反映する。共通書式はこの分業を見えるようにしたが、どの工程も自動的には完了させなかった。

未来の日付を先に配る意味

文書には更新日、必須の開始日、任意の終了日が入った。自動化がない環境で準備時間を確保するため、開始前の公開が認められていた。

この設計では、同じ瞬間に複数の正当な状態が存在する。調整側は新版を承認済み、あるサイトは導入済み、別のサイトは取得のみ、さらに別のサイトは旧版のままかもしれない。開始日を迎えても、文書上の宣言が有効になるだけで、全 MTA の収束を確認する分散 ACK は生成されない。

終了日も削除命令そのものではない。実際の稼働表から消えたかは各サイトで観測する必要がある。RFC 2626 の1999年の監査付録は RFC 1465 の yymmdd を検出した。これは2桁年の解釈に注意が必要だったことを示すが、実装障害が発生した証拠ではない。

優先度は「次に試す先」を決めた

主中継と副中継、さらに中継やサービスタイプの優先度が定義された。接続に失敗すれば別サービスを試し、それでも失敗すれば同順位または下位順位の別中継へ進む。代替がなければ同じ中継を再試行する。

これは現在の健全性を返す仕組みではなく、失敗時を含む選択手順である。主中継という役割も、優先度の数値も、その瞬間の負荷や受付可否を測らない。

RFC は各コミュニティに更新手順を求め、自動更新は慎重に検討すべきだとした。中継数が増えれば、各地の表を最新に保ち、接続を継続監視する負担も増える。冗長な記載が耐障害性になるのは、代替設定が導入され、実際に接続できる場合だけだった。

X.25 の変更が上位の安定を破った

特に鋭い注意書きが、発呼側と着呼側のネットワークアドレスにある。一部の X.400 システムは発呼アドレスを検証した。X.25 スイッチの再設定でそのアドレスが変わると、上位層を一切変更していなくても他の RELAY-MTA へ接続できなくなる、と RFC 1465 は述べた。

共有文書ではドメイン、キー、優先度、サービス名が同じままでもよい。しかし対向側が検証する下位の値は変化している。安定した経路宣言が、現実の接続条件を保存しているとは限らない。

そこで任意の診断情報が意味を持つ。ハードウェア、OS、MHS ソフトウェアは最新なら障害解析に役立つ。存在しない利用者名を使うローカル試験や echo server は、接続性と可用性を別に確認できる。試験方法が文書化されていることと、試験に合格したことは同義ではない。

後継計画は不一致を明文化した

RFC 1649 は1994年、O/R アドレスを次ホップ MTA に対応させる静的表を説明した。全 MTA を列挙する表は巨大で変化が激しいため、RELAY-MTA が集約点になった。RFC 1711 は GO-MHS を稼働中の X.400 サービスとし、主に静的な共同体規模の表規則を使うと分類した。

これは運用の存在を示す。同じ表が全拠点に入っていたことや、各メッセージが届いたことまでは示さない。

1995年の RFC 1802 は、中央保守の表は拡張限界に達し、手作業の伝播と導入では世界中の MTA の整合性を保証できないと記した。Long Bud は X.500 への移行を試す計画だった。対応 MTA はディレクトリを直接読み、未対応 MTA 向けには静的表を生成し続ける。

移行には登録、別参加者との接続試験、既存宛先へのデフォルト経路、データ品質、試験後の告知が必要だった。少数の初期 MTA は稼働していたが、大規模な結果はこれから検証する段階で、十分な資源もまだ約束されていなかった。RFC 1801 の長期設計も、目標を結果に変えるものではない。

宣言から配送までを一列にしない

追跡可能な変更には、承認済み文書とハッシュ、公開時刻と有効期間、各サイトの取得、生成表と導入表、ネットワーク・スタック・アドレス検証の一致、接続と引受の応答、配送または不配送報告が要る。

RFC 1465 が標準化したのは主にこの前半である。異なる管理主体の意図を運べるようにした功績は大きい。だからこそ、文書で指定された状態と、走る機械が示した状態を混同しないという教訓も鮮明に残る。