要約

  • RFC 2449 は CAPA を加え、POP3 の拡張機能やサーバー動作を、コマンドを試すだけ、あるいは文章のエラーを読むだけでなく、構造化された形で発見できるようにした。
  • その一覧はセッション状態に結びつく情報であり、権限や成功の受領証ではない。認証、利用者別ポリシー、完全性保護によって内容が変わり得る。

「このサーバーには何ができるのか」。一見ひとつの質問だが、POP3 では答えが接続状態に左右された。任意コマンド、認証方式、サーバー動作には実装差があり、クライアントはコマンドを試し、利用者向けの文章エラーを解釈し、互換設定を手動で選ばせることが多かった。1998 年 11 月に Standards Track として公開された RFC 2449 は、RFC 1939 を更新し、拡張を選ぶ前に機械可読な一覧を得る CAPA を導入した。

しかし、一覧は永続的なサーバープロファイルにはならなかった。CAPA はログイン前の AUTHORIZATION 状態と、認証後の TRANSACTION 状態の両方で使える。各機能の定義には、どの状態で告知され、関連コマンドがどの状態で有効かを記さなければならない。認証前に利用可能な機能は両方の状態で告知される一方、利用者が分かった後で引数がより具体化する場合もある。タグ、値、そして実行可能な操作は結びついていても、同じ事実ではない。

LOGIN-DELAY と EXPIRE が保守的な値の意味を示す。アカウントによって LOGIN-DELAY が異なるなら、認証前には想定し得る最大の待ち時間を告知し、認証後にはその利用者に合った正確な値を示すべきである。EXPIRE は保証される最短保存期間であって、特定のメッセージが消える日を予測するものではない。利用者ごとに異なる場合、認証前の値は可能な最短期間でなければならず、ログイン後により正確な値を示すべきだ。サーバーが適用ポリシーをまだ知らないため、最初の答えは慎重になる。

認証はセキュリティの文脈も変える。完全性保護層を交渉した場合、RFC 2449 は能動的ダウンネゴシエーションを検出するため、クライアントが CAPA を再発行するよう勧めた。後の RFC 5034 は SASL セキュリティ層について境界を明確にし、古い機能一覧を含め、以前に学習したサーバー情報を破棄するよう定めた。保護外で得た情報が、新しい文脈でも自動的に証拠になるわけではない。

肯定的な一覧があっても、全利用者が全操作を行える保証はない。USER は USER と PASS の対応を示すが、RFC 2449 はすべての利用者に利用可能とは限らないと明記する。SASL 機構の表示は、資格情報やローカルポリシーが認証を受け入れる保証ではない。ログインに成功してもメールボックスを取得できない場合がある。CAPA が -ERR を返したなら、発見コマンド自体が未実装であり、クライアントは従来どおり試行に戻る。新しい発見経路は推測を減らすが、古いサーバーの不確実性を消さない。

RFC 2449 は機械可読な応答コードも導入し、自由文だけから失敗を推測する必要を減らした。未知の詳細は無視し、共通の土台を安定させる。いっぽう能力一覧は認証機構を露出させ得ると警告した。自動発見はより強い機構の選択を助けるが、読める情報には運用上の価値と開示コストが両方ある。

したがって、この RFC の貢献は POP3 サーバーの互換性を保証したことでも、試行が終わったことでもない。サーバーが何を、どの状態で、どの拡張規則に沿って主張できるかを定めたことだ。一覧は次の判断を導くが、実際に何が起きたかを示すのは、次のコマンドと応答、さらにメールボックスの観察である。RFC の標準化段階や IANA 登録は、実装や普及を証明しない。

出典

RFC 2449 本文、RFC 2449 記録、RFC 2449 Errata、RFC 1939、RFC 1957、RFC 5034、RFC 1734、RFC 4422、IANA POP3 拡張登録簿、RFC 2384、Heng Lu「Running-Code Primacy」、Heng Lu「最小の初期仕様と自発的採用」。