竹内信和(xkd@xkd.com)
なるべく直訳するように心がけていますが、あまりにも日本語として理解しにくい部分は多少の意訳が含まれています。
翻訳に誤りがないように、この翻訳が正しいことは全く保証されません。
この翻訳を利用される場合は、なるべく原文を同時に参照されることをお勧めします。
尚、ミスがあった場合は訳者までご指摘下さい。
この翻訳が、読者の手助けに少しでもなれば幸いです。
maildrop=一般的に言うところのMAILBOX
byte-stuff=Byteで埋められる。
オクテット=一般的にはバイトと同等。正確には1バイトは8ビットとは限らないが、1オクテットは8ビットの事を指す。
Network Working Group J. Myers
Request for Comments: 1725 Carnegie Mellon
Obsoletes: 1460 M. Rose
Category: Standards Track Dover Beach Consulting,
Inc.
November 1994
このドキュメントはインターネット社会のためのインターネット標準トラックプロトコルを指定しており、改善のために論議と示唆を求める。
標準化状態とこのプロトコルの状態は「インターネットの公式のプロトコル標準」（ＳＴＤ1）の現在の版を参照してください。
このメモの配布は無制限である。
このメモは RFC 1460 Draft Standard の改訂版である。 そのドキュメントから次の変更をする：
インターネットにおいて、ある特定のタイプのより小さいノードの上のメッセージ輸送システム（ MTS ）を保守することはしばしば非実用的である。
例えば、ワークステーションは、SMTP サーバー［ RFC821 ］を許可したり、ローカルなメール配達システムを維持したり、連続稼働するための十分なリソース（サイクル、ディスク・スペース）を持っていないかもしれない。
同様に、長い時間、個々のコンピュータをIP 様式のネットワークで相互に結び付ける状態に保つことは費用がかかる（か、あるいは不可能である）かもしれない。（ノードは「接続性」として知られているリソースに欠けている）
にもかかわらず、これらのより小さいノードの上にメールを管理することが可能であることはしばしば非常に便利であり、そして、それらはメール取り扱いのタスクを援助するためにしばしばユーザエージェント（ＵＡ）をサポートする。 この問題を解くために、 MTS 構成要素をサポートできるノードがこれらのそれほど能力を授けられていないノードに maildrop サービスを提供する。
The Post Office Protocol - Version 3 (POP3) は有効な方法でワークステーションに対し、動的にサーバーホストの上の maildrop へアクセスする事を許すように意図される。 通常、これはサーバーが持っているメールをワークステーションに 取り戻すことを許すために POP3 が使われることを意味する。
このメモでは、「クライアントホスト」は POP3 サービスを利用しているホストを示し、用語「サーバーホスト」は POP3 サービスを提供するホストを示す。
このメモでは、考え方と一貫した手順はここで公開されるけれども、クライアントホストがメールを輸送システムの中に入力する方法は明示しない：
クライアントホストの上のユーザエージェントがメッセージを輸送システムの中に入力することを望むとき、それはその中継ホストに SMTP 接続を確立する
（この 中継ホストはそうであり得た、しかしそうである必要がない、クライアントホストのための POP3 サーバーホスト）。
初めに、 TCP ポート110に対して聞くことで、サーバーホストは POP3 サービスを始める。 クライアントホストがサービスを利用することを望むとき、サーバーホストとの TCP 接続を確立する。 接続が確立されたとき、 POP3 サーバーは挨拶を送る。 接続が閉じられるか、あるいは中止されるまで、クライアントと POP3 サーバーは、 それから （それぞれが）コマンドと応答を交換する。
POP3コマンドは、キーワードと、1つ、あるいはそれ以上の後に続く引数によって成り立つ。
すべてのコマンドは CRLF 対によって終結される。
キーワードと引数は印字可能なASCII文字から成り立つ。
キーワードと引数はそれぞれシングルスペース文字で分割されている。 キーワードは長さ3あるいは4文字である。 それぞれの引数の長さは最高40文字である。
POP3 での回答はステータス表示部と、(ことによると追加の情報によって)後に続くキーワードから成り立つ。 すべての回答は CRLF 対によって終結される。
現在2つの状態標識がある：
肯定の("+OK")と否定の ("-ERR") である。
ある特定のコマンドに対する回答は複数行である。 下に明らかに示されるこれらのケースで、応答と CRLF の最初のラインを送った後に、どんな追加の行でも、それぞれ CRLF 対によって終結されて送られる。 レスポンスのすべての行が送られたとき、最終のラインが、 オクテット (10進コードで 046, ".") と CRLF が対にする終端から成り立って送られる。 もし複数行応答のラインが終端オクテットから始まるなら、応答のそのラインに終端オクテットを前接続することによって、ラインは「byte-stuff」される。
したがって複数行レスポンスは5つのオクテット「 CRLF.CRLF 」で終了させられる。
複数行応答を調べるとき、クライアントはラインが終端オクテットから始まるかどうか調べる。 もしそうであるなら、そしてもし CRLF 以外のオクテットが次に続くなら、ラインの最初のオクテット（終端オクテット）は取り外される。 もしそうであるなら、そしてもし CRLF がすぐに終了文字に続くならＰＯＰサーバーからのレスポンスは終了し、「 .CRLF 」を含んでいる行は複数行レスポンスの一部であると思われない。
POP3 セッションがその寿命の間に多くの状態を通って進行する。
TCP 接続が開かれ、 POP3 サーバーが書き出し文句を送った途端に、セッションはAUTHORIZATION状態に入る。 この状態で、クライアントは POP3 サーバーにそれ自分自身を身分証明しなくてはならない。 クライアントが正常に認証を受けた直後、サーバーはクライアントの maildrop と関連づけられたリソースを獲得する、そしてセッションはTRANSACTION状態に入る。 この状態で、クライアントは POP3 サーバー側に動作を求める。 クライアントが QUIT コマンドを出したとき、セッションは UPDATE 状態に入る。 この状態で、 POP3 サーバーは TRANSACTION 状態の間に得られたどんなリソースをも解放して、そして goodbye を言う。 TCP 接続はそれから閉じられる。
POP3 サーバーが不活発自動ログアウトタイマーを持っているかもしれない。 このようなタイマーは、少なくとも10分の持続時間を持たなければならない。 どんなコマンドの受領書でもクライアントからその間隔の間に自動ログアウトタイマーをリセットするのに十分であるべきである。 タイマーが期限が切れるとき、セッションは UPDATE 状態に入らない
サーバーは、いかなるメッセージも削除したり、クライアントに応答を送ったりしないで、 TCP 接続を閉じるべきである。
TCP 接続が POP3 クライアントによって開かれた途端に、 POP3 サーバーは1行の挨拶を発行する。 これは CRLF によって終了させられるどんなストリングでもあり得る。 例がそうであるかもしれない：
S: +OK POP3 server ready
この書き出し文句が POP3 答えであることに注意しなさい。 POP3 サーバーは常に書き出し文句として肯定応答をするべきである。
POP3 セッションは今 AUTHORIZATION 状態である。 クライアントは POP3 サーバーに自分自身を身分証明しなくてはならない。 これをする方法として、2つの可能な機構がこのドキュメントに記述されている。 USER と PASS コマンド組合わせと APOP コマンドである。 APOP コマンドはこのドキュメントに後述される。
USER と PASS コマンドを使って認証するためには、クライアントは最初に USER コマンドを出さなくてはならない。 もし POP3 サーバーが肯定的な状態インジケータ("+OK") を返答するなら 、それからクライアントは認証を完了する PASS コマンドを発行してもよいし、あるいはPOP3 セッションを終了させる QUIT コマンドを発行しても良い。 もし POP3 サーバーが否定的な状態インジケータ("-ERR") で USER コマンドに返答するなら、クライアントは新しい認証コマンドを出してもよいし、QUIT コマンドを出してもよい。
クライアントが PASS コマンドを出すとき、 POP3 サーバーはクライアントがアクセスを与えられるべきであるかどうか決定する USER と PASS コマンドから適切な maildrop まで引数対を使う。
POP3 サーバーは、いずれかの認証コマンドの使用を通して、クライアントに適切な maildrop へのアクセスを与えられるべきであると決定すると、 POP3サーバーは、セッションがUPDATE状態に入る前にメッセージが修正されたり削除されたりするのを防ぐためにmaildropに排他アクセスロックをかける。
もしロックがうまく習得されているなら、 POP3 サーバーは肯定的な状態インジケータで返答する。
POP3 セッションはすぐに、削除マークが付かない状態でTRANSACTION 状態に入る。
もし maildrop が何らかの理由（例えば、ロックが獲得されることができないとか、クライアントが適切な maildrop にアクセスを拒否されたとか、あるいは maildrop を解析することができない）のために開くことができなかった場合、 POP3 サーバーは否定的な状態インジケータを返答する。
（もし、ロックは獲得されたが、 POP3 サーバーが否定的な状態インジケータの返答を意図するなら、 POP3 サーバーはコマンドを拒絶してロックを放さなくてはならない ）
否定的な状態インジケータを返した後に、サーバーは接続を閉じてもよい。 もしサーバーが接続を閉じないなら、クライアントはあるいは新しい認証コマンドを出して再び始めてもよいし、QUIT コマンドを出してもよい。
POP3 サーバーは maildrop を開いた後、メッセージ 番号をそれぞれのメッセージに割り当てて、そしてオクテットでそれぞれのメッセージの大きさを指摘する。
maildrop でのファーストメッセージは「1」のメッセージ 番号を割り当てられる、第2は「2」を割り当てられる、つまり、 maildrop でのｎ番目の メッセージは「ｎ」のメッセージ番号を割り当てられる。 POP3 コマンドと回答で、すべてのメッセージ番号とメッセージサイズはベース - 10（すなわち、10進数）で表現される。
これまでのところ論じられた3つの POP3 コマンドのための要約が以下にある：
引数：
サーバーにだけ重要なメールボックスを識別している文字列(省略不可)
制限：
AUTHORIZATION 状態でPOP3 挨拶直後、もしくはUSER や PASS コマンドの失敗後にのみ使用可能
可能な回答：
+OK name is a valid mailbox -ERR never heard of mailbox name
事例：
C: USER mrose S: +OK mrose is a real hoopy frood ... C: USER frated S: -ERR sorry, no mailbox for frated here
引数：
サーバーメールボックス特定のパスワード(省略不可)
制限：
AUTHORIZATION 状態でUSERコマンド成功直後のみ可能
解説：
PASSコマンドは1つの引数しか持たないので、 POP3 サーバーがパスワードの一部として(引数セパレータである)スペースを扱ってもよい。
可能な回答：
+OK maildrop locked and ready -ERR invalid password -ERR unable to lock maildrop
事例：
C: USER mrose S: +OK mrose is a real hoopy frood C: PASS secret S: +OK mrose's maildrop has 2 messages (320 octets) ... C: USER mrose S: +OK mrose is a real hoopy frood C: PASS secret S: -ERR maildrop already locked
引数：
なし
制限：
なし
可能な回答：
+OK
事例：
C: QUIT S: +OK dewey POP3 server signing off
クライアントが POP3 サーバーに自分自身の認証を成功し、 POP3 サーバーが適切な maildrop をロックして、そして開いた途端に、 POP3 セッションは TRANSACTION 状態に入る。 その時、クライアントは繰り返して次の POP3 コマンドのいずれを出してもよい。 それぞれのコマンドの後に、 POP3 サーバーは応答を発行する。
最後に、クライアントはQUITコマンドを発行し、 POP3 セッションは UPDATE 状態に入る。
ここに TRANSACTION 状態で正当な POP3 コマンドがある：
引数：
なし
制限：
TRANSACTION 状態でのみ使用可能
解説：
POP3 サーバーは maildrop のための情報を含んでだ肯定応答を一行発行する。 この行は maildrop のための「ドロップリスト」と呼ばれる。
文の解析を簡単にするために、全てのPOP3 サーバーはドロップリストの為のフォーマットの使用を必要とされる。
それは、"+OK" と、後に続く一つのスペース、maildropの数、一つのスペース、maildropのoctet数から成る肯定応答である。 何が maildrop サイズの後に続くかについて、このメモは必要事項を作らない。
最低限の実装でも、CRLF 対で応答行をきちんと終わらせるべきである。
いっそう進歩した実装は、他の情報を含むかもしれない。
注釈：
このメモでは、実装にドロップリストで追加の情報を供給することを強く否定する。任意のクライアントが maildrop のメッセージを解析するのを許すかについて、他のオプション機能が後述されている。
削除マークが付いたメッセージは、どの合計でも数えられないことに注意を払いなさい。
可能な回答：
+OK nn mm
事例：
C: STAT S: +OK 2 320
引数：
メッセージ 番号（省略可）
削除マークが付いたメッセージを参照しない
制限：
TRANSACTION 状態でのみ使用可能
解説：
もし引数が与えられて、POP3サーバーが肯定応答を発行するなら、応答行はメッセージの情報を含んでいる。
この行はそのメッセージのために「スキャンリスト」と呼ばれる。
もし引数が与えられなくて、POP3サーバーが肯定応答を発行するなら、与えられた応答は複数行である。
最初の+OKの後に、それぞれのmaildropのメッセージに関してPOP3サーバーはメッセージのための情報を含んだ行を返答する。この行はそのメッセージのための「スキャンリスト」とも呼ばれる。
文の解析をすることを簡単にするために、すべてのPOP3サーバーはスキャンリストのためにあるフォーマットを使うように要求される。
‖スキャンリストが通り過ぎて追われたメッセージのメッセージ-数から成り立つ‖シングルスペースで印字するそしてオクテットでのメッセージの実寸‖。
スキャンリストは、メッセージの番号と、後に続くオクテットで表されるメッセージの実サイズで成立する。
スキャンリストでメッセージサイズの後に続くかについて、このメモは要求事項を作らない。最低限の実装でもCRLF対できちんと応答行を終了させるべきである。いっそう進歩した実装では、メッセージから解析されるように他の情報を含むかもしれない。注釈：
このメモは、実装にスキャンリストで追加の情報を供給することを強く否定する。 任意のクライアントが maildrop でメッセージを解析するのを許すかについて、他のオプション機能が後述されている。
削除マークが付いたメッセージがリストされないことに注意しなさい。
可能な回答：
+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 messages in maildrop
引数：
削除マークが付いていないメッセージ番号(省略不可)
制限：
TRANSACTION 状態でのみ使用可能
解説：
もし POP3 サーバーが肯定応答を発行するなら、与えられた応答は複数行である。 最初の +OK の後に、POP3 サーバーは、（すべての複数行回答と同じように）終了キャラクタをbyte-stuffするように気を使って、メッセージを所定のメッセージ番号に対応させる。
可能な回答：
+OK message follows -ERR no such message
事例：
C: RETR 1 S: +OK 120 octets S: S: .
引数：
削除マークが付いていないメッセージ番号(省略不可)
制限：
TRANSACTION 状態でのみ使用可能
解説：
削除したように POP3 サーバーはメッセージにマークを付ける。 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
引数：
なし
制限：
TRANSACTION 状態でのみ使用可能
解説：
POP3 サーバーは何もせず、ただ肯定応答で答える。
可能な回答：
+OK 事例： C: NOOP S: +OK
引数：
なし
制限：
TRANSACTION 状態でのみ使用可能
解説：
もしメッセージが POP3 サーバーによって削除マークが付いていたなら、それらはマークが外される。 POP3 サーバーは肯定応答でそれから返事する。
可能な回答：
+OK
事例：
C: RSET S: +OK maildrop has 2 messages (320 octets)
クライアントが TRANSACTION 状態から QUIT コマンドを出すとき、 POP3 セッションは UPDATE 状態に入る。 （もしクライアントが AUTHORIZATION 状態から QUIT コマンドを出すなら、 POP3 セッションが終わるが、 UPDATE 状態に入らないことに注意しなさい。）
もしセッションがクライアントによって出された QUIT コマンド以外に何らかの理由で終わるなら、 POP3 セッションは UPDATE 状態に入らない、そして maildrop からのメッセージを削除してはならない。
引数：
なし
制限：
なし
解説：
POP3 サーバーは削除にマークが付いたすべてのメッセージを maildrop から取り除く。 (要修正)それはこれらのオペレーションの状況について maildrop と答えの上にそれからどんな排除アクセスロックでもリリースする。 TCP 接続はそれから閉じられる。
可能な回答：
+OK
事例：
C: QUIT S: +OK dewey POP3 server signing off (maildrop empty) ... C: QUIT S: +OK dewey POP3 server signing off (2 messages left) ...
上に論じた POP3コマンド は POP3 サーバーのすべての最低限の実装でサポートされなくてはならない。
単純な POP3 サーバー実装を維持した上で、下に記述された任意の POP3 コマンドはメッセージ通信で POP3 クライアントにもっと素晴らしい自由度を許可する。
注釈：
拡張されたドロップリストとスキャンリストを開発する代わりに、このメモはこれらのコマンドをサポートするために強く実装を奨励する。 要するに、このメモでは、知能は POP3 サーバーではなく POP3 クライアントの方に入れるべきと考える。
引数：
msg=削除マークの付いていないメッセージ番号(省略不可)
n=非負数(省略不可)
制限：
TRANSACTION 状態でのみ使用可能
解説：
もし POP3 サーバーが肯定応答を発行するなら、与えられたレスポンスは複数行である。 最初の +OK の後に、POP3 サーバーは、メッセージのヘッダーを送り、次にヘッダーと本体を分離する空行、それから指定された行数分のメッセージ本体を送る。
（すべての複数行回答と同じように）終了キャラクタをbyte-stuffするように気を使いなさい。
もし 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
引数：
削除マークの付いていないメッセージ番号(省略可)
制限：
TRANSACTION状態でのみ使用可能
解説：
もし引数が与えられていて、 POP3 サーバーがそのメッセージの情報を含んでいる肯定応答を発行するなら、この行はそのメッセージのために「ユニークな id のリスト」と呼ばれる。
もし引数が与えられなくて、 POP3 サーバーが肯定応答を発行するなら、与えられた応答は複数行である。 最初の +OK の後に、maildropのそれぞれのメッセージについて、 POP3 サーバーはメッセージの情報を含んだ行を返答する。
この行はメッセージのための「ユニークな id のリスト」と呼ばれる。
文の解析をすることを簡単にするために、すべての POP3 サーバーはユニークな id のリストのためにあるフォーマットを使うように要求される。
ユニークな id のリストは、メッセージ番号と後に続くシングルスペース、そしてユニークなidによって成り立つ。
ユニークな id のリストでユニークな id の後に情報は続かない。
メッセージのユニークな id は 0x21から0x7Eの間の文字で成立する、任意のサーバーによって決定された文字列であり、 maildrop の中でユニークにメッセージを識別し、また、、セッションをも越えて持続する。
サーバーは決して所定の maildrop でユニークな id を再利用するべきではない。なぜなら実体と同じぐらい長い間ユニークな id の存在は使用されるからである。
削除マークが付いたメッセージがリストされないことに注意を払いなさい。
可能な回答：
+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
引数：
メールボックスを識別している文字列(省略不可)
MD5 要約文字列(省略不可)
制限：
AUTHORIZATION 状態でPOP3 挨拶の後にのみ使用可能
解説：
通常、 POP3 セッションは USER/PASS交換から始める。 これはサーバー / ユーザ - id の特定のパスワードがネットワークの上に平文で送られるという結果を生じる。 POP3 の断続的な使用にとって、これはかなり大きい危険をもたらさしかねない。 しかしながら、多くの POP3 クライアントは、 新しいメールを調べるために 定期的なPOP3 サーバー接続を繰り返す。 さらにセッション起動の間隔は5分であるかもしれない。 それ故、パスワード盗難の危険は大いに高められている。
起点認証と再生防護両方のために、供給する認証の代わりの方法が必要とされるが、それにはネットワークの上に平文でパスワードを送らない必要がある。 APOP コマンドはこの機能性を提供する。
APOP コマンドを実行する POP3 サーバーはその見出し挨拶にタイムスタンプを含めるであろう。 ［ RFC822 ］に記述される `msg-id' に対応するタイムスタンプの文法で 、 POP3 サーバーが見出し挨拶を公表するたびに、異なっていなければならない。 例えば、別のＵＮＩＸプロセスが POP3 サーバーのそれぞれの事例のために使われるＵＮＩＸ実装で、タイムスタンプの文法はそうであるかもしれない：
「プロセスＩＤ」は１０進数値であるプロセスの PID 、10進数値のシステム時間、 POP3 サーバーが走っているホストに対応する完全に修飾されたドメイン名である。
POP3 クライアントは、このタイムスタンプを書き留めて、それから APOP コマンドを発行する。 「name」パラメータは USER コマンドの「name」パラメータと同一の意味を持っている。
「digest」パラメータは、共有された秘密をMD5 アルゴリズム［ RFC1321 ］を用い、（かぎ括弧を含めた）タイムスタンプ文字列に適用することによって計算される。 この共有された秘密は POP3 クライアントとサーバーにだけ知られている文字列である。
秘密の知識がどんな実体にでも成功裏に名前をつけられたユーザとしてふりをすることを許すであろう（とき・から・につれて・ように）、大きい注意が秘密の無許可の公表を妨げるためにとられるべきである。
秘密を知るいかなる個体も正規利用者になりすますことができるので、秘密の流出を防ぐ細心の注意が必要である。
「digest」パラメータ自身は、小文字のASCII文字を使って16進法のフォーマットで送られる16オクテットの値である。
POP3 サーバーが APOP コマンドを受け取ると、提供されたdigestを照合する。 もしdigestが正しければ、 POP3 サーバーは肯定応答を発行し、 POP3 セッションはTRANSACTION状態に入る。 さもなければ、否定応答が発令され、 POP3 セッションはAUTHORIZATION状態のままでいる。
共有された秘密の長さが長ければ、より盗み出すことが困難になることを覚えておきなさい。だから、共有された秘密は（かなり下に示される8文字の例よりも）長い文字列であるべきである。
可能な回答 :
+OK maildrop locked and ready -ERR permission denied
事例：
S: +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us> C: APOP mrose c4c9334bac560ecc979e58001b3e22fb S: +OK maildrop has 1 message (369 octets)
この例で、共有された秘密は文字列 `tanstaaf' である。
<1896.697170952@dbc.mtview.ca.us>tanstaaf
上記文字列をMD5 アルゴリズムに適用する事により、下記に示されるdigest値を作り出す。
c4c9334bac560ecc979e58001b3e22fb
USER name AUTHORIZATION 状態で有効 PASS string QUIT
STAT TRANSACTION 状態で有効 LIST [msg] RETR msg DELE msg NOOP RSET
QUIT UPDATE 状態で有効である
APOP name digest AUTHORIZATION 状態で有効である TOP msg n TRANSACTION 状態で有効である UIDL [msg]
+OK -ERR
STAT 、 LIST と UIDL コマンドを例外として、 POP3 サーバーによって与えられた、いかなるコマンドの応答についても、答えが "+OK" と "-ERR" だけが重要であることに注意を払いなさい。 この応答の後に発生しているどんなテキストもクライアントによって無視されるかもしれない。
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:
POP3 セッションの間に伝達されたすべてのメッセージはインターネットテキストメッセージのフォーマット［ RFC822 ］の標準に従うと仮定する。
サーバーホスト上にあるメッセージのオクテット数と、メッセージに割り当てられたオクテット数が、「行末」を示すローカルな規則のために違うかもしれないことに注意しなければいけない。
通常、 POP3 セッションの AUTHORIZATION 状態の間にmaildrop を開くとき、 POP3 サーバーはオクテットでそれぞれのメッセージの大きさを計算することができる。
例えば、もし POP3 サーバーホストが内部で、「行末」を単一キャラクタであるとして表現していても、 POP3 サーバーは単純にメッセージ中のそれぞれのこの文字を2オクテットと数える。
メッセージ行が終端オクテットで開始する時、POP3クライアントが複数行応答の受け取り時に、クライアント側が全ての byte-stuffされた終了キャラクタを取り除くであろうから、(サーバー側は)二度数えてはならない。
[RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC821, 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.
APOP コマンドの使用が POP3 セッションに出発地識別と繰り返し保護を提供すると推測される。
したがって、 PASS と APOP コマンド両方を実行する POP3 サーバーが両方の所定のユーザのためのアクセスの方法を許してはならない；すなわち、所定の "USER name" のためにあるいは PASS あるいは APOP コマンドが許される、しかし両方ともではない。
さらに、それを共有された秘密の増加の期間であると指摘しなさい、それを引き出すことについての困難もそうする。
USER コマンドに -ERR と答えるサーバーが潜在的な攻撃者に名前が正当である手がかりを与えている
PASS コマンドの使用が平文のパスワードをネットワークの上に送る。
RETR と TOP のコマンドの使用が問題なしのメールをネットワークの上に送る。
他の点では、セキュリティ問題はこのメモで論じられない。
ＰＯＰファミリーは長く、そして変化に富んだ履歴を持っている。 RFC1460 に主にマイナーな改訂であるけれども、 POP3 は RFCs 918, 937, and 1081 で提出された観念に基づいている。
加えるに、 Alfred Grimstad 、 Keith McCloghrie と Neil Ostroff は APOP コマンドについての重要なコメントを提供した。
ジョン・Ｇ・マイヤース カーネギー・メロン大学 5000フォーブス通り ピッツバーグ、ＰＡ、15213 E-Mail ： jgm+@cmu.edu マーシャル・Ｔ・ローズ ドーバービーチコンサルティング社。 420 Whisman コート マウンテンビュー、ＣＡ、94043 - 2186 E-Mail ： mrose@dbc.mtview.ca.us