要約

  • RFC 1429のDISTRIBUTEは、BITNET LISTSERVの配送網に宛先表とメールを渡し、経路情報が許す範囲で混雑回線上の複製を一つにまとめた。著者は当時の処理量を１日200万～600万通と記した。
  • 配信前にDEBUG=YESで予定経路を調べられた。入口サーバーのMaster nodes fileは２か月より古くないことが条件で、１日１万件を超す宛先には管理者への事前相談が求められた。

５人に送るつもりのメールは、どこで５通になるのか。1993年２月のRFC 1429に載る試験記録では、３件をUGAのLISTSERVへまとめて渡し、２件は地元のSMTPエージェントへ回す。DEBUG=YESなら、この振り分けを実際に配信せず確認できた。大量配信を始める前に、机上の宛先表がどの経路を生むかを見せる仕組みだった。

その仕組みの狙いは、同じ本文を狭い回線に何度も通さないことだ。送信者はJOBカード、DISTRIBUTE MAIL、BSMTPを付けた宛先一覧、本文を一つの依頼としてサーバーに渡す。配送網は得られるトポロジー情報を使い、混雑したリンクを一つの複製が越えてから、宛先群の近くで分ける。著者Eric Thomasは、このサービスが当時１日200万～600万通を運ぶと述べた。

経路の判断材料は放置できなかった。RFCは入口サイトのMaster nodes fileが２か月より古くないか確認するよう指示する。人手不足で表を更新しないサイトもある、と著者は書いた。古い表を持つサーバーに渡せば、巧妙な分岐アルゴリズムも古い道筋を巧妙に選ぶ。実際、文書は配送効率の主因をトポロジー情報の質と正確さに置いている。

入口選びにも同じ現実がある。受け手の大半が米国にいるのに、カリフォルニアからスウェーデンのサーバーへ仕事を持ち込む理由はない。T1のIP回線がある大学でも、BITNET側は9.6キロビットの専用線という場合があった。見かけのIP接続速度から、共有配送網に入る最後の細い線は読めない。

１日１万件を超す宛先を予定するなら、LISTSERVの管理者から許可を得ることも勧めた。大学によっては昼間の大量配信を制限し、定期停止もある。配信能力は共有資源であり、入口サイトの運用者にはその割り当てを決める権限があった。

依頼の失敗通知も行き先を分けた。SMTPのMAIL FROMは依頼がサーバーへ届かなかったとき動ける担当者へ。依頼メール中のRFC822 Fromは、その後の配送問題や返送先へ。ここにメーリングリストの投稿アドレスを入れると、返送が再投稿されループになりうる。TRACE=YESは配信しながら経路を報告し、通常運用のECHO=NOは資源使用報告を抑える。報告を増やすかどうかも運用費だった。

Thomasが示したBITNET宛先の典型的な所要時間は５～15分、近くへ引き渡せるインターネット宛先は５～20分だった。経路情報のない宛先はさらに長くかかりうる。速さの主役は魔法のメールコマンドではない。宛先をまとめる前に、誰かが地図を更新し、細い回線を見つけ、入口サイトの負担を引き受けていた。