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 このメモの意義 このドキュメントは、インターネット社会のためのインターネット標準 track プロトコルについて書かれており、改良のための議論、提案を求める ものである。このプロトコルの標準化の現状については、 "インターネッ ト公式プロトコル標準" を参照のこと。このメモは、無制限に配布しても よい。 目次 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 付録 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 サーバに要求されるものではない。 3. 基本的な操作 はじめに、サーバホストは TCP ポートの 110 を listen することで、POP3 service を開始する。クライアントホストは、サービスを要求する時、サー バホストへの TCP 接続を確立する。その接続が確立した時、POP3 サーバが 返事を返す。その接続を閉じるか中止されるまで、クライアントと POP3 サー バはコマンドと応答を (それぞれ) やりとりする。 POP3 コマンドは大文字小文字の区別がないキーワードからなり、それに続く 1 つ以上の引数をとるかもしれない。すべてのコマンドは、CRLF の組によっ て終了する。キーワードと引数は printable な ASCII 文字で構成されてい る。キーワードと引数は、それぞれ 1 つの空白文字によって区切られる。 キーワードは 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 コマンドを出した時、 その セッションは 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 サーバ に、自身の身分証明をしなくてはいけない。これを行なうため の 2 つの手法が、このドキュメントに記述されている。それは、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 を表す文字列で応 答をする。 (鍵を得られたが、もし 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 状態に移る。 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 [メッセージ] 引数: メッセージ番号 (省略可能)。引数が与えられた時、消去マーク のついたメッセージは参照してはいけない。 (訳注: 消去マー クのついたメッセージ番号を指定するとエラーとなる。) 制限: 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 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 状態でのみ使用可能 議論: 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 サーバに消去マークを付けられたメッセージがあれば、 マークが外される。その後、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 状態に入るか、もしくはセッション を終了する。メッセージを取り除いている間に、資源が足りなくなっ たというようなエラーがある場合、消去マークのついたメッセージ のいくつかが削除されない、あるいは 1 つも削除されないという結 果になるかも知れない。いかなる時も、サーバは、消去のマークが つけられていないメッセージを取り除いてしまってはいけない。 削除が成功しようと失敗しようと、サーバは maildropへの排他的ア クセスロックを解放し、TCP のコネクションを閉じる。 考えられる応答: +OK -ERR some deleted messages not remove 例: C: QUIT S: +OK dewey POP3 server signing off (maildrop empty) ... C: QUIT 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 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を貯めておくこと は、サーバの実行にとってはより好ましいことであるが、一方でこ の仕様は 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が存在してもサーバがエラーを返すかもしれないが、 サーバは、平文の認証を許可しない。 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 コマンドが、ただ 1 つの引数をとるので、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) 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 の別のプロセスが POP3 サーバのそれぞれの実体として使用されている UNIX 上の実装では、 タイムスタンプの文法は、次のようなものである。 'prosess-ID' は、プロセスの PID の 10 進数の値、clock はシス テム時計の 10 進数の値、hostname は POP3 サーバが動いているホ ストに一致した完全ドメイン名とする。 POP 3 クライアントはこのタイムスタンプの記録を作り、APOP コマ ンドを発する。 'name' 引数は USER コマンドの引数 'name' と等 しい意味を持っている。 digest 引数は、MD5[RFC1321]アルゴリズ ムを、共有秘密をタイムスタンプに続けたものからなる文字列に適 用し、計算される。 この共有秘密は、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 の機能にあるよ うな "半永久的に貯蔵するメイルドロップ" の弱いバージョンを提供するこ とができることを発見した。 もちろん、既存の接続で、新着メッセージがないか調べたり、サーバにおけ る複数のフォルダを支援したりなどという他の IMAP の機能は POP3 には含 まれていない。 これらの機能がこのようにして一般ユーザに使われるとき、既読メッセージ は制限なくサーバに蓄積する傾向がある。サーバ管理者の立場からして、こ れは明かに望ましくないことである。 POP3 の限られた能力は数百や数千の メッセージを持つような、maildropを運用するのに十分でないので、この状 態は事実悪化する。 結果的に、大規模なマルチユーザを扱っているサーバの管理者、特にユーザ が POP3 経由でしか maildropにアクセス出来ないようなサーバは管理者に以 下のオプションを考慮することを推める。 * ユーザごとに maildropの (spool 領域の) 容量制限をする。 メッセージが溜ると、ユーザの maildropに新しいメッセージを受けとる余裕 がないという結果になってしまうことがこのオプションでの不利益である。 このオプションを選んでいるサイトはユーザの maildrop に適当なメッセー ジを挿入することで、差し迫った、または最近の割当の枯渇状態をユーザに 知らせることを確認するべきである。 * メイルの貯蓄に関してのサイトの方針をサーバにおいて執行する。 サイトがメッセージの既読、未読に関わらず、メッセージの貯蓄やそれの維 持に関してのローカルな方針をおくことは自由である。例えば、サイトは未 読メッセージは 60 日後に、既読メッセージは 7 日後に消すようににしても 良い。そのようなメッセージの消去の仕方は、POP3 のプロトコルの範疇では なく、プロトコルの侵害とはみなしていない。 メッセージの消しかたについての方針を実施しているサーバの管理者は、そ の方針をすべてのユーザに 知らせるべきである。 クライアントはサイトがメッセージ消去を自動的に行なうと仮定してはいけ ない、適当な時に DELE コマンドを使って明白にメッセージを消去し続ける べきである。 メッセージの消去に関する方針を強制しているサイトはユーザを困惑させる かも知れないということに注意すべきである。なぜなら POP3 クライアント はメイルを残すようにオプションの設定をサーバにするが、実はサーバによっ て支持されていない場合があるからである。 サイトの政策の 1 つの特別な場合は、メッセージは 1 回だけサーバからダ ウンロードされ、これが実行された後に消去される、というものである。こ れは以下のような POP3 サーバのソフトェアのメカニズムによって実現でき る: "あるクライアントによって (きちんと) 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" にだけ意味があることに注意しなさい。 この返事のあとのあるあらゆるテキストはクライアントに無視されてもさし つかえない。 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を 単一文字で表現している場合でも、メッ セージでこの文字が現われた時は、2 オクテットとしてカウントする。 また、POP3 クライアントは複数行の返答を受けとった時、(余分な) バイト で埋められた終端文字をすべて削除するので、サーバホストはメッセージ内 で最終オクテット (".") で始まる行を 2 度カウントする必要はなく、逆に 2 度カウントしてはいけないことに注意する。 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 コ マンドに関する重要なコメントをしてくれた。 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 付録 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 入力する方法をはっきりと決めた。 - 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