要約

  • RFC 784はTOPS20上のメール配送係を描いた。宛先ホストの能力表を見て、TCP上のMTP、NCP上のMTP、従来のNCP上のFTP、特別な経路を選ぶ。
  • RFC 785は本文と配送管理を二つのファイルに分けた。管理ファイルには差出人、宛先ごとの経路、本文への参照があり、届けられた宛先と待機する宛先を更新できた。

四人に同じ手紙を送るなら、本文は一通、宛名が四つあればよい。ところが初期のメール作成プログラムには、宛先の数だけ本文のファイルを作るものがあった。Suzanne SluizerとJon Postelは1981年7月のISI TOPS20向けMTP実装を記したRFC 784で、手紙と配達伝票を分けた。閉まった道があれば直すのは伝票のほうだ。文章まで毎回清書する必要はない。

道は実際に複数あった。二人がBLISS-10で作ろうとしていたMTPの送受信プログラムは、TCPと従来のNCPを使い、ほかの郵便方式にも接続する構想だった。作成プログラムやネットワークの受信プログラムが利用者のディレクトリーにファイルを置く。裏で働く配送プログラムが出力先を選ぶ。使える経路があれば、利用者側からすぐ送る版も想定した。宛先ホストの能力表には、TCP上のMTP、NCP上のMTP、古いNCP上のFTPという選択肢が並んだ。別の表は、UCLが作った方式を通して英国のホストに送るような特別扱いを記録した。

一通のメールでも宛先が違えば経路も違う。管理ファイルには配送情報と本文ファイルへの参照を入れる。本文ファイルにはRFC 733形式のヘッダーを含む手紙の内容を入れる。一人への処理が終われば管理ファイルの待機項目を消したり印を付けたりできる。別の経路が使えないとき、その宛先は残しておく。本文は各配送で読み取られ、地元の処理が終われば改名や削除の対象になる。変わり続けるのは配送の仕事なので、その仕事だけを別の紙に載せた。

ファイル定義をまとめたRFC 785は伝票の書式を具体的にした。FILE:には本文ファイルの完全な名前、FROM:には差出人の経路、繰り返すTO:には宛先ごとの経路を書く。もう一方にメールヘッダーと本文がある。著者たちは、To、Cc、BccのN件の宛先にN個の本文を作る旧方式と比較した。このインターフェースは宛先が何人でも二つのファイルで始められる。画面に見える宛名欄と、配達係が辿る経路は別の役割を持つ。

別の方式に渡す窓口も必要だった。RFC 786はMTPとNIMAILのファイル交換を記し、パーセント記号を用いたアドレスとMTPの経路表現を変換する例を載せた。どの通信路を選ぶかだけでなく、次の仕組みが読める宛先の形にする仕事もあった。メールの道案内は、封筒の書き方から始まる。

RFC 784には、著者たちが作成中の部分、他の作成プログラムの改修に期待した部分、これから整える表が列挙されている。RFC 785はその計画に詳しいファイルの接点を与えた。設計から分かるのは、宛先ごとに仕事の進み方を別々に記録する発想だ。ある人への道が通じ、別の人への道が閉じていても、一通の本文に違う待機状態を結び付けられる。

机の上に一通の手紙がある。その隣に宛先と経路を書いた札があり、係は建物ごとに使える扉を知っている。1981年の扉にはTCP、NCP、NCP上のFTPと書かれていた。一つの扉が閉まれば、その行は札に残る。ほかの手紙の行き先は先へ進める。二つのファイルは、郵便局の仕事をコンピューターに映したような仕掛けだった。