要約

  • RFC 1440は、送信者が相手ホストのアカウントを持たなくても、メールではないファイルを受信デーモンへ送り込める実験を示した。
  • NULL ACKは一つのコマンドを受理した印であり、EOFや接続終了も受取人がファイルを承認・利用した証拠ではなかった。
  • 共有スプールに到着した後も、容量、保存期限、認証、受取判断、疑似ユーザーへのジョブ投入は受信側の別々の責任として残った。

受取人が呼ぶ前に荷物が来る

FTPの典型像では、利用者がサーバーへ接続し、アクセス主体を示し、ファイル操作を要求する。SIFT/UFTは最初の向きを逆にした。Unsolicitedとは、受信者が取引を開始していないという意味であり、不要なファイルだと断定する言葉ではない。

着想の背景にはNJEやBITNETがあった。そこではファイルを電子メールの本文や添付としてではなく、別の配送物として送れた。RFCは手紙に対する小包という比喩を置く。送信者は宛先ホストにアカウントを持たず、受取人は後で回収できる。

操作が一つ減ると、責任の置き場所が変わる。送信者は軽くなるが、受信ホストは常時待受、宛先名、容量判断、一時保管、期限切れ処分を引き受ける。状態は消去されたのではなく、相手側へ移された。

同じソケットに制御と本体を載せる

デーモンはTCP 608番ポートで待ち受けた。一つの接続にASCIIのコマンド列とバイナリデータが流れる。RFCは、これを制御ファイルとデータファイルという二つのものの連結として説明した。

FILEは送信者、予定サイズ、任意の認証チケットを示す。USERはローカル利用者またはサービス、TYPEは表現形式を指定する。この三つがDATAより前に必要だった。NAMEやDATEは補助情報で、EOFはファイルを閉じ、ABORTは途中のデータを捨て、QUITは作業を終える。

受信側は制御列と本体を別々に保存できた。待受プロセスが未知の形式をすぐ解釈しないための設計である。ただし、分離した二つを再び結び付ける記録が必要になる。どの指示がどの本体を表し、何バイト受け、誰がどう処分したかが失われてはならない。

ゼロの応答は一問だけを閉じる

肯定応答は先頭がゼロのオクテットで始まるNULL ACKだった。一つのACKは一つのコマンドだけを認める。それまでの全工程や最終受領を保証しない。

FILEのサイズは「置く場所があるか」を判断する材料だが、概算でもよかった。FILEを受理した後にUSERが存在しないと判明することも、データ書込みで容量が尽きることもある。先行する肯定応答を一つの約束にまとめれば、失敗した層が見えなくなる。

接続時のheraldはホスト名、UFTレベル、サーバー実装版を伝えた。同期とプロトコル合意には役立つが、ホストの認証ではない。FILEのauthは未実装で、仕様は認証が保証されないと明記した。

スプールに入ってから時間が分岐する

到着したファイルは、例として/usr/spool/uftという共有領域に置かれる。受取人が承認または拒否するまで、あるいはシステムが古さを理由に削除するまで待つ。「public」は共有を意味し、無制限アクセスを意味しない。大きさと保存期間はローカル管理の判断だった。

ここには通信終了時刻、ホスト保管期間、受取判断時刻がある。三つは一致しない。転送成功後に長く保管され、結局だれも受け取らず期限切れになることも仕様上の別結果である。

期限切れ削除を利用者の拒否と呼ぶことはできない。後からファイルが見つからないことも、利用済みの証明にならない。明示的な処分記録がなければ、拒否、隔離、清掃、障害を区別できない。

本文は受取人が動くまで極力加工しない方針だった。未知の表現はバイナリとして保持する。これは将来の選択肢を守る節度であり、完全性、安全性、有用性の保証ではない。

バーストの長さが停止地点を作る

通常のDATAには次のバーストのオクテット数が付く。受信者は指定量を読み、保存し、再びコマンド解釈へ戻る。複数バーストで一つのファイルを作り、同じ接続で次のファイルも送れる。区切りごとにACKやABORTの機会が戻る。

一方、「大胆な」高速モードでは長さを省く。クライアントが接続を閉じるまで読み続け、EOFもQUITも送らない。流れている間はABORTも使えない。接続寿命そのものがフレーム境界になる。

往復を減らす代わりに、意図した終端と偶発切断が同じ信号になる。完全性を判断するには申告量、受信量、ハッシュ、終了原因など別の証拠が必要だ。ソケットが閉じたという事実だけでは足りない。

宛先が人間とは限らない

USERはソフトウェアサービスや、疑似ユーザーとして見えるジョブ投入キューも指せた。保管されたファイルが自動処理への入力になり得る。

しかし、名前解決は実行許可ではない。送信者の身元、投入権限、形式検証、資源制限、隔離、起動、出力の確認は別の判断である。受信デーモンが宛先文字列を受理しても、その仕事を安全に走らせる権限までは生まれない。

RFCはセキュリティ問題を議論せず、認証の実装を将来へ委ねた。宛先アカウントを不要にした便利さは、それ自体では信頼の代替にならなかった。

メール経由では観測点が変わる

直接IPで届かないホスト、追加デーモンを望まない運用者、メールだけを通すファイアウォールがある。そこでUFTをMIMEに包む経路も示された。コマンドはapplication/octet-streamのパラメータとなり、本体はBase64でメール内を運ばれる。

MIMEは表現と輸送の互換性を与えるが、受取人の承認を代行しない。直接TCPで観測できたherald、コマンドACK、バーストの代わりに、メールの保存転送状態が証拠となる。認証も、もしあればメールシステムの責任だった。

RFC 1440はExperimentalであり、RFC 1499もその位置付けを維持した。IANAの現行表にはsift-uftと608番が残る。登録欄は文書史を示すが、実装や普及の実測値ではない。

到着後の主語を記録する

この実験が残したのは、発信、コマンド受理、バイト受信、ホスト保管、受取人判断、アプリケーション処理という別々の動詞である。それぞれの主語と時刻を保存しなければ、「配送済み」という一語が証拠を過大評価する。

必要なのは通信相手とherald、各コマンドとACK、申告・実測サイズ、表現形式、本体ハッシュ、スプール確定、保存期限、宛先検索、処分、後続結果を結ぶ記録だ。ホストは代理で保管できるが、受取人の意思まで代理できない。

出典