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://homepage1.nifty.com/YoR/index.html 日本語訳: 南山大学経営学研究科における後藤の講義の宿題として、大部分を 学生に翻訳してもらい、修正したものです。コピーライトは原典に 準じます。複数人の作業によるので文体の不一致等は御容赦下さい。 その後に、キャラテックの岩澤が自らの野心と欲望のために校正し ました。 翻訳者: goto,mick,hiro,junji,takeshi,nortic,naho,ron,atsushi,yamaji @iq.nanzan-u.ac.jp 翻訳校正: "Iwasawa Hironori" yorzbszy@nifty.com 作成日: June 1996 校正日: Dec 2000 （訳注: 本翻訳は参考のため提供されているもので、英文のものが正式で す。本翻訳の正しさについては一切保証しません。） Post Office Protocol - Version 3 このメモの意義 このドキュメントは、インターネット社会のためのインターネット標準 通信プロトコルについて記述され、改良のための吟味や提案を求めるも のです。このプロトコルの標準化の現状については”インターネット公 式プロトコル標準”を参照してください。このメモは無制限に配布して かまいません。 Myers & Rose Standards Track [Page 1] RFC 1939 POP3 May 1996 目次 1. 導入 ........................................................ 2 2. ちょっと寄り道 .............................................. 3 3. 基本的な操作 ................................................ 3 4. 認証状態 .................................................... 5 QUIT コマンド ............................................... 6 5. 手続き状態 .................................................. 6 STAT コマンド ............................................... 6 LIST コマンド ............................................... 7 RETR コマンド ............................................... 8 DELE コマンド ............................................... 8 NOOP コマンド ............................................... 9 RSET コマンド ............................................... 9 6. 更新状態 .................................................... 10 QUIT コマンド ............................................... 10 7. POP3のオプションコマンド .................................... 11 TOP コマンド ................................................ 11 UIDL コマンド ............................................... 12 USER コマンド ............................................... 13 PASSコマンド ................................................ 14 APOPコマンド ................................................ 14 8. 基準化と操作性の考慮 ........................................ 17 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 スタイルのネットワークに長時間接続しておくには、費用がかかりすぎ る（または不可能）かも知れません。（そのノードは”接続性”という 資源が足りないのです。） Myers & Rose Standards Track [Page 2] RFC 1939 POP3 May 1996 しかしながら、これらの小さなノードの上でメールシステムが運営でき た方が便利なこともよくありますし、それらのノードにメール操作補助 ユーザエージェント（UA）が存在していることも多いのです。この問題 を解決するために、MTSそのものをサポートしているノードでは、これら の非力なノードへのメールスプールサービスを提供しています。Post Office Protocol- Version 3（POP3）はワークステーションに、サーバ のメールスプールへの動的なアクセスを許しています。これは通常は、 メールを読み書きするワークステーションが、サーバが保持しているメー ルを取り寄せるために、POP3プロトコルが使えることを意味します。 POP3はメールサーバ上でのメールの操作を拡張しようとしているのでは ありません。通常、メールはダウンロードされた後は消去されます。よ り先進的で複雑なプロトコルのIMAP4は[RFC1730]で吟味されています。 以下では、クライアントというのは、POP3を利用するホストのことを意 味します。一方、サーバというのは、POP3サービスを提供するホストの ことを意味します。 2. ちょっと寄り道 これはクライアントが配送システムにメールを発送する方法を記述した ものではありませんが、このメモの考え方とは一貫しています。 クライアント側でユーザエージェントが配送システムにメールを発 信しようとしますと、中継ホストとの間にSMTPコネクションが確立 されて、すべてのメールを送ります。この中継ホストはクライアン トのPOP3サーバでもかまいません（が、POP3サーバの必要はありま せん）。もちろん、中継ホストはメールを受けとって、任意の受け とりアドレスに配達できなければなりません。この機能はすべての SMTPサーバに要求されるわけではありません。 3. 基本的な操作 最初にサーバがTCPポートの110をlisten（聴取）することで、POP3サー ビスを開始します。クライアントはサービスを要求する時に、サーバと のTCP接続を確立します。その接続が確立しますと、まずPOP3サーバが返 答します。その接続が閉じるか中止されるまで、クライアントとPOP3サー バはコマンドと応答をそれぞれやりとりします。 POP3コマンドは大文字小文字の区別がないキーワードからなっていて、 その後に1つ以上の引数を続けることができます。すべてのコマンドはCRLF の組で終了します。キーワードと引数は印字可能なASCII文字で構成され ています。キーワードと引数はそれぞれを１つの空白文字で区切られま す。キーワードは3文字か4文字です。各引数は40文字まで許されます。 Myers & Rose Standards Track [Page 3] RFC 1939 POP3 May 1996 POP3での応答は、状態を示す文字列とキーワード（付加情報が加えられ ている場合もあります）で構成されています。すべての応答はCRLFの組 で終了します。応答は、終了を示すCRLFを含めて512文字まで許されます。 現在、応答には「肯定」と「否定」の2つの状態があります。サーバは大 文字で、"+OK"（肯定）または "-ERR"（否定）のどちらかを送らなけれ ばなりません。 ひとつのコマンドの応答は、複数行にわたる場合もあります。以下に明 示される場合では、1行とCRLFからなる応答を送った後に、いくつかの行 が追加されます。それぞれの行はCRLFの組で終了します。すべての応答 の行が送られた後に、最終文字（termination octet）を表す終端文字 （十進数で46"."）とCRLFの組で構成されている最終行が送られます。複 数行の応答中に行が"." ではじまっている場合は、"." を前もって後回 しにする"バイト詰め"操作を行ないます。従って、複数行の応答は "CRLF.CRLF"の5文字で終了します。複数行の応答を調べる場合には、ク ライアントはその行が "."ではじまっているかどうかをチェックします。 その後にCRLFが続かなければ、その行の最初の"."を取り除きます。CRLF が"." に続いている場合は、POP3 サーバからの応答はそこで終わり、 ".CRLF" を含んでいる行は複数行の応答の一部分とはみなされません。 POP3セッションは、その活動中に多くの状態を遷移しながら進んでいき ます。一度TCP接続が確立して、POP3 サーバが挨拶をすると、そのセッ ションは認証状態になります。この状態ではクライアントはPOP3 サーバ に対して、身分証明をする必要があります。クライアントがこれに成功 しますと、サーバはクライアントの郵便受けに関する資源を取得します。 そして、セッションは手続き状態に移行します。この状態のとき、クラ イアントはPOP3サーバに動作を要求します。クライアントがQUITコマン ドを送信すると、そのセッションは更新状態になります。 この状態では、POP3サーバは手続き状態の間に得たいくつかの資源を解 放して、終了の挨拶をします。そしてTCP接続は閉じられます。 サーバは認識できない、実行できない、または構文的に無効なコマンド に対しては否定を表す文字列で応答しなくてはなりません。サーバは、 セッションを間違っている場合に出されたコマンドに対しても、否定を 表す文字列を使って返答しなければなりません。一般的に、クライアン トがオプショナルコマンドを実装していないサーバと、コマンドを処理 しないまたは処理できないサーバを区別する手法はありません。 POP3サーバは非通信オートログアウトタイマーを持つこともできます。 そのてのタイマーの継続場合間は、少なくとも10分はなければなりませ ん。サーバはその10分の間にクライアントからのコマンドを受け付ける と、タイマーをリセットします。タイマーが制限場合間に達してしまう と、そのセッションは更新状態に入れません。サーバはクライアントに 対していくつかのメッセージを消したりせず、何も応答せずにTCP接続を 閉じるようにしてください。 Myers & Rose Standards Track [Page 4] RFC 1939 POP3 May 1996 4. 認証状態(The AUTHORIZATION State) まずPOP3クライアントがTCP接続を確立したならば、POP3サーバは挨拶を 一行発行します。これは肯定応答とみなせます。例えば次のような応答 です。 S: +OK POP3 server ready この時、POP3セッションは認証状態になります。クライアントは、POP3 サーバに、自身の身分証明をしなくてはなりません。このドキュメント にはこのための２つの手法、USERコマンドとPASSコマンドの組合せと、 APOPコマンドが記述されています。これらの手法についてはこのドキュ メントの後ろに記述されています。追加の認証機構は、[RFC1734] に記 述されています。すべてのPOP3サーバに要求される認証を得る方法は一 つとは限りませんが、POP3サーバは少なくとも一つは認証を得る手法を サポートしなければなりません。 一度POP3サーバが、認証コマンドを通してクライアントが適切な郵便受 けへのアクセスを与えられるべきだと決定すれば、そのセッションが更 新状態になる前にメッセージが変更されたり削除されないように、郵便 受けを排他的なアクセスからロックします。うまくロックできるとPOP3 サーバは肯定応答をします。この場合、POP3セッションは手続き状態に なり、その時点では削除マークのついたメッセージは存在しません。 もし郵便受けが何らかの理由（例えば、ロックできなていなかったり、 クライアントが適切な郵便受けへのアクセスを拒んだり、郵便受けが解 析できなかった）により開かれないのなら、POP3サーバは否定を表す文 字列で応答をします。 （鍵を得られても、POP3サーバが否定な状態を表す文字列を使って応答 するつもりであれば、POP3サーバはコマンドを拒絶するために前のロッ クを解放する必要があります。）否定を示す文字列を返した後そのサー バは接続を閉じるべきです。もしサーバが接続を閉じなかったらクライ アントは新しい認証コマンドを発行し再開してもかまいませんし、QUIT コマンドを発行してもかまいません。POP3サーバが郵便受けを開いた後、 サーバは各メッセージに対してメッセージ番号を割り当て、文字単位で 各メッセージのサイズを表示します。郵便受けの最初のメッセージには、 メッセージ番号 "1"、二番目のメッセージには "2"のようにn番目のメッ セージには "n" を割り当てます。POP3のコマンドと応答では、すべての メッセージ番号とメッセージのサイズは十進法で表現されます。 ここで認証状態で使えるQUITコマンドの概要を示します。 Myers & Rose Standards Track [Page 5] RFC 1939 POP3 May 1996 QUIT 引数 : ありません 制限 : ありません 考えられる応答: +OK 例: C: QUIT S: +OK dewey POP3 server signing off 5. 手続き状態(The TRANSACTION State) クライアントがPOP3サーバへの認証に成功して、POP3サーバが適切な郵 便受けを固定して開いた場合、POP3セッションは手続き状態に移ります。 クライアントは次にあげるPOP3コマンドを何度か発行できます。POP3サー バはそれぞれのコマンドに返答をします。最後にはクライアントがQUIT コマンドを出してPOP3セッションは更新状態に移ります。 手続き状態で有効なコマンドを以下に紹介します。 STAT 引数: ありません 制限: 手続き状態でのみ使用可能です 吟味: POP3サーバは、郵便受けに関する情報を含んだ1行の肯定応答 をします。この行は"簡易一覧(drop listing)"と呼ばれてい ます。 すべてのPOP3サーバは、解析を簡単にするために簡易一覧用 のフォーマットを要求します。肯定応答は"+OK"の他に、空 白、郵便受け内のメッセージ数、空白、文字単位での郵便受 けのサイズで構成されます。このメモでは郵便受けのサイズ の後ろには何も続きません。最低限の実装でも、応答行が終 了を表すCRLFの組で終るようにするべきです。さらに高度な 実装では、他の情報も含めてもかまいません。 注意: このメモでは、簡易一覧に付加情報を供給しない実 装を奨めています。後に、クライアントに郵便受けのメッ セージを解析できるようにするための、他のオプションが 述べられています。 消去マークがついているメッセージは、どの総計にも入らな いので注意してください。 Myers & Rose Standards Track [Page 6] RFC 1939 POP3 May 1996 考えられる応答: +OK nn mm 例: C: STAT S: +OK 2 320 LIST [メッセージ] 引数: メッセージ番号（省略可能）。引数では、消去マークのつい たメッセージは参照できません。 制限: 手続き状態でのみ使用可能です 吟味: 引数が与えられた場合には、POP3 サーバはそのメッセージに 関する情報を含んでいる肯定応答の行を返します。この行 は、”詳細一覧(scan listing)”と呼ばれます。 もし引数がなくてPOP3サーバが肯定応答をしたときは、複 数行の応答になります。最初の"+OK"の後、郵便受け内のそれ ぞれのメッセージに対して、POP3サーバはメッセージに関す る情報を含む応答をします。この行は、”詳細一覧”と呼ば れています。もし 郵便受けに1つもメッセージがなければ、 POP3サーバは詳細一覧のない応答をします。つまり、POP3サー バは後ろに終了文字とCRLFの組を含む行の応答をします。 （構文の）解析を簡単にするために、すべてのPOP3サーバに は、詳細一覧用のフォーマットが必要です。詳細一覧はメッ セージ番号から構成されており、メッセージ番号の後には一 つの空白、メッセージの文字数が続きます。メッセージのサ イズを計算する方法は、メッセージの形式のところで述べま す。このメモでは詳細一覧のメッセージの後は何も続きませ ん。最低限の実装でも、応答の行がCRLFの組で終るようにす るべきです。さらに高度な実装では、メッセージから解析さ れる他の情報を含むようにしてもかまいません。 注意: このメモでは、詳細一覧に関する付加情報を供給し ないような実装を推奨しています。この他に、（オプショ ンで）クライアントがより簡単に mail drop 内のメッセー ジを解析できるような機能が後で吟味されています。 消去されたというマークがついているメッセージは、リスト されないので注意してください。 考えられる応答: +OK scan listing follows +ERR no such message Myers & Rose Standards Track [Page 7] RFC 1939 POP3 May 1996 例: 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 メッセージ 引数: 消去マークがつけられていないメッセージ番号（省略可能） 制限: 手続き状態でのみ使用可能です 吟味: POP3サーバが肯定応答をすると、応答は複数行にわたりま す。最初の"+OK"の後、POP3サーバは、与えられたメッセージ 番号に対応するメッセージを送信します。（複数行にわたる 応答の場合のすべてと同様に）終端文字をバイト詰めするこ とに注意してください。 考えられる応答: +OK message follows -ERR no such message 例: C: RETR 1 S: +OK 120 octets S: S: . DELE メッセージ 引数: 消去マークがつけられていないメッセージ番号 制限: 手続き状態でのみ使用できます Myers & Rose Standards Track [Page 8] RFC 1939 POP3 May 1996 吟味: POP3サーバは、メッセージに消去マークをつけます。POP3サー バはそのあとのそのメッセージに対応づけられたメッセージ 番号へのいかなる参照にも、エラーコードを返します。実際 には、POP3サーバは、更新状態に移るまでそのメッセージを 消去しません。 考えられる応答; +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 引数: ありません 制限: 手続き状態でのみ使用可能です 吟味: POP3サーバは何もしません。OKを返すだけです。 考えられる応答: +OK 例: C: NOOP S: +OK RSET 引数: ありません 制限: 手続き状態でのみ使用可能です 吟味: POP3サーバに消去マークを付けられたメッセージがあれば、 マークが外されます。 考えられる応答: +OK Myers & Rose Standards Track [Page 9] RFC 1939 POP3 May 1996 その後、POP3サーバはOKを返します。 例: C: RSET S: +OK maidrop has 2 messages （320 octets） 6. 更新状態(The UPDATE State) 手続き状態でクライアントがQUITコマンドを発信すると、POP3のセッショ ンは更新状態に入ります。（もしクライアントが認証状態でQUITコマン ドを発したなら、POP3のセッションは更新状態にはならずに終了するこ とに注意してください。） もし、クライアントからのQUITコマンド以外の理由でセッションが終了 した時は、POP3のセッションは更新状態には移らず、どんなメッセージ も郵便受けから取り除かないようにするべきです。 QUIT 引数: ありません 制限: ありません 吟味: POP3サーバは削除のマークが付けられたすべてのメッセージ を郵便受けから消して、その結果を返します。メッセージを 取り除いている間に、資源が足りなくなったなどのエラーが あった場合、消去マークのついたメッセージのいくつかが削 除されなかったりまたは１つも削除されないという結果にな るかも知れません。いかなる場合でも、サーバは消去のマー クがつけられていないメッセージを取り除いてしまってはい けません。 削除が成功しても失敗しても、サーバは郵便受けへの排他的 アクセスロックを解放して、TCPの接続を閉じます。 考えられる応答: +OK -ERR some deleted messages not remove 例: C: QUIT S: +OK deweyPOP3server signing off （maildrop empty） ... C: QUIT S: +OK deweyPOP3server signing off （2 messages left） ... Myers & Rose Standards Track [Page 10] RFC 1939 POP3 May 1996 7.POP3のオプションコマンド 上で述べたPOP3のコマンドはPOP3サーバの必要最小限の実装でサポート されなければなりません。 簡単なPOP3のサーバの実装を残しながら、次のオプションのPOP3コマン ドでPOP3のクライアントがより自由にメッセージを扱えるようになりま す。 注: このメモは特に、強化された簡易、詳細一覧の機能を開発する代 わりにこれらのコマンドを支えるための実装を強くすすめるものです。 つまりこのメモの考え方はPOP3のサーバではなくクライアントの部分 に知恵を与えることです。 TOP msg n 引数: 消去のマークのついていないメッセージの番号、 自然数のメッセージの行数 制限: 手続き状態のときだけ使用可能です 吟味: POP3サーバが肯定応答をすると、複数の行が返ってきます。 最初の+OKの後、POP3サーバはメッセージのヘッダと、本体部 分とヘッダを区切る空行と、引数で示された行数のメッセー ジ本文とを送ります。終端記号は（すべての複数行が対応し ているのと同じように）バイト詰めされていることに注意し てください。 もしPOP3クライアントから請求された行数が本体の行数より も大きければ、POP3サーバはそのメッセージ全部を送ること に注意してください。 考えられる応答: +OK top of message follows -ERR no such message 例: C: TOP 1 10 S: +OK S: S: . ... C: TOP 100 3 S: -ERR no such message Myers & Rose Standards Track [Page 11] RFC 1939 POP3 May 1996 UIDL [msg] 引数: 引数があるときは、消去にマークされたものは参照できませ ん。消去のマークがついていないメッセージの番号（オプショ ン） 制限: 手続き状態のときだけ使用可能です 吟味: 引数が与えられると、POP3サーバはメッセージの情報を含む 行とともに肯定応答をします。この行をそのメッセージの ”ユニークID一覧(unique-id listing)”といいます。 引数がないときにPOP3が肯定応答をすると、複数行で応答 されます。最初の+OKの後、郵便受けの中のそれぞれのメッセー ジに対して、POP3サーバはメッセージの情報を含む1行の返答 を送ります。この行をそのメッセージの"ユニークID一覧"と 呼びます。 簡単に解析するために、すべてのPOP3サーバはユニークID一 覧用のフォーマットを使用する必要があります。ユニークID 一覧はメッセージのメッセージ番号、空白1個とメッセージの unique-idの順になります。ユニークID一覧中のunique-idの 後には情報は続きません。 メッセージのunique-idはサーバが決定する任意の文字列で、 0x21から0x7Eまでの範囲の1〜70文字で構成され、これは郵便 受けの中のメッセージを一意に識別し、セッションを越えて 存続するものです。この持続性は更新状態に入らずにセッショ ンが終わった場合でも必要です。サーバはそのunique-idを使 用しているものがある限り、与えられた郵便受けの中でunique-id を決して再使用するべきではありません。 消去のマークが付けられたメッセージは列挙されないことに 注意してください。 郵便受けの中に任意に割り当てられたunique-idを貯めておく ことは、サーバの実行にとってはより好ましいことですが、 一方でこの仕様は、unique-idがメッセージのハッシュとして 計算されるように意図されています。クライアントは、同じ uiniqu-idを持つ郵便受けの中に2つの同一なメッセージのコ ピーが存在してもいいように実装するべきです。 考えられる応答: +OK unique-id listing follows -ERR no such message Myers & Rose Standards Track [Page 12] RFC 1939 POP3 May 1996 例: 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 引数: 郵便箱を認識する文字列。これはサーバに対してのみ意味を 持ちます。 制限: POP3の挨拶の後、またはUSERかPASSコマンドを失敗した後の 認証状態で使われます。 吟味: USER、PASSコマンドの組合せを使って認証するためにはクラ イアントは最初にUSERコマンドを出さなければなりません。 POP3サーバが肯定（"+OK"）で応答してきたならは、クライアン トは認証を完了するためにPASSコマンドか、POP3のセッション を終了するためにQUITコマンドを出せます。もしPOP3サーバ がUSERコマンドに対してエラーの反応（"-ERR"）を返したな らば、クライアントは新しく認証を発しても、QUITコマンド を出してもかまいません。 サーバは郵便箱が存在しない時でも肯定応答をするかもし れません。もし郵便箱が存在してもサーバがエラーを返すか もしれませんが、サーバは平文の認証を許可しません。 考えられる応答: +OK name is a valid mailbox -ERR never heard of mailbox name 例: C: USER frated S: -ERR sorry、no mailbox for frated here ... C: USER mrose S: +OK mrose is a real hoopy frood Myers & Rose Standards Track [Page 13] RFC 1939 POP3 May 1996 PASS string 引数: サーバー/メールボックス固有のパスワード（必要） 制限: 認証状態で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) APOP name digest 引数: 郵便箱のID文字列とMD5ダイジェスト文字列（両方必要） 制限: 認証状態でPOP3に挨拶した後か、USERコマンドかPASSコマン ドが失敗した後にだけ使用できます。 Myers & Rose Standards Track [Page 14] RFC 1939 POP3 May 1996 吟味: 通常、POP3のそれぞれのセッションはUSER/PASSで始まります。 これではネットワーク上でサーバ／ユーザーのIDを特定する パスワードが平文としてに送られることになります。断続的 なPOP3の使用では、これはそれほど大きな危険を導くことは ありません。ですかPOP3クライアントの実装の多くは新しい メールが来たかどうかを確かめるために、定期的にPOP3サー バに接続します。さらにセッションの間隔は5分程度です。こ のため、パスワードが漏れる危険性は非常に高まっています。 もう一つの認証の方法は、クライアントの認証と使用の繰り 返しの両方で保護するもので、ネットワーク上にパスワード を平文としてパスワードを送る事態を引き起こさないような 認証方法が必要とされます。APOPコマンドはこの機能を与え てくれます。 APOPコマンドを実装したPOP3サーバは、その最初の挨拶文に タイムスタンプを含んでいます。タイムスタンプの文法は [RFC822]の'msg-id'に対応し、POPサーバが最初の挨拶を発行 するたびに、異ならなければなりません。例えばUNIXでそれ ぞれPOP3サーバが別のプロセスとして使用されている実装で は、タイムスタンプの文法は次のようなものです。 'prosess-ID'はプロセスのPIDの10進数の値、clockはシステム時 計の10進数の値、hostnameはPOP3サーバが動いているホストに一 致したフルドメイン名とします。 POP3クライアントはこのタイムスタンプの記録を使ってAPOPコマ ンドを発行します。'name'引数はUSERコマンドの引数'name'と等 しい文字列を持っています。ダイジェスト引数は、共有鍵とタイ ムスタンプを繋げた文字列を、MD5[RFC1321]アルゴリズムを使っ て計算したものです。 この共有鍵はPOP3のクライアントとサーバだけが知っている 文字列です。これを知られますと、誰でも名前を偽装するこ とできますので、不正な秘密の暴露を防ぐように十分注意し てください。'digest'引数そのものはASCII小文字で書かれた 16進数の16文字です。 POP3サーバがAPOPコマンドを受けとると、ダイジェストを検 証します。ダイジェストが正しければPOP3サーバは肯定の返 事を返し、POP3セッションは手続き状態になります。または 否定応答が返されて、POP3セッションは認証状態に保たれま す。 Myers & Rose Standards Track [Page 15] RFC 1939 POP3 May 1996 共有鍵の長さが増えるに従って、それを見破る事が困難にな ることに注意してください。ですから、共有鍵は長い文字列 （下の例のような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 というダイジェストになります。 （訳注：tanstaafはロバート・Ａ・ハインラインの「月は無 慈悲な夜の女王」に出てくる単語です。有名な単語なので、 パスワードに使うことは推奨されません。） 8. 基準化と操作性の考慮 以上で説明したいくつかのオプション機能がPOP3プロトコルに加えられ たことで、ほとんどのユーザがお互いに関係ないような、大規模な商業 ポストオフィス運用をするような環境での経験がつまれました。これら や他の状況において、ユーザとPOP3クライアントのメーカは、UIDLコマン ドを使うこととDELコマンドを出さないという組合せを使えば、普通IMAP の機能にあるような"半永久的に貯蔵できる郵便受け" の弱いバージョン を提供することができることを発見しました。 もちろん既存の接続で、新着メッセージがないか調べたり、サーバにお ける複数のフォルダを支援したりなどという他のIMAPの機能は、POP3に は含まれていません。 これらの機能が一般ユーザに使われるときには、既読メッセージは制限 なくサーバに蓄積していく傾向があります。サーバ管理者の立場からは、 これは明かに望ましくないことです。POP3の限られた能力は、数百や数 千のメッセージを持つような郵便受けを運用するには十分ではないので、 実際に状態は悪化します。 Myers & Rose Standards Track [Page 16] RFC 1939 POP3 May 1996 結果的に、大規模なマルチユーザを扱っているサーバの管理者、特にユー ザがPOP3経由でしか郵便受けにアクセス出来ないようなサーバは、管理 者に以下のオプションを考慮することを推めます。 * ユーザごとに郵便受けの（スプール領域の）容量制限をする。 メッセージが溜ると、ユーザの郵便受けに新しいメッセージを受けと る余裕がなくなってしまうことが、このオプションでの不利益です。 このオプションを選んでいるサイトは、ユーザの郵便受けに適当なメッ セージを挿入することで、差し迫った、または最近の割当の枯渇状態 をユーザに知らせるように確認するべきです。 * メールの貯蓄に関してのサイトの方針をサーバで執行する。 サイトがメッセージの既読、未読に関わらず、メッセージの貯蓄や維 持に関するローカルな方針は自由に作れます。例えば、サイトは未読 メッセージを60日後に、既読メッセージを7日後に消すような方針に してもかまいません。そのようなメッセージの消去の仕方は、POP3の プロトコルの範疇ではないので、プロトコルの侵害とはみなされませ ん。 サーバの管理者は、メッセージの消しかたについての実施している方 針を、すべてのユーザに知らせるべきです。 クライアントは、サイトがメッセージ消去を自動的に行なうと仮定せ ず、適当な場合にDELEコマンドを使って明示的にメッセージを消去す るべきです。 メッセージを強制的に消去する方針のサイトは、ユーザを困惑させる かも知れないことに注意すべきです。なぜならPOP3クライアントはメー ルをサーバに残すオプションを使用するかもしれませんが、実はサー バが対応していない場合があるからです。 メッセージは1回だけサーバからダウンロードされて、この後に消去 される、というある特別なサイトの方針があります。これは”あるク ライアントがきちんとQUITで終ったPOP3 loginの後、RETRコマンドの セッションでダウンロードされたすべてのメッセージを消す。”とい うPOP3サーバのソフトウェアで実現できます。 異常な接続で終った場合（すなわちクライアントからQUITを受けとら なかった場合）メッセージを消去さないことが重要です。なぜならク ライアントは受信に失敗したか、メッセージの貯蔵に失敗したかもし れないからです。 ダウンロードして消すという方針のサーバでは、オプションのTOPコ マンドを無効にするか制限したいと思うかもしれません。なぜならTOP コマンドをメッセージ全体をダウンロードする代替メカニズムとして 使われてしまうかもしれないからです。 Myers & Rose Standards Track [Page 17] RFC 1939 POP3 May 1996 9. POP3コマンドのまとめ POP3の基本コマンド: USER name 認証状態で有効 PASS string QUIT STAT 手続き状態で有効 LIST [msg] RETR msg DELE msg NOOP RSET QUIT POP3のオプションコマンド: APOP name digest 認証状態で有効 TOP msg n 手続き状態で有効 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]に従います。 重要な注意事項に、行末の表現形式が異なるためにサーバ側のメッセー ジの文字数と、クライアント側の同じメッセージの文字数が異なること があります。 通常、POP3セッションの認証状態で、サーバは郵便受けを開くときに各 メッセージの文字数をカウントできます。たとえば、もしPOP3サーバが 内部形式で行末を単一文字で表現している場合でも、メッセージでこの 文字が現われた場合は２文字としてカウントします。また、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. セキュリティについての考察 PASSコマンドを使用すると、平文でネットワーク上にパスワードを送り ます。 POP3セッションでは、APOPコマンドを使用することで最初の身元の確認 とその後のセッションの繰り返しにおける保護ができると推定します。 従ってPASS及びAPOPコマンドの両方を実装したPOP3サーバーはユーザー に対して両方を使ったアクセスを許しません。言い換えれば、ある郵便 箱名に対しては、与えられたUSER/PASSコマンドシーケンス、またはAPOP コマンドのどちらか一方のみが許されて混在できません。 更に、共有するパスワードの長さが長いほど、それが漏れることは困難 となります。 USERコマンドに -ERR と答えるサーバは、攻撃者達にどれが正当な名前 かの手掛りを与えることになります。 RETR及びTOPコマンドは、ネットワーク上では平文でメールを送ります。 このメモでは、これら以外のセキュリティについては論じられていませ ん。 14. 謝辞 POPファミリーには、長くて変化に富んだ歴史があります。 POP3は主にRFC1460のマイナーな改訂ですが、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との相違 このメモは、標準ドラフトであるRFC 1725 の改訂です。そのドキュメン トから次の変更を行いました : - コマンドキーワードでは、大文字と小文字を区別しないことを明確 にしました。 - サーバは、「+OK」と「-ERR」を大文字で送らなければならないこ とを明確にしました。 - 最初の挨拶は、肯定応答と変えられる文字列ではなく、肯定の返 事だということを明確にしました。 - 実行されないコマンドの振舞いを明確にしました。 - USERコマンドとPASSコマンドのオプションを作成しました。 - USERコマンドへの可能な応答を明確にしました。 - 混乱を減らすために、USERコマンドとPASSコマンドの例での順番を 逆にしました。 - PASSコマンドは、成功したUSERコマンドの直後だけに与えられるこ とを明確にしました。 - UIDの要求が継続することを明確にして、実行における注意をいく つか加えました。 - 1つのUIDの長さの制限を70文字に指定しました。 - 状況を示す文字列の長さを、CRLFを含めて512文字に制限しました。 - 空の郵便箱では引数がないLISTコマンドは成功を返すことを明確に しました。 - LISTコマンドからMessage Formatセクションへの参照を加えました。 - 失敗した場合のQUITの振舞いを明確にしました。 - セキュリティセクションで、APOPコマンドとUSERコマンドの混在使 用を前提にしないことを明確にしました。 - RFC1730及び1734への参照を加えました。 - UAが送信システムにメール送信をする方法を明確にしました。 - TOPコマンドへの2番目の引数が行数だということを明確にしました。 Myers & Rose Standards Track [Page 22] RFC 1939 POP3 May 1996 - ユーザーからのPASSとAPOPの両方を受け入れないように、セキュリ ティ考察セクションで、サーバへの提案を、”している”から”す るべき”に変更しました。 - ”基準化と操作性の考慮”セクションを加えました。 付録 B. コマンドインデックス APOP ....................................................... 14 DELE ....................................................... 8 LIST ....................................................... 7 NOOP ....................................................... 9 PASS ....................................................... 14 QUIT ....................................................... 6 QUIT ....................................................... 10 RETR ....................................................... 8 RSET ....................................................... 9 STAT ....................................................... 6 TOP ....................................................... 11 UIDL ....................................................... 12 USER ....................................................... 13 Myers & Rose Standards Track [Page 23]