原文：ftp://ftp.rfc-editor.org/in-notes/rfc1939.txt
2004/10/01 0.1.0 初版
2005/12/11 0.1.1 一年以上ぶりに全体的に見直し。少しは読みやすくなったかと思います。
サイト内関連リンク：RFC 1730 IMAP4、RFC 5034 POP3 SASL
この文書はインターネットコミュニティの為のインターネット標準トラックプロトコルについて述べており、改良に向けての議論と提案とを求めている。このプロトコルの標準化の状態と状況は "Internet Official Protocol Standards"(STD 1)を参照して欲しい。この文書の配布は無制限である。
インターネット上の比較的小規模のノードでは、メッセージ転送システム(MTS)を維持する事はしばしば実用的でない。例えばワークステーションは、SMTP サーバー[RFC821]や、それに相当するローカルのメール配送システムを常駐させたり連続運転させたりする為の十分な資源(CPUサイクルやディスクスペース)を持たないだろう。同じように、パーソナルコンピュータが長時間に渡りIP型ネットワークとの相互接続を維持する事は高価(もしくは不可能)だろう(そのノードは "接続性(connectivity)" として知られる資源を欠いている)。
それにもかかわらず、これら比較的小規模のノード上でメール管理を可能にする事はしばしば非常に役に立つし、それらはしばしばメール処理タスクを手助けするユーザーエージェント（UA）をサポートしている。この問題を解決する為に、MTS 実装をサポートしているノードは能力の乏しいノードの為のメールドロップサービスを提供する。Post Office Protocol - バージョン 3(POP3)は、ワークステーションが有用な方法でサーバーホスト上のメールドロップに動的にアクセスする事を可能にすることを目的としている。通常これは、サーバーの保持しているメールをワークステーションが回収する事を可能にする為に POP3 プロトコルが使用される事を意味する。
POP3 は、サーバー上のメールの広範囲で巧妙な操作を提供する事は意図されていない。通常、メールはダウンロードされ、そして削除される。より進んだ(そして複雑な)プロトコル IMAP4 は、[RFC1730] で議論されている。
この文書の残りでは、用語 "クライアントホスト" は POP3 サービスを利用するホストを指し、用語 "サーバーホスト" は POP3 サービスを提供するホストを指す。
この文書ではクライアントがメールを転送システムに投入する方法は規定しないが、この文書の主義と首尾一貫する手法をここに記す。
クライアントホスト上のユーザーエージェントがメッセージを転送システムに投入しようとする場合、クライアントホストはリレーホストとの SMTP 接続を確立し、全てのメールをそこに送る。リレーホストはクライアントホストの為の POP3 サーバーホストになれる（しかし、要求はされない）。当然リレーホストは任意の受取アドレスへメールを配送可能でなければならないが、この機能は全ての SMTP サーバーに要求されるものではない。
初めに、サーバーは TCP ポート 110 でリスニングする事で POP3 サービスを開始する。クライアントホストがそのサービスを使用したい場合、サーバーホストとのTCP接続を確立する。接続が確立すると、サーバーは挨拶を送る。その後クライアントと POP3 サーバーとは、接続が閉じられるか中止されるまで、命令と応答とを(それぞれ)交わす。
POP3 の命令は大文字・小文字の区別されないキーワードから構成され、たいていは１つ以上の引数が続く。全ての命令は CRLF で終了する。キーワードと引数とは印刷可能な ASCII 文字から構成される。キーワードと引数とは単一の空白文字で区切られる。キーワードは３文字か４文字の長さである。各々の引数は 40 文字の長さまで許される。
POP3 の応答は、状態識別子と、たいていは追加情報が続くキーワードとから構成される。全ての応答は CRLF で終了する。応答は終端の CRLF を含めて 512 文字の長さまで許される。現在、２つの状態識別子、肯定("+OK")と否定("-ERR")とが存在する。サーバーは "+OK" と "-ERR" とを大文字で送信しなければならない(MUST)。
ある種の命令への応答は複数行になる。そのような場合、以降で詳述するが、応答の最初の行と CRLF とを送信した後、各々 CRLF で終わる追加行を送信する。応答の全行が送られた時、終端オクテット(10 進コード 046、".")と CRLF とから成る最終行が送られる。複数行応答の何れかの行が終端オクテットで始まる場合、その行は応答行の前に終端オクテットをぶら下げる事で "バイト詰め" される。ゆえに複数行応答は、5 オクテット "CRLF.CRLF" で終わる。複数行応答を調べる場合、クライアントはその行が終端オクテットで始まるかどうかを調べる。もしそうで、さらに CRLF 以外のオクテットが続くなら、その行の最初のオクテット(終端オクテット)は取り除かれる。もしそうで、さらに終端オクテットの直後に CRLF が続く場合、POP サーバーからの応答は終了であり、".CRLF" を含む行は複数行応答の一部とは見なされない。
POP3 セッションは、その存続期間をいくつかの状態を通して進行する。一旦 TCP 接続が開始され POP3 サーバーが挨拶を送信すると、セッションは AUTHORIZATION 状態に入る。この状態では、クライアントは POP3 サーバーに自分自身を識別させなければならない。一旦クライアントが首尾良くそれを完了すると、サーバーはクラインアントのメールドロップに対応する資源を取得し、セッションは TRANSACTION 状態に入る。この状態では、クライアントは POP3 サーバー側に対して動作を要求する。クライアントが QUIT 命令を発行するとセッションは UPDATE 状態に入る。この状態では、POP3 サーバーは TRANSACTION 状態で取得した全ての資源を解放し、別れを告げる。その後 TCP 接続が閉じられる。
認識出来ないコマンドや実装されていないコマンド、あるいは文法的に無効なコマンドに対し、サーバーは否定状態識別子を返す事で応答しなければならない(MUST)。セッションが不適切な状態の時に発行された命令に対し、サーバーは否定状態識別子を返す事で応答しなければならない(MUST)。ある命令を実装していないサーバーと、その命令を実行出来ないまたは気が進まないサーバーとをクライアントが区別する一般的な方法は存在しない。
POP3 サーバーは不活性自動ログアウトタイマーを持つ事を許される。そのようなタイマーは最低 10 分の持続時間を持たなければならない(MUST)。その間隔中は、クライアントからの任意のコマンドの受信により、自動ログアウトタイマーはリセットされるべきである。タイマーが時間切れになった場合、セッションは UPDATE 状態に入らず、サーバーはクライアントに何の応答も送信する事なく、如何なるメッセージも削除する事なく、TCP 接続を閉じるべきである。
一旦クライアントによって TCP 接続が開始されると、POP3 サーバーは一行の挨拶を発行する。これはどのような肯定応答でも良い。例えば以下のような内容である。
S: +OK POP3 server ready
現在、POP3 セッションは AUTHORIZATION 状態である。クライアントは POP3 サーバーに自分自身を認識させ、認証させなければならない。これを実行するのに取り得る二つのメカニズムがこの文書で説明されている。USER 命令と PASS 命令との組み合わせと、APOP 命令である。両メカニズムはこの文書で後に説明される。追加の認証メカニズムが [RFC1734] で説明されている。全ての POP3 サーバーに要求される単一の認証メカニズムは存在しないが、POP3 サーバーは当然最低でもひとつの認証メカニズムをサポートしなければならない。
何れかの認証命令により、適切なメールドロップへのアクセス権をクライアントに与えるべきだと POP3 サーバーが決定すると、セッションが UPDATE 状態に入る前にメッセージが変更されたり削除されたりする事を防ぐ必要性から、POP3 サーバーはメールボックスの排他ロックを取得する。首尾良くロックが取得されると、POP3 サーバーは肯定状態識別子を返す。POP3 セッションは現在 TRANSACTION 状態に入り、どのメッセージも削除の印は付けられていない。メールドロップが何らかの理由で開けない場合(例えば、ロックを取得できない、クライアントがメールドロップへのアクセスを拒否された、あるいはメールドロップを解析出来ない場合)、POP3 サーバーは否定状態識別子を返す(POP3 サーバーがロックを取得したが否定状態識別子を返す場合、POP3 サーバーは命令を拒否する前にロックを開放しなければならない)。否定状態識別子を返した後、サーバーは接続を閉じる事を許される。サーバーが接続を閉じない場合、クライアントは新しい認証命令を発行して再開するか、QUIT 命令を発行する事を許される。
POP3 サーバーがメールドロップを開いた後、サーバーは各々のメッセージにメッセージ番号を割当て、各々のオクテット単位のメッセージサイズを記録する。メールドロップ中の最初のメッセージにメッセージ番号 "1"、2番目には "2" のように、メールドロップ中の n 番目のメッセージ にメッセージ番号 "n" が割当てられる。POP3 の命令と応答とでは、全てのメッセージ番号とメッセージサイズは 10 進数で表される。
ここでは AUTHORIZATION 状態での QUIT 命令の要約を示す。
一旦クライアントが POP3 サーバーに自分自身を首尾良く識別させ、POP3 サーバーが適切なメールドロップを開いてロックすると、セッションは TRANSACTION 状態となる。クライアントは現在、以下の POP3 命令をどれでも繰り返し発行する事が許される。各命令の後、POP3 サーバーは応答を発行する。最後にクライアントは QUIT 命令を発行し、POP3 セッションは UPDATE 状態に入る。
TRANSACTION 状態で有効な POP3 コマンドは以下の通り。
POP3 サーバーはメールドロップの情報を含む一行の肯定応答を発行する。この行はそのメールドロップの "ドロップリスト(drop listing)" と呼ばれる。
解析を簡単にする為に、全ての POP3 サーバーはドロップリストに特定の形式を使用する事を要求される。この肯定応答は "+OK" に続けて単独の空白文字、メールドロップ中のメッセージ数、単独の空白文字、オクテット単位のメールドロップサイズから構成される。この文書はメールドロップサイズの後に何が続くかに付いては要求しない。最小限の実装は単に CRLF で応答行を終えれば良く、より進歩した実装は他の情報を含んでも良い。
注意: この文書は実装がドロップリストに追加情報を提供しない事を強く推奨する(STRONGLY)。クライアントがメールドロップ中のメッセージを解析する事を可能にするその他の任意の機能に付いて、後程検討する。
削除の印を付けられたメッセージはどちらの合計にも数えられない事に注意して欲しい。
引数が与えられている場合、POP3 サーバーはそのメッセージの情報を含む一行の肯定応答を発行する。この行はそのメッセージの "スキャンリスト(scan listing)"と呼ばれる。
引数が与えられておらず、POP3 サーバーが肯定応答を発行する場合、その応答は複数行である。最初の +OK の後、メールドロップ中のメッセージ毎に、POP3 サーバーはそのメッセージの情報を含む一行を返す。この行もそのメッセージの "スキャンリスト(scan listing)"と呼ばれる。メールドロップ中にメッセージが存在しない場合、POP3 サーバーはスキャンリストを返さず、終端オクテットに続けて CRLF を含む一行の肯定応答を発行する。
解析を簡単にする為に、全ての POP3 サーバーはスキャンリストに特定の形式を使用する事を要求される。スキャンリストは、そのメッセージのメッセージ番号、単独の空白、オクテット単位の正確なメッセージサイズから構成される。メッセージの正確なサイズの計算方法は、後の "メッセージ形式" セクションで説明される。この文書はスキャンリストのメッセージサイズの後に何が続くかに付いては要求しない。最小限の実装は単に CRLF で応答行を終えれば良く、より進歩した実装はメッセージを解析した他の情報を含んでも良い。
注意: この文書は実装がスキャンリストに追加情報を提供しない事を強く推奨する(STRONGLY)。クライアントがメールドロップ中のメッセージを解析する事を可能にするその他の任意の機能に付いて、後程検討する。
削除の印を付けられたメッセージはリストされない事に注意して欲しい。
TRANZACTION 状態で QUIT 命令を発行すると、POP3 セッションは UPDATE 状態に入る。( (AUTHORIZATION 状態で QUIT 命令を発行した場合、POP3 セッションは終了するが UPDATE 状態には入らない事に注意してほしい)
クライアント発行の QUIT 命令以外の理由でセッションが終了する場合、POP3 セッションは UPDATE 状態には入らず、メールドロップから如何なるメッセージも削除されてはならない(MUST)。
POP3 サーバーは削除の印を付けられている全てのメッセージを削除し、この操作の結果を返す。メッセージ削除中にリソース不足等のエラーが発生し場合、メールドロップは、削除の印を付けられていたメッセージが幾つか削除されたか、全く削除されていないか、どちらかの状態となる。どちらの場合でもサーバーは、削除の印が付けられていない如何なるメッセージも削除してはならない。
削除が成功したかどうかに関わらず、サーバーはメールドロップの全ての排他アクセスロックを開放し、TCP 接続を閉じる。
これまでに議論された POP3 命令は、POP3 サーバーの最小の実装でもサポートされなければならない。
以下で説明する任意の POP3 命令は、単純な POP3 サーバー実装を維持する一方で、メッセージ処理において POP3 クライアントにより大きな自由を与える。
注意: この文書は実装に対し、補強されたドロップリストとスキャンリストとを開発する代わりに、これらの命令をサポートする事を強く推奨する(STRONGLY)。この文書の主義を一言でいえば、POP3 サーバーではなく POP3 クライアント側に知能を置くという事である。
POP3 サーバーが肯定応答を発行する場合、その応答は複数行である。最初の +OK の後、POP3 サーバーは(全ての複数行応答と同様に)終端文字のバイト詰めに注意しながら、メッセージのヘッダ、ヘッダと本文とを分割する空行、指定されたメッセージ本文を指定行数分、送信する。
POP3 クライアントによって要求された行数が本文の行数を越えている場合、POP3 サーバーはメッセージ全体を送信する事に注意して欲しい。
引数が与えられている場合、POP3 サーバーはそのメッセージの情報を含む一行を持つ肯定応答を発行する。その行はそのメッセージの "ユニーク ID リスト(unique-id listing)" と呼ばれる。
引数が与えられておらず、POP3 サーバーが肯定応答を発行する場合、その応答は複数行である。POP3 サーバーは、最初の +OK の後、メールドロップ中のメッセージ毎にそのメッセージの情報を含む一行を返す。その行はそのメッセージの "ユニーク ID リスト(unique-id listing)" と呼ばれる。
解析を簡単にする為に、全ての POP3 サーバーはユニーク ID リストに特定の形式を使用する事を要求される。ユニーク ID リストはそのメッセージのメッセージ番号、続いて単独の空白と、そのメッセージのユニーク ID とから構成される。ユニーク ID リストにおいて、ユニーク ID の後に続く情報は無い。
メッセージのユニーク ID はサーバーが決定する任意の文字列であり、0x21〜0x7E の範囲の 1〜70 文字から構成され、メールボックス内のメッセージを一意に識別し、セッションをまたいで持続する。セッションが UPDATE 状態に入らずに終了した場合でも、この持続性は必要とされる。サーバーは、あるユニーク ID が使用されている限り、メールドロップ中でそのユニーク ID を再使用してはならない。
削除の印が付けられているメッセージはリストされない事に注意して欲しい。
割当てたユニーク ID をサーバー実装が任意でメールドロップ内に保存する事は一般的に好ましい事であるが、この規則はユニーク ID がメッセージのハッシュとして計算されても良いという事を意味する。クライアントは、メールドロップ中のメッセージの二つのコピーが同じユニークIDを持つ状況を扱えるべきである。
USER 命令と PASS 命令との組み合わせを使用して認証する場合、クライアントは最初に USER 命令を発行しなければならない。POP3 サーバーが肯定状態識別子("+OK")を返した場合、クライアントは認証を完了する為に PASS 命令を発行するか、POP3 セッションを終了する為に QUIT 命令を発行する事を許される。POP3 サーバーが USER 命令に否定状態識別子("-ERR")を返した場合、クライアントは新しい認証命令を発行するか、QUIT 命令を発行する事を許される。
与えられた名前のメールボックスが存在しない場合でも、サーバーは肯定応答を返す事を許される。メールボックスは存在するが平文パスワードによる認証が許可されていない場合、サーバーは否定応答を返す事を許される。
クライアントが PASS 命令を発行した場合、POP3 サーバーはそのクライアントが適切なメールドロップにアクセス出来るかどうかを決定する為に、USER 命令の引数と PASS 命令の引数との組を使用する。
PASS 命令は正確にひとつの引数を持つので、POP3 サーバーは引数中の空白を引数の区切りではなく、パスワードの一部として扱っても良い。
通常の POP3 セッションは USER/PASS の交換で開始される。これは、サーバー/ユーザー ID 固有のパスワードがネットワーク上を平文で送信されるという事を意味する。一時的な POP3 の使用の場合であれば、これは大きな危険を招かない。しかしながら多くの POP3 クライアント実装は、新規メールのチェックの為に定期的に POP3 サーバーに接続する上、そのセッション開始の間隔は 5 分程度だろう。従って、パスワード盗聴の危険性はかなり高くなる。
送信元の認証と再現保護とは提供するが、ネットワーク越しの平文でのパスワード送信を含まないような別の認証方法が必要とされる。APOP命令はこの機能を提供する。
APOP 命令を実装する POP3 サーバーは、その挨拶にタイムスタンプを含む。タイムスタンプの文法は [RFC822] の 'msg-id' に相当し、POP3 サーバーが挨拶を発行する度に異ならなければならない(MUST)。例えば、POP3 サーバーのインスタンス毎に別々の UNIX プロセスが使用される UNIX 実装においては、タイムスタンプの文法は以下のようなものでも良い。
<process-ID.clock@hostname>
ここで 'process-ID' はプロセスの PID の 10 進値であり、clock はシステムクロックの 10 進値、hostname は POP3 サーバーを実行中のホストに対応する FQDN(fully-qualified domain-name)である。
POP3 クライアントはこのタイムスタンプに注目して APOP 命令を発行する。パラメータ 'name' は、USER 命令の 'name' パラメータと同じ意味を持つ。パラメータ 'digest' は、タイムスタンプ(鍵括弧を含む)の直後に共有鍵を付加した文字列に、MD5 アルゴリズム [RFC1321] を適用して計算される。この共有鍵は、POP3 クライアントとサーバーとのみが知っている文字列である。この秘密の情報は、その名前のユーザーへのなりすましを誰にでも許してしまう事になる為、認証されない公開を防ぐように十分な注意が必要である。'digest' パラメータ自身は、小文字の ASCII 文字を使った 16 進形式で送信される 16 オクテットの値である。
APOP 命令を受け取ると、POP3 サーバーはダイジェストの内容を確かめる。ダイジェストが正しい場合、POP3 サーバーは肯定応答を発行し、POP3 セッションは TRANSACTION 状態に入る。そうでなければ否定応答が発行され、POP3 セッションは AUTHORIZATION 状態に留まる。
共有鍵の長さが増えるほど、それを導き出す事が難しくなる事に注意して欲しい。従って、共有鍵は長い文字列(下の例で示す8文字よりもかなり長い文字列)にするべきである。
この例では、共有鍵は 'tanstaaf' である。従って文字列
<1896.697170952@dbc.mtview.ca.us>tanstaaf
に MD5 アルゴリズムが適用され、次のダイジェスト値が生成される。
c4c9334bac560ecc979e58001b3e22fb
上で説明した幾つかの任意の機能が POP3 プロトコルに追加されて以来、大規模な商用ポストオフィスの運用(そこではほとんどの利用者が互いに無関係である)において、これらを使用する経験が積まれてきた。その状況とそれ以外の状況との中で、POP3 クライアントのユーザーとベンダーは、UIDL 命令の使用と DELE 命令を発行しない事との組み合わせが、IMAP では普通に提供される "半永久的リポジトリとしてのメールドロップ" 機能の下位バージョンを提供出来る事を発見した。もちろん、新しく到着したメッセージを既存の接続でポーリングしたり、サーバー上での複数フォルダをサポートするといった、IMAP4 のその他の能力は、POP3 では提供されない。
普通のユーザーがこれらの機能をこのような形で使用するようになった時、既読メッセージがサーバー上に際限なく蓄積される傾向を持つようになった。サーバー管理者の立場から見て、これは明らかに望ましくない状況である。この状況は、数百、数千のメッセージを持つメールドロップを能率的に扱う事の出来ない POP3 の能力の限界という事実によって悪化する。
結果として大規模なマルチユーザー向けサーバーの管理者は、特にメールドロップへのアクセスが POP3 経由だけの場合、次のような選択を考慮する事を推奨される。
サーバー上の未読・既読両メッセージの保持と保存とに関するローカルな方針を建てる事は、サイトの自由である。例えばあるサイトは、未読メッセージを 60 日後に削除し、既読メッセージを 7 日後に削除しても良い。このようなメッセージ削除は POP3 プロトコルの範囲外であり、プロトコル違反とは見なされない。
メッセージ削除のポリシーを実施するサーバーの管理者は、その方針が施行されている事を全ユーザーに認識させるように取り計らうべきである。
クライアントは、サイトの方針がメッセージ削除を自動化していると仮定してはならない。適切な時に、DELE 命令によるメッセージの明示的な削除を継続的に行うべきである。
ユーザーの POP3 クライアントには、サーバー上にメールを残すというような、サーバーで実際にはサポートされていないオプション設定が含まれている可能性がある為、メッセージ削除の方針の実施は、ユーザーコミュニティを混乱させるかもしれないという事に注意するべきである。
サイト方針の特別なケースとしては、メッセージはサーバーから一度だけダウンロードしても良く、それが完了すると削除されると言う方法がある。これは POP3 サーバーソフトウェアが、"クライアントによる POP3 ログインが QUIT 命令によって終わった後、RETR 命令によってそのセッション中にダウンロードされた全メッセージを削除する" という機能を持っている場合に可能である。異常な接続終了(例えば、クライアントから QUIT を受け取らなかった場合)によってメッセージが削除されない事は重要である。なぜなら、クライアントはそのメッセージを正常に受信したり保存したり出来ていないかもしれない為である。このダウンロードと削除との方針を実施するサーバーは、TOP 命令を制限または禁止したいかもしれない。それはメッセージ全体をダウンロードする別のメカニズムとして使用出来る為である。
最低限の 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" とのみが意味を持つ事に注意して欲しい。この応答以降にあるテキストはクライアントにより無視されても良い。
S: <TCP ポート 110 で接続を待つ>
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: <POP3 サーバーがメッセージ 1 を送信する>
S: .
C: DELE 1
S: +OK message 1 deleted
C: RETR 2
S: +OK 200 octets
S: <POP3 サーバーがメッセージ 2 を送信する>
S: .
C: DELE 2
S: +OK message 2 deleted
C: QUIT
S: +OK dewey POP3 server signing off (maildrop empty)
C: <接続終了>
S: <次の接続を待つ>
POP3 セッション中に送信される全てのメッセージは、インターネットテキストメッセージ [RFC822] 形式の標準に従っていると仮定される。
サーバーホスト上のメッセージのオクテット数は、行末を表す為のローカルの習慣によっては、そのメッセージに割当てられたオクテット数とは異なるかもしれないという点に注意する事は重要である。通常、POP3 セッションの AUTHORIZATION 状態の間、POP3 サーバーはメールドロップを開いた時に各々のメッセージのオクテットサイズを計算する事が出来る。例えば POP3 サーバーホストが内部的に一文字で行末を表現する場合、POP3 サーバーは単純にメッセージ中のその文字の出現をそれぞれ 2 オクテットと数える。メッセージ中の終端オクテットで始まる行は、POP3 クライアントが複数行応答を受け取った時にバイト詰めの為の終端オクテットを全て取り除くので、2 倍に数えられる必要はない(かつ、数えられるべきではない)事に注意して欲しい。
[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.
APOP コマンドが送信元の認証と再現保護とを提供すると推測される。従って、PASS 命令と APOP 命令とを両方実装する POP3 サーバーは、ひとりのユーザーに対して両方のアクセスを許可するべきではない。すなわち、あるメールボックス名の為には USER/PASS 命令または APOP 命令のどちらかが許可され、両方は許可されないべきである。
さらに、共有鍵の長さが増えるほど、それを導き出すのが難しくなる事に注意して欲しい。
USER 命令に対して -ERR を答えるサーバーは、潜在的な攻撃者に対してその名前が有効であるという手がかりを与えている事になる。
PASS 命令は、パスワードをネットワーク越しに平文で送信する。
RETR 命令と TOP 命令は、メールの内容をネットワーク越しに平文で送信する。
他の点では、この文書においてセキュリティ問題は議論されていない。
POP ファミリーは、長く変化と波乱に富んだ歴史を持っている。主に RFC1460 への重要でない改訂であるが、POP3 は RFC918、937、1081 にて提出されたアイデアに基いている。
加えて、Alfred Grimstad、Keith McCloghrie、Neil Ostroff は、APOP 命令に付いて重要な論評を提供した。
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
この文書はドラフトスタンダードである RFC1725 の改訂である。その文書から以下の変更が行われている。
APOP
DELE
LIST
NOOP
PASS
QUIT
QUIT
RETR
RSET
STAT
TOP
UIDL
USER