Network Working Group J. Myers Request for Comments: 1939 Carnegie Mellon STD: 53 M. Rose Obsoletes: 1725 Dover Beach Consulting, Inc. Category: Standards Track May 1996 この翻訳に関するノート URL: http://doobie.iq.nanzan-u.ac.jp/rfc-jp/rfc1939-jp.txt 日本語訳: 南山大学経営学研究科における後藤の講義の宿題として, 大部分を 学生に翻訳してもらい, 修正したものです. コピーライトは原典に 準じます. 複数人の作業によるので文体の不一致等は御容赦下さい. 翻訳者: goto,mick,hiro,junji,takeshi,nortic,naho,ron,atsushi,yamaji @iq.nanzan-u.ac.jp 作成日: June 1996 (訳注: 本翻訳は参考のため提供されているもので, 英文のものが正式である. 本翻訳の正しさについて, 一切保証しない.) Post Office Protocol - Version 3 このメモの意義 このドキュメントは, インターネット社会のためのインターネット標準tra- ckプロトコルについて書かれており, 改良のための議論, 提案を求めるもの である. このプロトコルの標準化の現状については, ``インターネット公式 プロトコル標準''を参照のこと. このメモは, 無制限に配布してもよい. 目次 1. 導入 ......................................................... 2 2. 余談 ......................................................... 2 3. 基本的な操作 ................................................. 3 4. AUTHORIZATION 状態 ........................................... 4 QUIT コマンド ................................................ 5 5. TRANSACTION 状態 ............................................. 5 STAT コマンド ................................................ 6 LIST コマンド ................................................ 6 RTER コマンド ................................................ 8 DELE コマンド ................................................ 8 NOOP コマンド ................................................ 9 RSET コマンド ................................................ 9 6. UPDATE 状態 ................................................. 10 QUIT コマンド ............................................... 10 7. POP3 のオプションコマンド ................................... 11 TOP コマンド ................................................ 11 UIDL コマンド ............................................... 12 USER コマンド ............................................... 13 PASS コマンド ............................................... 14 APOP コマンド ............................................... 15 8. 9. POP3 コマンドの概要 ......................................... 18 10. POP3 セッションの例 ........................................ 19 11. メッセージの形式 ........................................... 19 12. 参照 ....................................................... 20 13. セキュリティについての考察 ................................. 20 14. 謝辞 ....................................................... 20 15. 著者のアドレス ............................................. 21 付録 A. RFC 1725 との相違点 .................................... 22 Myers & Rose Standards Track [Page 1] RFC 1939 POP3 May 1996 付録 B. コマンドインデックス ................................... 23 1. 導入 インターネット上のある種の小さなノードにおいて, メッセージ転送システ ム(MTS)を維持することはしばしば実用的ではない. 例えば,ワークステーシ ョンはSMTPサーバ[RFC821]を動かしたり, ローカルなメイル配送システムを 継続的に運営するための十分な資源(サイクルやディスク資源)を持たないか も知れない. 同様に, パーソナルコンピュータをIPスタイルのネットワーク に長時間接続しておくには, 多くの費用がかかる(または不可能である)かも 知れない. (そのノードは``接続性''として知られている資源が足りない.) しかしながら, これらの小さなノードの上でメイルシステムを運営すること はとても便利である. これらはしばしば,メイル操作の仕事を助けるために, ユーザエージェント(UA)をサポートしている. この問題を解決するために, MTS の実体をサポートしているノードは, これらの非力なノードに対してメ イルスプールサービスを提供している. Post Office Protocol-Version 3 (POP3) は,ワークステーションに対して, サーバホストのメイルスプールへ の, 動的なアクセスを許している. 通常, このことは, POP3プロトコルがメ イルを読み書きするワークステーションに対して, サーバが保持しているメ イルを取り寄せることを許していることを意味する. POP3はメイルサーバ上でメイルの拡張的な操作を提供しようとしているので はない. 普通は,メイルはダウンロードされ, そして消去される.より進んだ, そして複雑なプロトコルであるIMAP4 は[RFC1730]で議論されている. 以下では, クライアントホストというのは, POP3を利用するホストのことを 意味する. 一方, サーバホストというのは, POP3サービスを提供するホスト のことを意味する. 2. 余談 このメモの考え方と一致した手法をここに紹介するが,このメモは,どのよう にクライアントホストが配送システムにメイルを入れるのかを記述したもの ではない. クライアントホスト上でのユーザエージェントが配送システムにメ イルを入れようとしたときに, その中継ホストとの間にSMTPコネク ションが確立され, すべてのメイルを送る. この中継ホストはクラ イアントホストのPOP3サーバであってもよい.(しかし, POP3サーバ である必要はない). もちろん,中継ホストはメイルを受けとり, 任 意の受けとりアドレスに配達できなければならない. そして, この 機能はすべてのSMTP サーバに要求されるものではない. Myers & Rose Standards Track [Page 2] RFC 1939 POP3 May 1996 3. 基本的な操作 はじめに, サーバホストは TCP ポートの 110 を listen することで, POP3 service を開始する. クライアントホストは, サービスを要求する時, サー バホストへの TCP 接続を確立する. その接続が確立した時, POP3 サーバが 返事を返す. その接続を閉じるか中止されるまで, クライアントと POP3 サ ーバはコマンドと応答を(それぞれ)やりとりする. POP3コマンドは大文字小文字の区別がないキーワードからなり, それに続く 1つ以上の引数をとるかもしれない. すべてのコマンドは, CRLF の組によっ て終了する. キーワードと引数は printable な ASCII 文字で構成されてい る. キーワードと引数は, それぞれ１つの空白文字によって区切られる. キ ーワードは 3 か 4 文字である. 各引数は, 40 文字までである. POP3 での応答は, 状態を示す文字列とキーワード(時として, 付加情報が加 えられている)で構成されている. すべての応答は, CRLF の組によって終了 している. 応答は, 終了を示す CRLF を含めて 512 文字までである. 現在, 応答には positive(肯定) と negative (否定)の2 つの状態を示すものがあ る. サーバは大文字で, "+OK"(positive) または "-ERR"(negative) のどち らかを送らなければならない. あるコマンドに対する応答は, 複数行にわたる時もある. これらの以下には っきり示すような場合において, 応答の 1 行目と CRLF を送った後, いく つかの追加の行が送られる. それぞれの行は CRLF の組で終了している. 応 答のすべての行が送られる時, 最終 octet(termination octet) を表す終端 文字(十進数のコードで 046 である ".")と CRLF の組で構成されている最終 行が送られる.複数行の応答の中で, その行が "." ではじまっているならば, "byte-stuffed"(バイトで埋めること)により, "." を前もって後回しにする 操作を行なう. 従って, 複数行の応答は "CRLF.CRLF"の 5 オクテットで終了 する. 複数行の応答を調べる時, クライアントはその行が "."ではじまって いるかをチェックする. もしそうであり, CRLF があとに続かなければ,その 行の最初の"."を取り除く.もしそうであり CRLF が"." に続いているならば, POP3 サーバからの応答は終わり, ".CRLF" を含んでいる行は複数行の応答 の一部分とみなされない. POP3 セッション は, その活動中に多くの状態に移りながら進んでいく. 一 度 TCP 接続が確立し, POP3 サーバが挨拶をすれば, そのセッションは AU- THORIZATION 状態になる. この状態では, クライアントは POP3 サーバに対 して, 身分証明をする必要がある. クライアントがこれに成功すると, サー バはクライアントの maildrop に関係する資源を得る. そして, そのセッシ ョンはTRANSACTION状態になる. この状態においては,クライアントは POP3 サーバ側での動作を要求する. クライアントが QUIT コマンドを出した時, Myers & Rose Standards Track [Page 3] RFC 1939 POP3 May 1996 その セッションは UPDATE 状態になる.この状態においては, POP3 サーバ は TRANSACTION 状態の間に得たいくつかの資源を解放し, 別れの言葉をい う. それから TCP 接続が閉じられる. サーバは認識できないか, 実行できないか,または構文的に無効なコマンド に対しては, negative を表す文字列を使って応答をしなくてはいけ ない. サーバは,セッションが間違っている状態にある時に出されたコマン ドに対して, negative を表す文字列を使って応答をしなければなら ない. クライアントが, オプショナルコマンドを実装していないサーバと コマンドを処理しようとしない, または処理できないサーバを区別する一 般的な手法はない. POP3 サーバ は, inactivity なオートログアウトタイマーを持っているか もしれない.そのようなタイマーの継続時間は, 少なくとも 10 分でなけれ ばならない.サーバは, その 10 分の間にクライアントからのコマンドを受 け付ければタイマーをリセットする. そのタイマーが制限時間に達した時, そのセッションは UPDATE 状態に入れない.サーバはクライアントに対して いくつかのメッセージを消したり, 何の応答を送ることもなく TCP 接続を 閉じるベきである. 4. The AUTHORIZATION 状態 一度 POP3 クライアントが TCP 接続を確立したならば, POP3サーバ は一行 の挨拶を出す. これは positive な応答とみなすことができる. 例えば次の ような応答である. S: +OK POP3 server ready この時, POP3 セッション は AUTHORIZATION 状態である. クライアントは, POP3 サーバ に, 自身の身分証明をしなくてはいけない.これを行なうため の２つの手法が,このドキュメントに記述されている.それは,USERとPASSコ マンドの組合せとAPOPコマンドである.この手法については共にこのドキュ メントのあとに書かれている.追加の認証機構は, [RFC1734] に書かれてい る. すべての POP3 サーバにおいて,要求される唯一の認証を得る方法があ るわけてはないが,POP3サーバは少なくとも一つの認証を得る手法をサポー トしなければならない. 一度 POP3 サーバが, 認証コマンドを通してクライアントが適切な maildrop へのアクセスを与えられるべきであることを決定すれば, それからPOP3 サー バ は, そのセッションが UPDATE 状態になる前にメッセージが変更されたり, 削除されることを妨ぐことができるように, maildrop に対して排他的なアク セスの lock を得る. もし lock がうまく得られたなら, POP3 サーバは po- sitive を表すものを用いて, 応答をする. この時, POP3 セッション は TR- ANSACTION 状態になり, そこでは削除マークのついたメッセージはない.もし maildrop が何らかの理由(例えば, lock が得られなかったり, クライアント が適切な maildrop へのアクセスを拒んだり,maildrop が解析できない)によ り開かれないのなら, POP3 サーバ は negative を表す文字列で応答をする. Myers & Rose Standards Track [Page 4] RFC 1939 POP3 May 1996 (鍵を得られたが, もし POP3 サーバが negative な状態を表す文字列を使っ て応答するつもりであれば, その POP3 サーバはコマンドを拒絶するために, 前の lock を解放する必要がある.) negative を示す文字列を戻した後, そ のサーバは接続を閉じるかも知れない.もしサーバ が接続を閉じなかったら, クライアントは新しい認証コマンドを発行し再びスタートしてもよいし, ク ライアントが QUIT コマンドを発行してもよい. POP3サーバが maildrop を 開いた後, サーバは各メッセージに対してメッセージ番号を割り当て, oct- et 単位で各メッセージのサイズを表示する.maildrop での最初のメッセージ には, メッセージ番号 "1",二番目のメッセージには "2" など n 番目のメッ セージには "n" を割り当てる. POP3 のコマンドと応答において, すべての メッセージ番号とメッセージのサイズは, 十進法で表現される. ここに AUTHORIZATION 状態で使われる QUIT コマンドに対する概要を示す. QUIT Arguments : none Restrictions: none 考えられる応答: +OK Examples: C: QUIT S: +OK dewey POP3 server signing off 5. TRANSACTION 状態 クライアントがPOP3サーバへの身分証明に成功し, POP3サーバが適切な maildrop をロックして, オープンした時, POP3セッションはTRANSACTION 状態に移る. クライアントは何回か次にあげるような POP3 コマンドを出 してもよい. POP3サーバはそれぞれのコマンドに返事をする. 最終的にク ライアントが QUIT コマンドを出して POP3 セッションは UPDATE 状態に 移る. Myers & Rose Standards Track [Page 5] RFC 1939 POP3 May 1996 TRANSACTION 状態で有効なコマンドを以下にあげる. STAT 引数: なし 制限: TRANSACTION 状態でのみ使用可能 議論: POP3 サーバは, maildrop に関する情報を含んだ 1 行の pos- itive な応答をする. この行は, "drop listing"と呼ばれてい る. (コマンドの)解析を簡単にするために,すべての POP3 サーバは, drop listing 用に,あるフォーマットを要求する. positive な 応答は, "+OK" の他に, 空白, maildrop 内のメッセージ数, 空 白,オクテット単位での maildrop のサイズから構成されている. このメモでは, maildrop のサイズの後ろ続くものは何も必要と しない. 最低限の実装でも, 応答行が終了を表す CRLFの組で終 るようにすべきである. さらに, 高度な実装では,他の情報も含 めたてもよい. 注意: このメモでは, 実装において, drop listing に おいて付加情報を供給しないようすすめている. maildrop においてクライアントにメッセージを解析することを許す他 のオプションの機能が, 後に述べられている. 消去マークがついているメッセージは,どの総計にも入ら ないので注意すること. 考えられる応答: +OK nn mm 例: C: STAT S: +OK 2 320 LIST [メッセージ] 引数: メッセージ番号(省略可能).引数が与えられた時,消去 マークのついたメッセージは参照してはいけない. (訳注: 消去マークのついたメッセージ番号を指定すると エラーとなる.) Myers & Rose Standards Track [Page 6] RFC 1939 POP3 May 1996 制限: TRANSACTION 状態でのみ使用可能 議論: 引数が与えられた時, POP3 サーバは,そのメッセージに関する 情報を含んでいる行を持つ positive な応答を返す. この行は, ``scan listing'' と呼ばれている. もし引数がなく, POP3 サーバが positiveな応答をしたならば, その応答は複数行にわたる. 最初の "+OK" の後,maildrop内の それぞれのメッセージに対して, POP3サーバは, メッセージに 関する情報を含む応答をする. この行は, ``scan list-ing'' と呼ばれている.もし maildrop に 1 つもメッセージがなけれ ば, POP3 サーバは scan listing のない応答をする -- POP3 サーバは,後ろに終了オクテットとCRLFの組を含む行が続く応答 をする. (構文の)解析を簡単にするために, すべての POP3 サーバには, scan listing用に, あるフォーマットが必要である. scan list -ing は, メッセージ番号から構成されており,メッセージ番号 の後には一つの空白, メッセージのオクテット数が続く. メッ セージのサイズを計算する方法は, メッセージの形式のところ で述べる. このメモでは, scan listing において,メッセージ の後に続くものは何も必要としていない.最低限の実装でも,応 答の行が CRLF の組で終るようにするべきである. さらに高度 な実装においては, メッセージから解析される, 他の情報を含 むようにした方がよい. 注意: このメモでは, 実装において,scan listing に関す る付加情報を供給しないように推奨している. この他に, (オプションで)クライアントがより簡単に mail drop 内の メッセージを解析することを許すような機能が後で議論され ている. 消去されたというマークがついているメッセージは, リストさ れないので注意すること. 考えられる応答: +OK scan listing follows +ERR no such message 例: C: LIST S: +OK 2 messages (320 octets) S: 1 120 Myers & Rose Standards Track [Page 7] RFC 1939 POP3 May 1996 S: 2 200 S: . ... C: LIST 2 S: +OK 2 200 ... C: LIST 3 S: -ERR no such message, only 2 message in maildrop RETR メッセージ 引数: 消去マークがつけられていないメッセージ番号(省略可能) 制限: TRANSACTION 状態でのみ使用可能 議論: POP3 サーバが OK という応答をしたら,応答は複数行にわたる. 最初の "+OK" の後,POP3 サーバは, (すべての複数行にわたる 応答の時と同様に)終端文字をbyte-stuff することに注意しな がら. 与えられたメッセージ番号に対応するメッセージを送信 する. 考えられる応答: +OK message follows -ERR no such message 例: C: RETR 1 S: +OK 120 octets S: S: . DELE メッセージ 引数: 消去マークのつけられていないメッセージ番号 制限: TRANSACTION 状態でのみ使用可能 Myers & Rose Standards Track [Page 8] RFC 1939 POP3 May 1996 議論: POP3 サーバは, メッセージに消去マークをつける. POP3サーバ は,今後そのメッセージに対応づけられたメッセージ番号へのい かなる参照にも, エラーコードを返す. 実際には, POP3 サーバ は, UPDATE 状態に移るまでそのメッセージを消去しない. 考えられる応答; +OK message deleted -ERR no such message 例: C: DELE 1 S: +OK message 1 deleted ... C: DELE 2 S: -ERR message 2 already deleted NOOP 引数: なし 制限: TRANSACTION 状態でのみ使用可能 議論: POP3 サーバは何もしない. OK という返事を出すだけである. 考えられる応答: +OK 例: C: NOOP S: +OK RSET 引数: なし 制限: TRANSACTION 状態でのみ使用可能 議論: POP3 サーバに消去マークを付けられたメッセージがあれば, マ ークが外される. Myers & Rose Standards Track [Page 9] RFC 1939 POP3 May 1996 その後, POP3 サーバは OK という返事を返す. 考えられる応答: +OK 例: C: RSET S: +OK maidrop has 2 messages (320 octets) 6. The UPDATE State クライアントが TRANSACTION 状態から QUIT コマンドを発したとき, POP3の セッションは UPDATE 状態に入る.(もしクライアントが AUTHORIZATION 状態 からQUITコマンドを発したなら, POP3 のセッションは UPDATE 状態にはなら ずに, 終了されることに留意して欲しい.) もしクライアントが発した QUIT コマンド以外の何らかの理由により,セッシ ョンが終了したなら, POP3 のセッションは UPDATE 状態には移らず, どんな メッセージも maildrop から取り除いてはいけない. QUIT 引数: なし 制限: なし 議論: POP3 サーバは削除のマークが付けられたすべてのメッセージを maildropから取り除き, UPDATE状態に入るか, もしくはセッシ ョンを終了する. メッセージを取り除いている間に, 資源が足り なくなったというようなエラーがある場合, 消去マークのついた メッセージのいくつかが削除されない, あるいは１つも削除され ないという結果になるかも知れない. いかなる時も, サーバは, 消去のマークがつけられていないメッセージを取り除いてしまっ てはいけない. 削除が成功しようと失敗しようと, サーバは maildropへの排他 的アクセスロックを解放し, TCP のコネクションを閉じる. 考えられる応答: +OK -ERR some deleted messages not remove 例: C: QUIT S: +OK dewey POP3 server signing off (maildrop empty) ... C: QUIT Myers & Rose Standards Track [Page 10] RFC 1939 POP3 May 1996 S: +OK dewey POP3 server signing off (2 messages left) ... 7. POP3 のオプションコマンド 上で述べたPOP3のコマンドはPOP3サーバの必要最小限の実装によってサポート されなければならない. 簡単なPOP3のサーバの実装を残しつつ, 次に示されるオプションのPOP3の コマンドによって, POP3のクライアントがより自由にメッセージを扱える ようになる. NOTE: このメモは特に, 強化されたdropとscanリストの機能を開発する 代わりにこれらのコマンドを支えるための実装を強くすすめるものである. つまり, このメモの考え方はPOP3のサーバではなくクライアントの部分に 知恵を与えることである. TOP msg n 引数: 消去のマークのついていないメッセージの番号, 非負のメッセージの行数 制限: TRANSACTION状態のときだけ使用可能 議論: POP3サーバがpositiveな応答をすると, 複数の行が返ってくる. 最初の+OKの後, POP3サーバはメッセージのヘッダと, 本体部分と ヘッダを区切る空行と, 引数で示された行数のメッセージ本文とを, 埋めたバイトである終端記号に注意して, 送る(すべてのmulti-line が対応するように). もしPOP3クライアントによって請求された行数が本体の行数よりも 大きければ, POP3サーバはそのメッセージ全部を送ることに注意. 可能な応答: +OK top of message follows -ERR no such message 例: C: TOP 1 10 S: +OK Myers & Rose Standards Track [Page 11] RFC 1939 POP3 May 1996 S: < POP3 サーバはメッセージのヘッダ, 空行, メッセージ本体の 最初の10行を送る > S: . ... C: TOP 100 3 S: -ERR no such message UIDL [msg] 引数: 引数があるときは, 消去とマークされたものは参照できない. 消去のマークがついていないメッセージの番号(オプション) 制限: TRANSACTION状態のときだけ使用可能 議論: 引数が与えられると, POP3サーバはメッセージの情報を含む行とともに positiveな応答をする. この行をそのメッセージに対する"unique-id listing"という. 引数がなく, POP3がpositiveな応答をすれば, その応答は複数行で与え られる. 最初の+OKの後, maildropの中のそれぞれのメッセージに対し て, POP3サーバはメッセージの情報を含む1行の返事を送る. この行を そのメッセージの"unique-id listing"と呼ぶ. 簡単に解析するために, すべてのPOP3サーバはunique-id listingの あるフォーマットを使用する必要がある. unique-id listing は順にメッセージのメッセージ番号, 空白1個とメッセージの unique-idからなる. unique-id listingの中のunique-idの後に 情報は続かない. メッセージのunique-idはサーバが決定する任意の文字列で, 0x21から 0x7Eまでの範囲の 1から70文字で構成される, これはmaildropの中で メッセージを一意に識別し, セッションを越えて存続するものである. この持続性はたとえUPDATE状態に入らずにセッションが終わっても, 必要である. サーバはそのunique-idを使用しているものがある限り, 決して与えられたmaildropの中でunique-idを再使用するべきではない. 消去のマークが付けられたメッセージは列挙されないことに注意. maildropの中に任意に割り当てられたunique-idを貯めておくこ とは, サーバの実行にとってはより好ましいことであるが, 一方で Myers & Rose Standards Track [Page 12] RFC 1939 POP3 May 1996 この仕様はunique-idがメッセージのハッシュとして計算されるように 意図されている. ( 訳注: 同じメッセージのハッシュは同じものになっ てしまう. ) クライアントは, 同じuiniqu-idを持つmaildropの中に2つ の同一なメッセージのコピーが存在する設定を, 扱うことができるはず である. 可能な応答: +OK unique-id listing follows -ERR no such message 例: C: UIDL S: +OK S: 1 whqtswO00WBw418f9t5JxYwZ S: 2 QhdPYR:00WBw1Ph7x7 S: . ... C: UIDL 2 S: +OK 2 QhdPYR:00WBw1Ph7x7 ... C: UIDL 3 S: -ERR no such message, only 2 messages in maildrop USER name 引数: mailboxを認識する文字列, これはサーバに対してのみ意味を持つ 制限: POP3の挨拶の後, またはUSERかPASSコマンドを失敗した後の AUTHORIZATION 状態のみで使われる 議論: 使用するUSER, PASSコマンドの組合せを使って認証するためには, クライアントは最初にUSERコマンドを出さなければならない. もしPOP3のサーバがpositiveな状態("+OK")で応答してきたら, クライアントは認証を完了するためにPASSコマンドか, または POP3のセッションを終了するためにQUITコマンドを出してよい. もしPOP3サーバがUSERコマンドに対してエラーの反応("-ERR")を 示したら, クライアントは新しく認証を出しても, QUITコマンド を出してもよい. サーバはmailboxが存在しなくても, positiveな応答をするかも しれない. もしmailboxが存在してもサーバがエラーを返すかもしれないが, サーバは, 平文の認証を許可しない. Myers & Rose Standards Track [Page 13] RFC 1939 POP3 May 1996 Possible Responses: +OK name is a valid mailbox -ERR never heard of mailbox name Examples: C: USER frated S: -ERR sorry, no mailbox for frated here ... C: USER mrose S: +OK mrose is a real hoopy frood PASS string 引数: サーバー/メールボックス固有のパスワード(必要) 制限: AUTHRIZATION 状態のにおいて,USER コマンドが成功したすぐ後だけ 使用できる. 議論: クライアントがPASSコマンドを発した時,POP3 サーバーは,USER コマンド とPASS コマンドからの引数の組を, クライアントが適したメールドロップ にアクセスできるかどうか決定するために使用する. PASS コマンドが,ただ１つの引数をとるので,POP3 サーバは,引数中に現れ るスペース文字を,引数を区切る文字としてでなく, パスワードの一部とし て扱う. 可能な応答: +OK メールドロップがロックされ準備ができた. -ERR パスワードが不正であった. -ERR メールドロップをロックでなかった. 例: C: USER mrose S: +OK mrose is a real hoopy frood C: PASS secret S: -ERR maildrop aleady locked ... C: USER mrose S: +OK mrose is a real hoopy frood C: PASS secret S: +OK mrose's maildrop has 2 messages (320 octets) Myers & Rose Standards Track [Page 14] RFC 1939 POP3 May 1996 APOP name digest 引数: メイルボックスにおいてのID文字列とMD5のダイジェスト文字列(両方必要) 制限: AUTHORIZATION 状態において,POP3に挨拶した後か, USERコマンドかPASSコマンドが失敗した後の時だけ,使用できる. 議論: 通常,POP3のそれぞれのセッションはUSER/PASS を交わすことで始まる. これは,ネットワーク上で,サーバ/ユーザーID 特定パスワードが, 平文としてに送られるという結果をもたらす. 断続的なPOP3の使用では, これは,それほど大きな危険を導くことはない. しかしながら,たくさん のPOP3クライアントの実装は,定期的に POP3 セーバに接続する -- 新しいメールが来たか確かめるために. さらに,セッションの始まりの間隔は5分程度である. 従って,パスワード が手に入れられる危険性は,非常に高まっている. もう一つの認証の方法には,クライアントの認証と, 使用の繰り返しに おいての保護の両方をしてくるもので, ネットワーク上で,平文として, パスワードを送る事態を引き起こさないような認証方法が必要とされる. APOP コマンドはこの機能を与えてくれる. APOP コマンドを実装した POP3 サーバは,その最初の挨拶文に, タイムスタンプを含んでいる. タイムスタンプの文法は[RFC822] の 'msg-id' に対応し,POP サーバが,最初の挨拶で発行するたびに,異なら なければならない. 例えば, UNIXの別のプロセスがPOP３サーバのそれぞ れの実体として使用されている UNIX 上の実装では, タイムスタンプの 文法は, 次のようなものである. 'prosess-ID' は,プロセスのPIDの10進数の値, clock はシステム時計の 10進数の値, hostname は POP3 サーバが動いているホストに一致した 完全ドメイン名とする. POP 3 クライアントはこのタイムスタンプの記録を作り, APOPコマンドを 発する. 'name' 引数は USER コマンドの引数 'name' と等しい意味を持っ ている. digest 引数は, MD5[RFC1321]アルゴリズムを, 共有秘密をタイム スタンプに続けたものからなる文字列に適用し, 計算される. Myers & Rose Standards Track [Page 16] RFC 1939 POP3 May 1996 この共有秘密は,POP3 のクライアントとサバーだけが知っている文字列で ある. 秘密の知識があると,いかなる実体でも,名前を持ったた使用者とし て仮装できるので,不正な秘密の暴露を予防することに十分注意しなさい. 'digest' 引数そのものは, ASCII 文字の小文字を使って16進数の書式で 記述された16オクテットの値である. OP 3 サーバがAPOP コマンドを受けとった時,与えられたdigest 検証する. digest が正しければ, POP 3 サーバは, positive という 応答を発し, POP 3 セッションが TRANSACTION状態にはいる. もしくは, negativeという応答が発されて, POP 3 セッションは, AUTHORIZATION 状態のままである. 共有秘密の長さが増えるに従い,それを見破る 難しさも増えることに注意しなさい. よって,共有秘密は長い文字列(下の例のような8文字よりも, ずっと長い文字)でなければならない. 可能な応答: +OK メールドロップがロックされて準備された. -ERR 許可が降りない 例: S: +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us> C: APOP mrose c4c9334bac560ecc979e58001b3e2fb S: +OK maildrop has 1 message (369 octets) この例では, 共有秘密は,'tanstaaf' という文字列である. 従って, MD5 アルゴリズムに適用される文字列 <1896.697170952@dbc.mtview.ca.us>tanstaaf は, c4c9334bac560ecc979e58001b3e2fb という digest の値を生み出す. 8. 規模と運用上の考慮. 以上で説明したいくつかのオプション機能がPOP 3 プロトコルに加えられた ことで, ほとんどのユーザがお互いに関係ないような, 大規模な商業ポスト オフィス運用をするような環境での経験がつまれた. これらや他の状況にお いて, ユーザとPOP3 クライアントのメーカは, UIDL コマンドを使うことと DEL コマンドを出さないという組合せを使えば, 普通IMAP の機能にあるよう な"半永久的に貯蔵するメイルドロップ" の弱いバージョンを提供することが できることを発見した. Myers & Rose Standards Track [Page 16] RFC 1939 POP3 May 1996 もちろん, 既存の接続で, 新着メッセージがないか調べたり,サーバにおける 複数のフォルダを支援したりなどという他のIMAPの機能はPOP3 には含まれて いない. これらの機能がこのようにして一般ユーザに使われるとき, 既読メッセージは 制限なくサーバに蓄積する傾向がある. サーバ管理者の立場からして, これは 明かに望ましくないことである. POP3 の限られた能力は数百や数千のメッセー ジを持つような,maildropを運用するのに十分でないので, この状態は事実悪 化する. 結果的に, 大規模なマルチユーザを扱っているサーバの管理者, 特にユーザが POP3経由でしかmaildropにアクセス出来ないようなサーバは管理者に以下のオ プションを考慮することを推める. * ユーザごとにmaildropの(spool 領域の)容量制限をする. メッセージが溜ると, ユーザのmaildropに新しいメッセージを受けとる余裕が ないという結果になってしまうことがこのオプションでの不利益である. この オプションを選んでいるサイトはユーザのmaildrop に適当なメッセージを挿入 することで, 差し迫った, または最近の割当の枯渇状態をユーザに知らせるこ とを確認するべきである. * メイルの貯蓄に関してのサイトの方針をサーバにおいて執行する. サイトがメッセージの既読,未読に関わらず,メッセージの貯蓄やそれの維 持に関してのローカルな方針をおくことは自由である. 例えば, サイトは 未読メッセージは60日後に, 既読メッセージは7日後に消すようににしても 良い.そのようなメッセージの消去の仕方は, POP3 のプロトコルの範疇で はなく, プロトコルの侵害とはみなしていない. メッセージの消しかたについての方針を実施しているサーバの管理者は, その方針をすべてのユーザに 知らせるべきである. クライアントはサイトがメッセージ消去を自動的に行なうと仮定しては いけない, 適当な時にDELE コマンドを使って明白にメッセージを消去し 続けるべきである. メッセージの消去に関する方針を強制しているサイトはユーザを困惑させる かも知れないということに注意すべきである. なぜならPOP3 クライアントは メイルを残すようにオプションの設定をサーバにするが, 実はサーバによって 支持されていない場合があるからである. サイトの政策の1つの特別な場合は, メッセージは1回だけサーバからダウン ロードされ, これが実行された後に消去される, というものである. これは 以下のようなPOP3 サーバのソフトェアのメカニズムによって実現できる: Myers & Rose Standards Track [Page 17] RFC 1939 POP3 May 1996 "あるクライアントによって(きちんと)QUITで終ったPOP3 loginのあと, RETRコマンドでセッションをしている間 DELE がなくても,downloadされた すべてのメッセージを消す." 異常な接続で終った場合(すなわちクライアント からQUIT を受けとらない場合)メッセージを消去しないことが重要である. なぜならクライアントは受けとるのに失敗したか, メッセージを貯めるのに 失敗したかもしれないからである. ダウンロードして消すという方針を実現するサーバでは, オプションのTOP コマンドを無効にするか制限したいと思うかもしれない. なぜなら(訳注: 本来, メッセージの最初の何行かだけを入手するための)TOP コマンドが メッセージ全体をダウンロードする代替メカニズムとして使われてしまう かもしれないからである. 9. POP3 コマンドのまとめ POP3 の 基本コマンド: USER name AUTHORIZATION 状態 で有効 PASS string QUIT STAT TRANSACTION 状態 で有効 LIST [msg] RETR msg DELE msg NOOP RSET QUIT POP3 の オプションコマンド: APOP name digest AUTHORIZATION 状態 で有効 TOP msg n TRANSACTION 状態 で有効 UIDL [msg] POP3 からの返答: +OK -ERR STAT, LIST, UIDL コマンド以外のあらゆるコマンドへのPOP3 サーバ からの返答は"+OK"と"-ERR"にだけ意味があることに注意しなさい. この返事のあとのあるあらゆるテキストはクライアントに無視されても さしつかえない. Myers & Rose Standards Track [Page 18] RFC 1939 POP3 May 1996 10. POP3セッションの例 S: C: <接続する> S: +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us> C: APOP mrose c4c9334bac560ecc979e58001b3e22fb S: +OK mrose's maildrop has 2 messages (320 octets) C: STAT S: +OK 2 320 C: LIST S: +OK 2 messages (320 octets) S: 1 120 S: 2 200 S: . C: RETR 1 S: +OK 120 octets S: S: . C: DELE 1 S: +OK message 1 deleted C: RETR 2 S: +OK 200 octets S: S: . C: DELE 2 S: +OK message 2 deleted C: QUIT S: +OK dewey POP3 server signing off (maildrop empty) C: <接続を終わる> S: <次の接続を待つ> 11. メッセージ形式 POP3 セッションの間に送られるメッセージはすべて, インターネット上のテ キストメッセージ形式の標準[RFC822]に従う. サーバホストにおけるメッセージのオクテットカウントと, クライアントに よる同じメッセージにたいするオクテットカウントが異なる可能性があること に注意する. これはend-of-lineに対する表現形式が異なるためである. 通常, POP3セッションのAUTHORIZATION 状態の間に, サーバホストがmaildrop を開くとき, 各メッセージのオクテット数をカウントできる. もしPOP3 サーバ が内的に end-of-lineを 単一文字で表現している場合でも, メッセージでこの 文字が現われた時は, ２オクテットとしてカウントする. また, POP3クライアントは複数行の返答を受けとった時, （余分な）バイトで 埋められた終端文字をすべて削除するので, サーバホストはメッセージ内で最 終オクテット(".")で始まる行を２度カウントする必要はなく, 逆に２度カウ ントしてはいけないことに注意する. Myers & Rose Standards Track [Page 19] RFC 1939 POP3 May 1996 12.参照 [RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, USC/Information Sciences Institute, August 1982. [RFC822] Crocker, D., "Standard for the Format of ARPA-Internet Text Messages", STD 11, RFC 822, University of Delaware, August 1982. [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, MIT Laboratory for Computer Science, April 1992. [RFC1730] Crispin, M., "Internet Message Access Protocol - Version 4", RFC 1730, University of Washington, December 1994. [RFC1734] Myers, J., "POP3 AUTHentication command", RFC 1734, Carnegie Mellon, December 1994. 13.セキュリティについての考察 APOP コマンドの使用が, POP3 セッションに対し, 起源の同定と繰り返し の保護を与える. 従って, PASS 及び APOP コマンドを実行する道具として, POP3 サーバは, あるユーザーのためにアクセスの両方の方法は許さない. すなわち, ある mailbox 名に対しては, 与えられた USER/PASS コマンドシーケンス, または APOP コマンドのどちらか一方のみが許される. 更に, 共有秘密の長さが増えるほど, それを得ることは, 困難となる. USER コマンドに -ERR と答えるサーバは, attackers にどの名前が正当で あるかの手掛りを与えることになる. PASS コマンドの使用は, ネットワークにおいて, 平文でパスワードを送る. RETR 及び TOP コマンドの使用は, ネットワークにおいて, 平文で メイル を送る. それ以外, セキュリティについては, このメモで論じられていない. 14.謝辞 POP ファミリーは, 長くそして変化に富んだ歴史を持っている. POP3 は, 主にRFC 1460 のマイナーな改訂だが, RFC918 ,937 及び,1081 バージョンで提示されたアイデアに基づいている. 更に Alfred Grimstad, Keith McCloghrie, 及び Neil Ostroffは, APOP コマンドに関する重要なコメントをしてくれた. Myers & Rose Standards Track [Page 20] RFC 1939 POP3 May 1996 15.著者のアドレス John G. Myers Carnegie-Mellon University 5000 Forbes Ave Pittsburgh, PA 15213 EMail:jgm+@cmu.edu Marshall T. Rose Dover Beach Consulting, Inc. 420 Whisman Court Mountain View, CA 94043-2186 EMail:mrose@dbc.mtview.ca.us Myers & Rose Standards Track [Page 21] RFC 1939 POP3 May 1996 付録 A. RFC1725との相違 このメモは, Draft StandardであるRFC 1725 の改訂である. そのドキュメントから次の変更をもたらす : - コマンドキーワードでは, 大文字小文字を区別しないことをはっきりと決めた. - サーバは, 「 +OK 」と「 -ERR 」を大文字として送らなければならない ことをはっきりと決めた. - 最初の挨拶は, positiveな応答(訳注:「 +OK 」のこと) であることをはっきりと 決めた. それは, positiveな応答となるべきああらゆる文字列の代わりである. - 実行されないコマンドのための振舞いをはっきりと決めた. - USER と PASS コマンドのオプションを作成した. - USER コマンドへの可能な応答の集合を, はっきりと決めた. - 混乱を減少させるために, 例での USER と PASS コマンドの順番を 逆にした. - PASS コマンドは, 成功した USER コマンドの直後だけに与えられること をはっきりと決めた. - UIDの要求が継続することをはっきりと決め, いくつかの実行における注意を 加えた. - 1つの UID の長さの制限を70オクテットに指定した. - CRLFを含み, 512オクテットの状況を示す文字列の長さの制限を指定した. - 空のメイルボックス上での引数を伴わないLISTはsuccessを返すことを はっきりと決めた. - LISTコマンドからMessage Format セクションへの参照を加えた. - 失敗した上でのQUITの振舞いをはっきりと決めた. - APOP コマンドとUSER コマンドの同時使用を前提にしないことを セキュリティセクションではっきりと決めた. - RFC1730及び1734への参照を加えた. - UA がトランスポートシステムに mail 入力する方法をはっきりと決めた. Myers & Rose Standards Track [Page 22] RFC 1939 POP3 May 1996 - TOPコマンドへの2番目の引数は, 行数であることをはっきりと決めた. - ユーザーへのPASSとAPOP, 双方を受け入れないための, セキュリティ考察 セクションでのサーバへの提案を, ”してはいけない”から”するべきではない” に変更した. - ”段階と操作性の考慮”セクションを加えた. 付録 B. Command インデックス APOP ....................................................... 15 DELE ....................................................... 8 LIST ....................................................... 6 NOOP ....................................................... 9 PASS ....................................................... 14 QUIT ....................................................... 5 QUIT ....................................................... 10 RETR ....................................................... 8 RSET ....................................................... 9 STAT ....................................................... 6 TOP ........................................................ 11 UIDL ....................................................... 12 USER ....................................................... 13 Myers & RoseStandards Track[Page 23]