要約

  • FTPはUSER、PASS、ACCTを別々のアクセス制御情報として扱った。パスワード段階の成功は、ログイン完了や後続のファイル操作の許可と同義ではない。
  • 332は追加情報を待つ肯定的な中間応答であり、後続操作に対して返る場合はサーバーが命令を保留したことも示す。532なら命令は破棄され、ACCTの後に再送が必要になる。
  • 仕様はaccountの意味を共通化しなかった。課金、プロジェクト、資源配分、権限のどれであるかはサイト側の問題であり、RFCやIANA登録から利用実態は分からない。

230へ進まなかった対話

FTPクライアントが利用者名を送り、サーバーがパスワードを求める。続くPASSが正しければ、普通は230 User logged inへ進むように見える。しかしRFC 959にはもう一つの正規経路がある。ログインに勘定情報が必要なら、成功したPASSへの応答は332 Need account for loginである。

ここで3から始まる数字は失敗を意味しない。先行する命令は受理されたが、要求された動作は追加情報が届くまで保留されている。正しい次手は同じパスワードの再試行ではなく、ACCTの送信だった。

現代の認証画面はしばしば利用者名とパスワードの二欄だけで世界を表す。その抽象化で332を処理すると、「ログインできなかった」という一語に潰れやすい。FTPの古い状態機械は、誰を名乗ったか、秘密が受理されたか、どのローカル文脈で資源を使うかを別々に残した。

TENEXの事情が第三の命令になった

1972年7月のRFC 354の直後、RFC 385はACCTを追加した。理由は抽象的な認証理論ではない。TENEXのように、userとpasswordに加えて別のaccount指定を必要とするシステムがあったからだ。

提案はACCTをPASSから明確に分けた。accountは必ずしもUSERに結び付かず、いつ届いてもよい。同じ利用者が異なるファイル転送に異なるaccountを用いる場合さえ想定された。

したがってaccountを金融口座や第二パスワードと訳し切るのは危険である。仕様が運んだのはTelnet文字列だけだった。プロジェクト、計算資源の帰属、割当て、局所的なアクセス区分など、意味を決める権限はサーバーのオペレーティングシステムに残された。

同じ意味を運ぶ数字は一度入れ替わった

1973年のRFC 542はACCTをアクセス制御命令として取り込み、ログイン時に必要な場合と、格納など特定操作だけに必要な場合を区別した。ただし当時の番号体系では、ログインにaccountを求める応答は331 Enter account、accountなしでは転送できず命令を再送すべき場合は433だった。

1974年のRFC 640が返信コードを再設計する。サーバーごとに異なる説明文を解析せず、三桁から機械が状態遷移を選べるようにするためだった。3yzは追加情報を待つ肯定的中間状態、5yzは同じ要求をそのまま繰り返すべきでない否定的完了に整理された。

この体系で331は利用者名受理・パスワード待ち、332はログイン用account待ち、532はファイル格納用account不足となった。古い記録の331を現在の「password待ち」と読むと、当時サーバーが何を尋ねていたかを取り違える。

追加情報だけで進むか、命令も送り直すか

RFC 765とRFC 959は、ログイン後にaccountが必要になる場合の違いを一段深く定義した。たとえばSTORを受けたサーバーが、その操作にはaccountが必要だと判断する。

サーバーがSTORを保持したままACCTを待つなら、応答は332でよい。クライアントはaccount情報を補えば、保留中の意図がまだサーバー側にある。対して532なら、その命令は捨てられた。ACCTの成功後にSTORをもう一度送らなければならない。

両方を「accountが必要」とだけ表示するクライアントは、意図の所在を失う。332後に再送すれば二重実行の設計問題を招き得るし、532後に再送しなければ何も始まらない。返信コードは単なる理由欄ではなく、次に送るべき命令を決める保管証だった。

532を容量不足と読んではならない

語尾が「storing files」であるため、532はディスク不足のようにも見える。しかしRFC 959は容量の状態を別に持つ。452はシステムの記憶容量不足、552は現在のディレクトリやデータセットの割当て超過である。

532はaccountという制御文脈が欠けている。452は物理・システム容量、552は割当ての上限に関わる。同じアップロード失敗でも、補うべきものは文字列、容量、配分変更と異なる。数字を一つの「storage error」へ正規化すると、運用は誤った修復を自動化する。

接続が続いてもアクセス文脈は続かない

RFC 959では、制御接続の途中でも新しいUSERを送れる。その瞬間、蓄積されたuser、password、account情報は消去され、ログイン列が最初から始まる。ただし転送パラメータは残り、進行中の転送は旧アクセス制御の下で完了する。

境界は接続全体に一様ではない。新しい利用者が、すでに流れているデータの責任を遡って引き受けるわけではない。一方、REINは接続を閉じずに利用者とaccountを消し、他のパラメータを既定値へ戻す。

監査が接続IDだけを鍵にすると、この時間差を見落とす。ある時点のACCT成功は、その後のUSER、REIN、再接続を越えて有効だとは証明しない。

実装必須と使用必須は別である

RFC 1123は、基盤となるファイルシステムやOSが許さない場合の例外を除き、サーバーとクライアント双方が支えるべき命令にACCTを含めた。これは三番目の状態を理解し表現できることを求める互換性規則だった。

すべてのサイトにaccount要求を課したわけではない。そのコンピューターで意味を持たない認識済み命令には、202で「ここでは不要」と肯定的に答えられる。命令の語彙を実装することと、毎回accountを要求することは異なる。

IANAのFTP Commands and Extensions登録簿もACCTをbaseのAccount、access-control型として残す。これは構文と参照仕様の証拠であり、現在の普及率や文字列の意味の証拠ではない。

正しかったのは、未完了を未完了のまま表すこと

FTPは各ホストのaccount制度を統一しなかった。代わりに、パスワード段階が通っても別の局所的決定が残ることを隠さなかった。さらに、その不足が後続操作で判明したとき、サーバーが命令を保持したか捨てたかまで機械に伝えた。

古い仕組みの価値はaccountそのものを復活させることではない。本人確認、資源文脈の選択、個別操作の受理を一つのbooleanへ縮めないという設計にある。状態を減らした画面は簡単だが、消えた状態は運用の暗黙ルールとして戻ってくる。

典拠と限界

史料はRFC 385、RFC 542、RFC 640、RFC 765、RFC 959、RFC 1123、IANA登録簿である。仕様は意味と遷移を示すが、特定実装、現在の利用、accountの機密性、課金の有無、ファイル操作の成功を証明しない。