RFC1939 日本語訳
1939 Post Office Protocol - Version 3. J. Myers, M. Rose. May 1996. (Format: TXT=47018 bytes) (Obsoletes RFC1725) (Updated by RFC1957, RFC2449) (Also STD0053) (Status: STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
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
コメントを求めるワーキンググループJ.マイアーズの要求をネットワークでつないでください: 1939カーネギーメロンSTD: 53 M.ローズは以下を時代遅れにします。 1725年のドーヴァービーチコンサルティングInc.カテゴリ: 標準化過程1996年5月
Post Office Protocol - Version 3
POP--バージョン3
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Table of Contents
目次
1. Introduction ................................................ 2
2. A Short Digression .......................................... 2
3. Basic Operation ............................................. 3
4. The AUTHORIZATION State ..................................... 4
QUIT Command ................................................ 5
5. The TRANSACTION State ....................................... 5
STAT Command ................................................ 6
LIST Command ................................................ 6
RETR Command ................................................ 8
DELE Command ................................................ 8
NOOP Command ................................................ 9
RSET Command ................................................ 9
6. The UPDATE State ............................................ 10
QUIT Command ................................................ 10
7. Optional POP3 Commands ...................................... 11
TOP Command ................................................. 11
UIDL Command ................................................ 12
USER Command ................................................ 13
PASS Command ................................................ 14
APOP Command ................................................ 15
8. Scaling and Operational Considerations ...................... 16
9. POP3 Command Summary ........................................ 18
10. Example POP3 Session ....................................... 19
11. Message Format ............................................. 19
12. References ................................................. 20
13. Security Considerations .................................... 20
14. Acknowledgements ........................................... 20
15. Authors' Addresses ......................................... 21
Appendix A. Differences from RFC 1725 .......................... 22
1. 序論… 2 2. 短い脱線… 2 3. 基本的な操作… 3 4. 承認状態… 4 コマンドをやめてください… 5 5. トランザクション状態… 5 スタットコマンド… 6 コマンドを記載してください… 6 RETRは命令します… 8 DELEは命令します… 8 NOOPは命令します… 9 RSETは命令します… 9 6. アップデート状態… 10 コマンドをやめてください… 10 7. 任意のPOP3は命令します… 11はコマンドを上回っています… 11 UIDLは命令します… 12 ユーザコマンド… 13 コマンドに合格してください… 14 APOPは命令します… 15 8. 比例していて操作上の問題… 16 9. POP3は概要を命令します… 18 10. 例のPOP3セッション… 19 11. メッセージ形式… 19 12. 参照… 20 13. セキュリティ問題… 20 14. 承認… 20 15. 作者のアドレス… 21 RFC1725からの付録A.差… 22
Myers & Rose Standards Track [Page 1] RFC 1939 POP3 May 1996
マイアーズとバラ標準化過程[1ページ]RFC1939POP3 May 1996
Appendix B. Command Index ...................................... 23
付録B.コマンド索引… 23
1. Introduction
1. 序論
On certain types of smaller nodes in the Internet it is often impractical to maintain a message transport system (MTS). For example, a workstation may not have sufficient resources (cycles, disk space) in order to permit a SMTP server [RFC821] and associated local mail delivery system to be kept resident and continuously running. Similarly, it may be expensive (or impossible) to keep a personal computer interconnected to an IP-style network for long amounts of time (the node is lacking the resource known as "connectivity").
インターネットのあるタイプの、より小さいノードでは、メッセージ輸送システム(MTS)を維持するのはしばしば非実用的です。 例えば、ワークステーションには十分なリソース(サイクル、椎間腔)が、SMTPサーバー[RFC821]と関連ローカルの郵便配達システムが居住しているように保たれて、絶え間なく動いていることを許可するためにないかもしれません。 同様に、長い量の時間のIP-スタイルネットワークとパーソナルコンピュータとインタコネクトし続けるのは、高価、そして、(不可能。)であるかもしれません(ノードは「接続性」として知られているリソースを欠いています)。
Despite this, it is often very useful to be able to manage mail on these smaller nodes, and they often support a user agent (UA) to aid the tasks of mail handling. To solve this problem, a node which can support an MTS entity offers a maildrop service to these less endowed nodes. The Post Office Protocol - Version 3 (POP3) is intended to permit a workstation to dynamically access a maildrop on a server host in a useful fashion. Usually, this means that the POP3 protocol is used to allow a workstation to retrieve mail that the server is holding for it.
これにもかかわらず、これらのより小さいノードに関するメールに対処できるのがしばしば非常に役に立って、それらは、メール取り扱いに関するタスクを支援するためにしばしばユーザエージェント(UA)をサポートします。 この問題、MTS実体が申し出であることを支えることができるノードを解決するために、郵便受けサービスはそれほどノードをこれらに授けませんでした。 ポスト紙オフィスプロトコル--バージョン3(POP3)が、役に立つファッションでワークステーションがサーバー・ホストの上でダイナミックに郵便受けにアクセスすることを許可することを意図します。 通常、これは、POP3プロトコルがワークステーションがサーバがそれのために保持しているメールを検索するのを許容するのに使用されることを意味します。
POP3 is not intended to provide extensive manipulation operations of mail on the server; normally, mail is downloaded and then deleted. A more advanced (and complex) protocol, IMAP4, is discussed in [RFC1730].
POP3がサーバにおけるメールの大規模な操作操作を提供することを意図しません。 通常、メールは、ダウンロードされて、次に、削除されます。 [RFC1730]でより多くの高度で(複雑)のプロトコル(IMAP4)について議論します。
For the remainder of this memo, the term "client host" refers to a host making use of the POP3 service, while the term "server host" refers to a host which offers the POP3 service.
このメモの残りについて、「クライアントホスト」という用語はPOP3サービスを利用するホストについて言及します、「サーバー・ホスト」という用語はPOP3がそれの申し出を修理するホストについて言及しますが。
2. A Short Digression
2. 短い脱線
This memo does not specify how a client host enters mail into the transport system, although a method consistent with the philosophy of this memo is presented here:
このメモはクライアントホストがどうメールを輸送システムに入力するかを指定しません、このメモの哲学と一致したメソッドがここに提示されますが:
When the user agent on a client host wishes to enter a message
into the transport system, it establishes an SMTP connection to
its relay host and sends all mail to it. This relay host could
be, but need not be, the POP3 server host for the client host. Of
course, the relay host must accept mail for delivery to arbitrary
recipient addresses, that functionality is not required of all
SMTP servers.
クライアントホストの上のユーザエージェントがメッセージを輸送システムに入力したがっているとき、それは、SMTP接続を中継ホストに確立して、すべてのメールをそれに送ります。 ある必要はないのを除いて、この中継ホストはクライアントホストのためのPOP3サーバー・ホストであるかもしれません。 もちろん、中継ホストは任意の受取人アドレスに配送のためのメールを受け入れなければならなくて、すべてのSMTPサーバーがその機能性に要求されるというわけではありません。
Myers & Rose Standards Track [Page 2] RFC 1939 POP3 May 1996
マイアーズとバラ標準化過程[2ページ]RFC1939POP3 May 1996
3. Basic Operation
3. 基本的な操作
Initially, the server host starts the POP3 service by listening on TCP port 110. When a client host wishes to make use of the service, it establishes a TCP connection with the server host. When the connection is established, the POP3 server sends a greeting. The client and POP3 server then exchange commands and responses (respectively) until the connection is closed or aborted.
初めは、サーバー・ホストは、TCPポート110の上で聴くことによって、POP3サービスを始めます。 クライアントホストがサービスを利用したがっているとき、それはサーバー・ホストとのTCP接続を確立します。 接続が確立されるとき、POP3サーバは挨拶を送ります。 そして、接続が閉店するか、または中止されるまで、クライアントとPOP3サーバはコマンドと応答(それぞれ)を交換します。
Commands in the POP3 consist of a case-insensitive keyword, possibly followed by one or more arguments. All commands are terminated by a CRLF pair. Keywords and arguments consist of printable ASCII characters. Keywords and arguments are each separated by a single SPACE character. Keywords are three or four characters long. Each argument may be up to 40 characters long.
POP3のコマンドは1つ以上の議論がことによるとあとに続いた大文字と小文字を区別しないキーワードから成ります。 すべてのコマンドがCRLF組によって終えられます。 キーワードと議論は印刷可能なASCII文字から成ります。 キーワードと議論は単独のSPACEキャラクタによってそれぞれ切り離されます。 長い間、キーワードは3か4つのキャラクタです。 長い間、各議論は最大40のキャラクタであるかもしれません。
Responses in the POP3 consist of a status indicator and a keyword
possibly followed by additional information. All responses are
terminated by a CRLF pair. Responses may be up to 512 characters
long, including the terminating CRLF. There are currently two status
indicators: positive ("+OK") and negative ("-ERR"). Servers MUST
send the "+OK" and "-ERR" in upper case.
POP3の応答は追加情報がことによるとあとに続いた自動運転表示灯とキーワードから成ります。 すべての応答がCRLF組によって終えられます。 終わっているCRLFを含んでいて、長い間、応答は最大512のキャラクタであるかもしれません。 現在、2つの自動運転表示灯があります: 積極的であって(「+ OK」)、否定的です(「-間違えてください」)。 「サーバは」 + 」 大文字におけるOKの「間違えてください」を送らなければなりません。
Responses to certain commands are multi-line. In these cases, which are clearly indicated below, after sending the first line of the response and a CRLF, any additional lines are sent, each terminated by a CRLF pair. When all lines of the response have been sent, a final line is sent, consisting of a termination octet (decimal code 046, ".") and a CRLF pair. If any line of the multi-line response begins with the termination octet, the line is "byte-stuffed" by pre-pending the termination octet to that line of the response. Hence a multi-line response is terminated with the five octets "CRLF.CRLF". When examining a multi-line response, the client checks to see if the line begins with the termination octet. If so and if octets other than CRLF follow, the first octet of the line (the termination octet) is stripped away. If so and if CRLF immediately follows the termination character, then the response from the POP server is ended and the line containing ".CRLF" is not considered part of the multi-line response.
あるコマンドへの応答はマルチ系列です。 これらの場合では、どんな追加系列も送ります、CRLF組によって終えられたそれぞれ。(応答とCRLFの最初の系列を送った後に、場合は以下で明確に示されます)。 応答のすべての系列を送ったとき、最終的な系列を送ります、終了八重奏から成って。「(小数が046をインチコード化する、」、)、そして、CRLF組。 何かマルチ系列応答の系列が終了八重奏で始まるなら、系列は未定プレ応答のその系列への終了八重奏で「バイトで、詰められます」。 したがって、マルチ系列応答は5つの八重奏"CRLF.CRLF"と共に終えられます。 マルチ系列応答を調べるとき、クライアントは、系列が終了八重奏で始まるかどうか確認するためにチェックします。 そうだとすれば、CRLF以外の八重奏が続くなら、系列(終了八重奏)の最初の八重奏ははがれます。 そうだとすれば、CRLFがすぐに行終了文字に続くなら、POPサーバからの応答は終わります、そして、".CRLF"を含む系列はマルチ系列応答の一部であると考えられません。
A POP3 session progresses through a number of states during its lifetime. Once the TCP connection has been opened and the POP3 server has sent the greeting, the session enters the AUTHORIZATION state. In this state, the client must identify itself to the POP3 server. Once the client has successfully done this, the server acquires resources associated with the client's maildrop, and the session enters the TRANSACTION state. In this state, the client requests actions on the part of the POP3 server. When the client has
POP3セッションは生涯多くの州を通って進歩をします。 いったんTCP接続が開かれて、POP3サーバが挨拶を送ると、セッションはAUTHORIZATION状態に入ります。 この状態では、クライアントはPOP3サーバに身元を明らかにしなければなりません。クライアントがいったん首尾よくこれをすると、サーバはクライアントの郵便受けに関連しているリソースを取得します、そして、セッションはTRANSACTION状態に入力します。 この状態では、クライアントがPOP3サーバ側の動作を要求する、クライアントはそうしました。
Myers & Rose Standards Track [Page 3] RFC 1939 POP3 May 1996
マイアーズとバラ標準化過程[3ページ]RFC1939POP3 May 1996
issued the QUIT command, the session enters the UPDATE state. In this state, the POP3 server releases any resources acquired during the TRANSACTION state and says goodbye. The TCP connection is then closed.
QUITコマンドを発行して、セッションはUPDATE状態に入ります。 この状態では、POP3サーバは、TRANSACTION状態の間に取得されたどんなリソースも発表して、さようならを言います。 そして、TCP接続は閉店します。
A server MUST respond to an unrecognized, unimplemented, or syntactically invalid command by responding with a negative status indicator. A server MUST respond to a command issued when the session is in an incorrect state by responding with a negative status indicator. There is no general method for a client to distinguish between a server which does not implement an optional command and a server which is unwilling or unable to process the command.
サーバは、否定的自動運転表示灯で応じることによって、認識されていないか、非実装しているか、シンタクス上無効のコマンドに反応しなければなりません。 サーバはセッションが不正確な状態に否定的自動運転表示灯で応じることによってあるとき発行されたコマンドに反応しなければなりません。 クライアントが任意のコマンドを実装しないサーバと不本意であるか、またはコマンドを処理できないサーバを見分けるどんな一般的なメソッドもありません。
A POP3 server MAY have an inactivity autologout timer. Such a timer MUST be of at least 10 minutes' duration. The receipt of any command from the client during that interval should suffice to reset the autologout timer. When the timer expires, the session does NOT enter the UPDATE state--the server should close the TCP connection without removing any messages or sending any response to the client.
POP3サーバには、不活発自動ログアウト・タイマーがあるかもしれません。 そのようなタイマは少なくとも10分の持続時間のものであるに違いありません。 その間隔の間のクライアントからのどんなコマンドの領収書も、自動ログアウト・タイマーをリセットするために十分であるはずです。 タイマが期限が切れる場合、セッションはUPDATE状態に入りません--どんなメッセージも取り除くか、またはどんな応答もクライアントに送らないで、サーバはTCP接続を終えるべきです。
4. The AUTHORIZATION State
4. 承認状態
Once the TCP connection has been opened by a POP3 client, the POP3 server issues a one line greeting. This can be any positive response. An example might be:
TCP接続がPOP3クライアントによっていったん開かれると、POP3サーバは1つの系列挨拶を発行します。 これはどんな積極的な応答であるかもしれません。 例は以下の通りです。
S: +OK POP3 server ready
S: +OK POP3サーバ準備ができています。
The POP3 session is now in the AUTHORIZATION state. The client must now identify and authenticate itself to the POP3 server. Two possible mechanisms for doing this are described in this document, the USER and PASS command combination and the APOP command. Both mechanisms are described later in this document. Additional authentication mechanisms are described in [RFC1734]. While there is no single authentication mechanism that is required of all POP3 servers, a POP3 server must of course support at least one authentication mechanism.
POP3セッションが現在、AUTHORIZATION状態にあります。 クライアントは、現在、POP3サーバにそれ自体を特定して、認証しなければなりません。これをするための2台の可能なメカニズムがこのドキュメント、USER、PASSコマンド組み合わせ、およびAPOPコマンドで説明されます。 両方のメカニズムは後で本書では説明されます。 追加認証機構は[RFC1734]で説明されます。 すべてのPOP3サーバが要求されるどんなただ一つの認証機構もない間、POP3サーバはもちろん少なくとも1台の認証機構をサポートしなければなりません。
Once the POP3 server has determined through the use of any authentication command that the client should be given access to the appropriate maildrop, the POP3 server then acquires an exclusive- access lock on the maildrop, as necessary to prevent messages from being modified or removed before the session enters the UPDATE state. If the lock is successfully acquired, the POP3 server responds with a positive status indicator. The POP3 session now enters the TRANSACTION state, with no messages marked as deleted. If the maildrop cannot be opened for some reason (for example, a lock can not be acquired, the client is denied access to the appropriate
一度、POP3サーバは、適切な郵便受けへのアクセスをクライアントに与えるべきであり、次に、POP3サーバがセッションがUPDATE状態に入る前に、メッセージが変更されるか、または取り除かれるのを防ぐために必要に応じて郵便受けで排他的なアクセス錠を入手することをどんな認証コマンドの使用目的でも決定したことがあります。 首尾よく錠を入手するなら、POP3サーバは陽性反応インディケータで反応します。 POP3セッションは今、削除されるようにマークされたメッセージなしでTRANSACTION状態に入ります。 郵便受けがそうすることができないなら、ある理由で開けてください。(例えば、錠を入手できない、適切へのアクセスはクライアントに拒絶されます。
Myers & Rose Standards Track [Page 4] RFC 1939 POP3 May 1996
マイアーズとバラ標準化過程[4ページ]RFC1939POP3 May 1996
maildrop, or the maildrop cannot be parsed), the POP3 server responds with a negative status indicator. (If a lock was acquired but the POP3 server intends to respond with a negative status indicator, the POP3 server must release the lock prior to rejecting the command.) After returning a negative status indicator, the server may close the connection. If the server does not close the connection, the client may either issue a new authentication command and start again, or the client may issue the QUIT command.
郵便受け、郵便受けを分析できない、)、POP3サーバは否定的自動運転表示灯で反応します。 (錠を入手しましたが、POP3サーバが否定的自動運転表示灯で応じるつもりであるなら、コマンドを拒絶する前に、POP3サーバは錠をリリースしなければなりません。) 否定的自動運転表示灯を返した後に、サーバは接続を終えるかもしれません。 サーバが接続を終えないなら、クライアントが、新しい認証コマンドを発行して、再開するかもしれませんか、またはクライアントはQUITコマンドを発行するかもしれません。
After the POP3 server has opened the maildrop, it assigns a message- number to each message, and notes the size of each message in octets. The first message in the maildrop is assigned a message-number of "1", the second is assigned "2", and so on, so that the nth message in a maildrop is assigned a message-number of "n". In POP3 commands and responses, all message-numbers and message sizes are expressed in base-10 (i.e., decimal).
POP3サーバが郵便受けを開いた後に、それは、メッセージ番号を各メッセージに割り当てて、八重奏における、それぞれのメッセージのサイズに注意します。 メッセージ番号が郵便受けにおける最初のメッセージに割り当てられる、「1インチ、「2インチ、などに、「n」のメッセージ番号は郵便受けでn番目が通信させるそうに割り当てられること」が2番目に割り当てられます。 POP3コマンドと応答では、すべてのメッセージ番号とメッセージサイズはベース-10(すなわち、10進の)で表されます。
Here is the summary for the QUIT command when used in the AUTHORIZATION state:
ここに、AUTHORIZATION状態で使用されると、QUITコマンドのための概要があります:
QUIT
やめてください。
Arguments: none
議論: なし
Restrictions: none
制限: なし
Possible Responses:
+OK
可能な応答: + OK
Examples:
C: QUIT
S: +OK dewey POP3 server signing off
例: C: Sをやめてください: + サインオフするOK dewey POP3サーバ
5. The TRANSACTION State
5. トランザクション状態
Once the client has successfully identified itself to the POP3 server and the POP3 server has locked and opened the appropriate maildrop, the POP3 session is now in the TRANSACTION state. The client may now issue any of the following POP3 commands repeatedly. After each command, the POP3 server issues a response. Eventually, the client issues the QUIT command and the POP3 session enters the UPDATE state.
クライアントが首尾よくPOP3サーバに身元を明らかにして、POP3サーバがいったん適切な郵便受けをロックして、開くと、POP3セッションが現在、TRANSACTION状態にあります。 クライアントは現在、繰り返して以下のPOP3コマンドのいずれも発行するかもしれません。 各コマンドの後に、POP3サーバは応答を発行します。 結局、クライアントはQUITコマンドを発行します、そして、POP3セッションはUPDATE状態に入力します。
Myers & Rose Standards Track [Page 5] RFC 1939 POP3 May 1996
マイアーズとバラ標準化過程[5ページ]RFC1939POP3 May 1996
Here are the POP3 commands valid in the TRANSACTION state:
ここに、TRANSACTION状態で有効なPOP3コマンドがあります:
STAT
スタット
Arguments: none
議論: なし
Restrictions:
may only be given in the TRANSACTION state
制限: TRANSACTION状態で与えるだけであるかもしれません。
Discussion:
The POP3 server issues a positive response with a line
containing information for the maildrop. This line is
called a "drop listing" for that maildrop.
議論: POP3サーバは系列が郵便受けのための情報を含んでいる積極的な応答を発行します。 この系列はその郵便受けのために「低下リスト」と呼ばれます。
In order to simplify parsing, all POP3 servers are
required to use a certain format for drop listings. The
positive response consists of "+OK" followed by a single
space, the number of messages in the maildrop, a single
space, and the size of the maildrop in octets. This memo
makes no requirement on what follows the maildrop size.
Minimal implementations should just end that line of the
response with a CRLF pair. More advanced implementations
may include other information.
構文解析を簡素化するために、すべてのPOP3サーバが低下リストに、ある形式を使用するのに必要です。 シングルスペース、郵便受けにおける、メッセージの数、シングルスペース、および八重奏における、郵便受けのサイズに従って、「積極的な応答は」 +からOKに成ること」が続きました。 このメモは郵便受けサイズに続くことに要件を全く作りません。 最小限の器具はCRLF組と共に応答のその系列をただ終わらせるべきです。 より高度な実装は他の情報を含むかもしれません。
NOTE: This memo STRONGLY discourages implementations
from supplying additional information in the drop
listing. Other, optional, facilities are discussed
later on which permit the client to parse the messages
in the maildrop.
以下に注意してください。 このメモSTRONGLYは、実装が低下リストで追加情報を提供するのを思いとどまります。 後で他の、そして、任意の施設について議論します(クライアントが郵便受けにおけるメッセージを分析することを許可します)。
Note that messages marked as deleted are not counted in
either total.
削除されるようにマークされたメッセージがどちらの合計でも数えられないことに注意してください。
Possible Responses:
+OK nn mm
可能な応答: + OK nn mm
Examples:
C: STAT
S: +OK 2 320
例: C: スタットS: + OK2 320
LIST [msg]
リスト[msg]
Arguments:
a message-number (optional), which, if present, may NOT
refer to a message marked as deleted
議論: メッセージ番号(任意の)。(存在しているなら、そのメッセージ番号は削除されるようにマークされたメッセージを示さないかもしれません)。
Myers & Rose Standards Track [Page 6] RFC 1939 POP3 May 1996
マイアーズとバラ標準化過程[6ページ]RFC1939POP3 May 1996
Restrictions:
may only be given in the TRANSACTION state
制限: TRANSACTION状態で与えるだけであるかもしれません。
Discussion:
If an argument was given and the POP3 server issues a
positive response with a line containing information for
that message. This line is called a "scan listing" for
that message.
議論: 議論が与えてPOP3であったなら、サーバは系列がそのメッセージのための情報を含んでいる積極的な応答を発行します。 この系列はそのメッセージのために「スキャンリスト」と呼ばれます。
If no argument was given and the POP3 server issues a
positive response, then the response given is multi-line.
After the initial +OK, for each message in the maildrop,
the POP3 server responds with a line containing
information for that message. This line is also called a
"scan listing" for that message. If there are no
messages in the maildrop, then the POP3 server responds
with no scan listings--it issues a positive response
followed by a line containing a termination octet and a
CRLF pair.
議論を全く与えないで、POP3サーバが積極的な応答を発行して、次に、与えられた応答がマルチ系列であるなら。 初期かOKだったことの後に、郵便受けにおける各メッセージに関して、系列がそのメッセージのための情報を含んでいて、POP3サーバは反応します。 また、この系列はそのメッセージのために「スキャンリスト」と呼ばれます。 郵便受けにメッセージが全くなければ、POP3サーバはスキャンリストなしで反応します--それは終了八重奏を含む系列とCRLF組によって後をつけられた積極的な応答を発行します。
In order to simplify parsing, all POP3 servers are
required to use a certain format for scan listings. A
scan listing consists of the message-number of the
message, followed by a single space and the exact size of
the message in octets. Methods for calculating the exact
size of the message are described in the "Message Format"
section below. This memo makes no requirement on what
follows the message size in the scan listing. Minimal
implementations should just end that line of the response
with a CRLF pair. More advanced implementations may
include other information, as parsed from the message.
構文解析を簡素化するために、すべてのPOP3サーバがスキャンリストに、ある形式を使用するのに必要です。 スキャンリストはシングルスペースがあとに続いたメッセージのメッセージ番号と八重奏における、メッセージの実寸から成ります。 メッセージの実寸について計算するためのメソッドは下の「メッセージ・フォーマット」セクションで説明されます。 このメモはスキャンリストでメッセージサイズに続くことに要件を全く作りません。 最小限の器具はCRLF組と共に応答のその系列をただ終わらせるべきです。 より高度な実装はメッセージから分析されるように他の情報を含むかもしれません。
NOTE: This memo STRONGLY discourages implementations
from supplying additional information in the scan
listing. Other, optional, facilities are discussed
later on which permit the client to parse the messages
in the maildrop.
以下に注意してください。 このメモSTRONGLYは、実装がスキャンリストで追加情報を提供するのを思いとどまります。 後で他の、そして、任意の施設について議論します(クライアントが郵便受けにおけるメッセージを分析することを許可します)。
Note that messages marked as deleted are not listed.
削除されるようにマークされたメッセージが記載されていないことに注意してください。
Possible Responses:
+OK scan listing follows
-ERR no such message
可能な応答: + OKスキャンリストはそのようなものが通信させる-ERRノー、に従います。
Examples:
C: LIST
S: +OK 2 messages (320 octets)
S: 1 120
例: C: リストS: + OK2つのメッセージ(320の八重奏)S: 1 120
Myers & Rose Standards Track [Page 7] RFC 1939 POP3 May 1996
マイアーズとバラ標準化過程[7ページ]RFC1939POP3 May 1996
S: 2 200
S: .
...
C: LIST 2
S: +OK 2 200
...
C: LIST 3
S: -ERR no such message, only 2 messages in maildrop
S: 2 200秒間: . ... C: 2秒間、記載してください: + OK2 200… C: 3秒間、記載してください: -ERRはメッセージ、郵便受けでそのような2つのメッセージであるだけではありません。
RETR msg
RETR msg
Arguments:
a message-number (required) which may NOT refer to a
message marked as deleted
議論: 削除されるようにマークされたメッセージを示さないかもしれないメッセージ番号(必要です)
Restrictions:
may only be given in the TRANSACTION state
制限: TRANSACTION状態で与えるだけであるかもしれません。
Discussion:
If the POP3 server issues a positive response, then the
response given is multi-line. After the initial +OK, the
POP3 server sends the message corresponding to the given
message-number, being careful to byte-stuff the termination
character (as with all multi-line responses).
議論: POP3サーバが積極的な応答を発行するなら、与えられた応答はマルチ系列です。 初期かOKだったことの後に、POP3サーバは与えられたメッセージ番号に対応するメッセージを送ります、行終了文字をバイト詰めるのに慎重であることで(すべてのマルチ系列応答のように)。
Possible Responses:
+OK message follows
-ERR no such message
可能な応答: + OKメッセージはそのようなものが通信させる-ERRノー、に従います。
Examples:
C: RETR 1
S: +OK 120 octets
S: <the POP3 server sends the entire message here>
S: .
例: C: RETR1秒間: + OKの120の八重奏S: POP3サーバが全体を送る<はここで>Sを通信させます: .
DELE msg
DELE msg
Arguments:
a message-number (required) which may NOT refer to a
message marked as deleted
議論: 削除されるようにマークされたメッセージを示さないかもしれないメッセージ番号(必要です)
Restrictions:
may only be given in the TRANSACTION state
制限: TRANSACTION状態で与えるだけであるかもしれません。
Myers & Rose Standards Track [Page 8] RFC 1939 POP3 May 1996
マイアーズとバラ標準化過程[8ページ]RFC1939POP3 May 1996
Discussion:
The POP3 server marks the message as deleted. Any future
reference to the message-number associated with the message
in a POP3 command generates an error. The POP3 server does
not actually delete the message until the POP3 session
enters the UPDATE state.
議論: POP3サーバは削除されるようにメッセージをマークします。 POP3コマンドにおけるメッセージに関連しているメッセージ番号のどんな後学もエラーを起こします。 POP3セッションがUPDATE状態に入るまで、POP3サーバは実際にメッセージを削除しません。
Possible Responses:
+OK message deleted
-ERR no such message
可能な応答: + OKメッセージの削除された-ERRはそのようなメッセージではありません。
Examples:
C: DELE 1
S: +OK message 1 deleted
...
C: DELE 2
S: -ERR message 2 already deleted
例: C: DELE1秒間: + 1が削除したOKメッセージ… C: DELE2秒間: -既に削除されたERRメッセージ2
NOOP
NOOP
Arguments: none
議論: なし
Restrictions:
may only be given in the TRANSACTION state
制限: TRANSACTION状態で与えるだけであるかもしれません。
Discussion:
The POP3 server does nothing, it merely replies with a
positive response.
議論: それは、積極的な応答でPOP3サーバが何もしないと単に返答します。
Possible Responses:
+OK
可能な応答: + OK
Examples:
C: NOOP
S: +OK
例: C: NOOP S: + OK
RSET
RSET
Arguments: none
議論: なし
Restrictions:
may only be given in the TRANSACTION state
制限: TRANSACTION状態で与えるだけであるかもしれません。
Discussion:
If any messages have been marked as deleted by the POP3
server, they are unmarked. The POP3 server then replies
議論: 何かメッセージがPOP3サーバによって削除されるようにマークされたなら、それらは無印です。 そして、POP3サーバは返答します。
Myers & Rose Standards Track [Page 9] RFC 1939 POP3 May 1996
マイアーズとバラ標準化過程[9ページ]RFC1939POP3 May 1996
with a positive response.
積極的な応答で。
Possible Responses:
+OK
可能な応答: + OK
Examples:
C: RSET
S: +OK maildrop has 2 messages (320 octets)
例: C: RSET S: + OK郵便受けには、2つのメッセージがあります。(320の八重奏)
6. The UPDATE State
6. アップデート状態
When the client issues the QUIT command from the TRANSACTION state, the POP3 session enters the UPDATE state. (Note that if the client issues the QUIT command from the AUTHORIZATION state, the POP3 session terminates but does NOT enter the UPDATE state.)
クライアントがTRANSACTION状態からQUITコマンドを発行するとき、POP3セッションはUPDATE状態に入ります。 (クライアントがAUTHORIZATION状態からQUITコマンドを発行するなら、POP3セッションが終わりますが、UPDATE状態に入らないことに注意してください。)
If a session terminates for some reason other than a client-issued QUIT command, the POP3 session does NOT enter the UPDATE state and MUST not remove any messages from the maildrop.
ある理由でクライアントによって発行されたQUITコマンド以外に、セッションが終わるなら、POP3セッションは、UPDATE状態に入力しないで、郵便受けからどんなメッセージも取り除いてはいけません。
QUIT
やめてください。
Arguments: none
議論: なし
Restrictions: none
制限: なし
Discussion:
The POP3 server removes all messages marked as deleted
from the maildrop and replies as to the status of this
operation. If there is an error, such as a resource
shortage, encountered while removing messages, the
maildrop may result in having some or none of the messages
marked as deleted be removed. In no case may the server
remove any messages not marked as deleted.
議論: POP3サーバはこの操作の状態に関して郵便受けと回答から削除されるようにマークされたすべてのメッセージを取り除きます。 削除されるようにメッセージのいくつかかいずれもマークしない郵便受けがメッセージを取り除いている間に遭遇するリソース不足のようにもたらすかもしれない誤りがあれば、取り除いてください。 サーバが削除されるようにマークされなかったどんなメッセージも決して、取り除きませんように。
Whether the removal was successful or not, the server
then releases any exclusive-access lock on the maildrop
and closes the TCP connection.
取り外しがうまくいったか否かに関係なく、サーバは、次に、郵便受けのどんな排他的なアクセス錠もリリースして、TCP接続を終えます。
Possible Responses:
+OK
-ERR some deleted messages not removed
可能な応答: + OK-ERRは取り除かれなかったいくつかの削除されたメッセージです。
Examples:
C: QUIT
S: +OK dewey POP3 server signing off (maildrop empty)
...
C: QUIT
例: C: Sをやめてください: + サインオフする(郵便受け空の)OK dewey POP3サーバ… C: やめてください。
Myers & Rose Standards Track [Page 10] RFC 1939 POP3 May 1996
マイアーズとバラ標準化過程[10ページ]RFC1939POP3 May 1996
S: +OK dewey POP3 server signing off (2 messages left)
...
S: + サインオフするOK dewey POP3サーバ(あと2つのメッセージ)…
7. Optional POP3 Commands
7. 任意のPOP3コマンド
The POP3 commands discussed above must be supported by all minimal implementations of POP3 servers.
POP3サーバのすべての最小限の器具で上で議論したPOP3コマンドをサポートしなければなりません。
The optional POP3 commands described below permit a POP3 client greater freedom in message handling, while preserving a simple POP3 server implementation.
任意のPOP3コマンドは簡単なPOP3サーバ実装を保存している間、許可証の下でメッセージハンドリングにおけるPOP3のクライアントの、よりすばらしい自由について説明しました。
NOTE: This memo STRONGLY encourages implementations to support
these commands in lieu of developing augmented drop and scan
listings. In short, the philosophy of this memo is to put
intelligence in the part of the POP3 client and not the POP3
server.
以下に注意してください。 このメモSTRONGLYは、実装が増大している低下を開発することの代わりにこれらのコマンドをサポートして、リストをスキャンするよう奨励します。 要するに、このメモの哲学はPOP3サーバではなく、POP3クライアントの部分に知性を入れることです。
TOP msg n
TOP msg n
Arguments:
a message-number (required) which may NOT refer to to a
message marked as deleted, and a non-negative number
of lines (required)
議論: aへの削除されるようにマークされたメッセージ、および系列の非負数について言及しないかもしれないメッセージ番号(必要です)(必要)です。
Restrictions:
may only be given in the TRANSACTION state
制限: TRANSACTION状態で与えるだけであるかもしれません。
Discussion:
If the POP3 server issues a positive response, then the
response given is multi-line. After the initial +OK, the
POP3 server sends the headers of the message, the blank
line separating the headers from the body, and then the
number of lines of the indicated message's body, being
careful to byte-stuff the termination character (as with
all multi-line responses).
議論: POP3サーバが積極的な応答を発行するなら、与えられた応答はマルチ系列です。 初期かOKだったことの後に、POP3サーバはメッセージ、ボディーからヘッダーを分離する空白行、および次に、示されたメッセージのボディーの系列の数のヘッダーを送ります、行終了文字をバイト詰めるのに慎重であることで(すべてのマルチ系列応答のように)。
Note that if the number of lines requested by the POP3
client is greater than than the number of lines in the
body, then the POP3 server sends the entire message.
POP3クライアントによって要求された系列の数がボディーの系列の数より大きいならPOP3サーバが全体のメッセージを送ることに注意してください。
Possible Responses:
+OK top of message follows
-ERR no such message
可能な応答: + メッセージのOK先端はそのようなものが通信させる-ERRノー、に従います。
Examples:
C: TOP 1 10
S: +OK
例: C: 10秒間の最高1: + OK
Myers & Rose Standards Track [Page 11] RFC 1939 POP3 May 1996
マイアーズとバラ標準化過程[11ページ]RFC1939POP3 May 1996
S: <the POP3 server sends the headers of the
message, a blank line, and the first 10 lines
of the body of the message>
S: .
...
C: TOP 100 3
S: -ERR no such message
S: POP3サーバがメッセージのヘッダー、空白行、およびメッセージ欄>Sの最初の10の系列を送る<: . ... C: トップ1003秒間: -ERRはそのようなメッセージではありません。
UIDL [msg]
UIDL[msg]
Arguments:
a message-number (optional), which, if present, may NOT
refer to a message marked as deleted
議論: メッセージ番号(任意の)。(存在しているなら、そのメッセージ番号は削除されるようにマークされたメッセージを示さないかもしれません)。
Restrictions:
may only be given in the TRANSACTION state.
制限: TRANSACTION状態で与えるだけであるかもしれません。
Discussion:
If an argument was given and the POP3 server issues a positive
response with a line containing information for that message.
This line is called a "unique-id listing" for that message.
議論: 議論が与えてPOP3であったなら、サーバは系列がそのメッセージのための情報を含んでいる積極的な応答を発行します。 この系列はそのメッセージのために「ユニークなイドリスト」と呼ばれます。
If no argument was given and the POP3 server issues a positive
response, then the response given is multi-line. After the
initial +OK, for each message in the maildrop, the POP3 server
responds with a line containing information for that message.
This line is called a "unique-id listing" for that message.
議論を全く与えないで、POP3サーバが積極的な応答を発行して、次に、与えられた応答がマルチ系列であるなら。 初期かOKだったことの後に、郵便受けにおける各メッセージに関して、系列がそのメッセージのための情報を含んでいて、POP3サーバは反応します。 この系列はそのメッセージのために「ユニークなイドリスト」と呼ばれます。
In order to simplify parsing, all POP3 servers are required to
use a certain format for unique-id listings. A unique-id
listing consists of the message-number of the message,
followed by a single space and the unique-id of the message.
No information follows the unique-id in the unique-id listing.
構文解析を簡素化するために、すべてのPOP3サーバがユニークなイドリストに、ある形式を使用するのに必要です。 ユニークなイドリストはシングルスペースがあとに続いたメッセージのメッセージ番号とメッセージのユニークなイドから成ります。 どんな情報もユニークなイドリストでユニークなイドに従いません。
The unique-id of a message is an arbitrary server-determined
string, consisting of one to 70 characters in the range 0x21
to 0x7E, which uniquely identifies a message within a
maildrop and which persists across sessions. This
persistence is required even if a session ends without
entering the UPDATE state. The server should never reuse an
unique-id in a given maildrop, for as long as the entity
using the unique-id exists.
メッセージのユニークなイドは任意のサーバで決定しているストリングです、0x7E(郵便受けの中で唯一メッセージを特定して、セッションの向こう側に固執している)に範囲0x21の1〜70のキャラクタから成って。 セッションがUPDATE状態に入らないで終わっても、この固執が必要です。 サーバは与えられた郵便受けにおけるユニークなイドを決して再利用するべきではありません、ユニークなイドを使用する実体が存在している限り。
Note that messages marked as deleted are not listed.
削除されるようにマークされたメッセージが記載されていないことに注意してください。
While it is generally preferable for server implementations
to store arbitrarily assigned unique-ids in the maildrop,
サーバ実装が郵便受けにおける任意に割り当てられたユニークなイドを保存するのが、一般に望ましいのですが
Myers & Rose Standards Track [Page 12] RFC 1939 POP3 May 1996
マイアーズとバラ標準化過程[12ページ]RFC1939POP3 May 1996
this specification is intended to permit unique-ids to be
calculated as a hash of the message. Clients should be able
to handle a situation where two identical copies of a
message in a maildrop have the same unique-id.
この仕様が、ユニークなイドがメッセージのハッシュとして計算されることを許可することを意図します。 クライアントは郵便受けにおけるメッセージの同一のもの2通が同じユニークなイドを持っている状況を扱うことができるべきです。
Possible Responses:
+OK unique-id listing follows
-ERR no such message
可能な応答: + OKリストが従うユニークなイド-ERRはそのようなメッセージではありません。
Examples:
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
例: C: UIDL S: + OK S: 1whqtswO00WBw418f9t5JxYwZ S: 2 QhdPYR: 00WBw1Ph7x7S: . ... C: UIDL2秒間: QhdPYR: + OK2 00WBw1Ph7x7… C: UIDL3秒間: -ERRはメッセージ、郵便受けでそのような2つのメッセージであるだけではありません。
USER name
USER名
Arguments:
a string identifying a mailbox (required), which is of
significance ONLY to the server
議論: サーバだけへの意味のものであるメールボックス(必要である)を特定するストリング
Restrictions:
may only be given in the AUTHORIZATION state after the POP3
greeting or after an unsuccessful USER or PASS command
制限: POP3挨拶か失敗のUSERかPASSが命令した後にAUTHORIZATION状態で与えるだけであるかもしれません。
Discussion:
To authenticate using the USER and PASS command
combination, the client must first issue the USER
command. If the POP3 server responds with a positive
status indicator ("+OK"), then the client may issue
either the PASS command to complete the authentication,
or the QUIT command to terminate the POP3 session. If
the POP3 server responds with a negative status indicator
("-ERR") to the USER command, then the client may either
issue a new authentication command or may issue the QUIT
command.
議論: USERを使用して、PASSコマンド組み合わせを認証するために、クライアントは最初に、USERコマンドを発行しなければなりません。 POP3サーバが陽性反応インディケータ(「+ OK」)で反応するなら、クライアントは認証を終了する通過コマンドかPOP3セッションを終える辞任コマンドのどちらかを発行するかもしれません。 POP3サーバが否定的自動運転表示灯(「-間違える」)でユーザコマンドに反応するなら、クライアントは、新しい認証コマンドを発行するか、または辞任コマンドを発行するかもしれません。
The server may return a positive response even though no
such mailbox exists. The server may return a negative
response if mailbox exists, but does not permit plaintext
どんなそのようなメールボックスも存在していませんが、サーバは積極的な応答を返すかもしれません。 サーバは、メールボックスが存在しているなら否定応答を返すかもしれませんが、平文を可能にしません。
Myers & Rose Standards Track [Page 13] RFC 1939 POP3 May 1996
マイアーズとバラ標準化過程[13ページ]RFC1939POP3 May 1996
password authentication.
パスワード認証。
Possible Responses:
+OK name is a valid mailbox
-ERR never heard of mailbox name
可能な応答: + OK名は-ERRがメールボックス名について決して聞かなかった有効なメールボックスです。
Examples:
C: USER frated
S: -ERR sorry, no mailbox for frated here
...
C: USER mrose
S: +OK mrose is a real hoopy frood
例: C: USER frated S: -ERR残念である、どんなメールボックス、もここで、…をfratedしませんでした。 C: USER mrose S: +OK mroseは本当のhoopy froodです。
PASS string
PASSストリング
Arguments:
a server/mailbox-specific password (required)
議論: メールボックスサーバ/特有のパスワード(必要)です。
Restrictions:
may only be given in the AUTHORIZATION state immediately
after a successful USER command
制限: うまくいっているUSERコマンド直後AUTHORIZATION状態で与えるだけであるかもしれません。
Discussion:
When the client issues the PASS command, the POP3 server
uses the argument pair from the USER and PASS commands to
determine if the client should be given access to the
appropriate maildrop.
議論: クライアントがPASSコマンドを発行するとき、POP3サーバはUSERからの議論組を使用します、そして、PASSは適切な郵便受けへのアクセスがクライアントに与えられるべきであるかどうか決定すると命令します。
Since the PASS command has exactly one argument, a POP3
server may treat spaces in the argument as part of the
password, instead of as argument separators.
PASSコマンドにはちょうど1つの議論があるので、POP3サーバはパスワードの一部として議論における空間を扱うかもしれません、引数分離子の代わりに。
Possible Responses:
+OK maildrop locked and ready
-ERR invalid password
-ERR unable to lock maildrop
可能な応答: 郵便受けをロックできない+ OK郵便受けのロックされて持ち合わせの-ERR無効のパスワード-ERR
Examples:
C: USER mrose
S: +OK mrose is a real hoopy frood
C: PASS secret
S: -ERR maildrop already 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)
例: C: USER mrose S: +OK mroseは本当のhoopy frood Cです: PASS秘密S: -ERR郵便受けは既にロックされました… C: USER mrose S: +OK mroseは本当のhoopy frood Cです: PASS秘密S: +OK mroseの郵便受けには、2つのメッセージがあります。(320の八重奏)
Myers & Rose Standards Track [Page 14] RFC 1939 POP3 May 1996
マイアーズとバラ標準化過程[14ページ]RFC1939POP3 May 1996
APOP name digest
APOP名前ダイジェスト
Arguments:
a string identifying a mailbox and a MD5 digest string
(both required)
議論: メールボックスを特定するストリングとMD5ダイジェストストリング(ともに必要)です。
Restrictions:
may only be given in the AUTHORIZATION state after the POP3
greeting or after an unsuccessful USER or PASS command
制限: POP3挨拶か失敗のUSERかPASSが命令した後にAUTHORIZATION状態で与えるだけであるかもしれません。
Discussion:
Normally, each POP3 session starts with a USER/PASS
exchange. This results in a server/user-id specific
password being sent in the clear on the network. For
intermittent use of POP3, this may not introduce a sizable
risk. However, many POP3 client implementations connect to
the POP3 server on a regular basis -- to check for new
mail. Further the interval of session initiation may be on
the order of five minutes. Hence, the risk of password
capture is greatly enhanced.
議論: 通常、それぞれのPOP3セッションはUSER/PASS交換から始まります。 これはネットワークに関する明確で送られるサーバ/ユーザIDの特定のパスワードをもたらします。 POP3の間欠使用のために、これはかなり大きい危険を導入しないかもしれません。 しかしながら、多くのPOP3クライアント実装が定期的にPOP3サーバに接続します--新しいメールがないかどうかチェックするために。 さらに、5分の注文にはセッション開始の間隔があるかもしれません。 したがって、パスワード・キャプチャの危険は大いに高められます。
An alternate method of authentication is required which
provides for both origin authentication and replay
protection, but which does not involve sending a password
in the clear over the network. The APOP command provides
this functionality.
発生源認証と反復操作による保護の両方に備えますが、ネットワークの上の明確でパスワードを送ることを伴わない認証の代替方法が、必要です。 APOPコマンドはこの機能性を提供します。
A POP3 server which implements the APOP command will
include a timestamp in its banner greeting. The syntax of
the timestamp corresponds to the `msg-id' in [RFC822], and
MUST be different each time the POP3 server issues a banner
greeting. For example, on a UNIX implementation in which a
separate UNIX process is used for each instance of a POP3
server, the syntax of the timestamp might be:
APOPがコマンドであると実装するPOP3サーバはバナー挨拶にタイムスタンプを含むでしょう。 タイムスタンプの構文は、[RFC822]の'msg-イド'に対応している、POP3サーバがバナー挨拶を発行する各回に異なっているに違いありません。 例えば、別々のUNIXプロセスがPOP3サーバの各インスタンスに使用されるUNIX実装では、タイムスタンプの構文は以下の通りです。
<process-ID.clock@hostname>
<プロセスID.clock@hostname>。
where `process-ID' is the decimal value of the process's
PID, clock is the decimal value of the system clock, and
hostname is the fully-qualified domain-name corresponding
to the host where the POP3 server is running.
'プロセスID'が過程sのPIDのデシマル値であるところでは、時計はシステムクロックのデシマル値です、そして、ホスト名はPOP3サーバが稼働しているところのホストにとって、対応する完全に適切なドメイン名です。
The POP3 client makes note of this timestamp, and then
issues the APOP command. The `name' parameter has
identical semantics to the `name' parameter of the USER
command. The `digest' parameter is calculated by applying
the MD5 algorithm [RFC1321] to a string consisting of the
timestamp (including angle-brackets) followed by a shared
POP3クライアントはこのタイムスタンプ、および次に、問題のメモをAPOPコマンドにします。 '名前'パラメタはUSERコマンドの'名前'パラメタに同じ意味論を持っています。 'ダイジェスト'パラメタは、共有されたaがあとに続いたタイムスタンプ(角ブラケットを含んでいる)から成るストリングにMD5アルゴリズム[RFC1321]を適用することによって、計算されます。
Myers & Rose Standards Track [Page 15] RFC 1939 POP3 May 1996
マイアーズとバラ標準化過程[15ページ]RFC1939POP3 May 1996
secret. This shared secret is a string known only to the
POP3 client and server. Great care should be taken to
prevent unauthorized disclosure of the secret, as knowledge
of the secret will allow any entity to successfully
masquerade as the named user. The `digest' parameter
itself is a 16-octet value which is sent in hexadecimal
format, using lower-case ASCII characters.
秘密。 この共有秘密キーはPOP3クライアントとサーバだけに知られているストリングです。秘密の不当開示を防ぐために高度の注意を取るべきです、どんな実体も秘密に関する知識で首尾よく命名されたユーザのふりをすることができるとき。 'ダイジェスト'パラメタ自体は小文字のASCII文字を使用して、16進形式で送られる16八重奏の値です。
When the POP3 server receives the APOP command, it verifies
the digest provided. If the digest is correct, the POP3
server issues a positive response, and the POP3 session
enters the TRANSACTION state. Otherwise, a negative
response is issued and the POP3 session remains in the
AUTHORIZATION state.
POP3サーバがAPOPコマンドを受け取るとき、それは提供されたダイジェストについて確かめます。 ダイジェストが正しいなら、POP3サーバは積極的な応答を発行します、そして、POP3セッションはTRANSACTION状態に入れます。 さもなければ、否定応答は発行されます、そして、POP3セッションはAUTHORIZATION州に残っています。
Note that as the length of the shared secret increases, so
does the difficulty of deriving it. As such, shared
secrets should be long strings (considerably longer than
the 8-character example shown below).
共有秘密キーの長さがそれを引き出すという困難を増強して、そう、するとき、それに注意してください。 そういうものとして、共有秘密キーはロング・ストリングであるべきです(以下に示された8キャラクタの例よりかなり長い)。
Possible Responses:
+OK maildrop locked and ready
-ERR permission denied
可能な応答: + ロックされて持ち合わせの-ERR許可が否定したOK郵便受け
Examples:
S: +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us>
C: APOP mrose c4c9334bac560ecc979e58001b3e22fb
S: +OK maildrop has 1 message (369 octets)
例: S: + OK POP3サーバ ready <1896.697170952@dbc.mtview.ca.us 、gt;、C: APOP mrose c4c9334bac560ecc979e58001b3e22fb S: + OK郵便受けには、1つのメッセージがあります。(369の八重奏)
In this example, the shared secret is the string `tan-
staaf'. Hence, the MD5 algorithm is applied to the string
この例では、共有秘密キーはストリング'日焼けstaaf'です。 したがって、MD5アルゴリズムはストリングに適用されます。
<1896.697170952@dbc.mtview.ca.us>tanstaaf
<1896.697170952@dbc.mtview.ca.us>tanstaaf
which produces a digest value of
生産物aはどれについて値を読みこなしますか。
c4c9334bac560ecc979e58001b3e22fb
c4c9334bac560ecc979e58001b3e22fb
8. Scaling and Operational Considerations
8. 比例していて操作上の問題
Since some of the optional features described above were added to the POP3 protocol, experience has accumulated in using them in large- scale commercial post office operations where most of the users are unrelated to each other. In these situations and others, users and vendors of POP3 clients have discovered that the combination of using the UIDL command and not issuing the DELE command can provide a weak version of the "maildrop as semi-permanent repository" functionality normally associated with IMAP. Of course the other capabilities of
上で説明されたオプション機能のいくつかがPOP3プロトコルに追加されて以来、経験はそれらを使用する際に互いに、ユーザの大部分が関係ないところに商業郵便局操作を大きいスケールで蓄積しています。 これらの状況と他のものでは、POP3クライアントのユーザとベンダーは、UIDLコマンドを使用して、DELEコマンドを発行しない組み合わせが通常、IMAPに関連している「半永久的な倉庫としての郵便受け」機能性の弱いバージョンを提供できると発見しました。 もちろん他の能力
Myers & Rose Standards Track [Page 16] RFC 1939 POP3 May 1996
マイアーズとバラ標準化過程[16ページ]RFC1939POP3 May 1996
IMAP, such as polling an existing connection for newly arrived messages and supporting multiple folders on the server, are not present in POP3.
新たに到着したメッセージのために既存の接続に投票して、サーバで複数のフォルダーを支えなどなどのIMAPはPOP3に存在していません。
When these facilities are used in this way by casual users, there has been a tendency for already-read messages to accumulate on the server without bound. This is clearly an undesirable behavior pattern from the standpoint of the server operator. This situation is aggravated by the fact that the limited capabilities of the POP3 do not permit efficient handling of maildrops which have hundreds or thousands of messages.
これらの施設が一時的ユーザによってこのように使用されるとき、サーバにバウンドなしで蓄積する既読メッセージのための傾向がありました。 これは明確にサーバオペレータの見地からの好ましくない行動パターンです。 POP3の限られた能力が数百を持っている郵便受けか何千ものメッセージの効率的な取り扱いを可能にしないという事実によってこの状況はいらいらさせられます。
Consequently, it is recommended that operators of large-scale multi- user servers, especially ones in which the user's only access to the maildrop is via POP3, consider such options as:
その結果、大規模なマルチユーザサーバのオペレータ(特にPOP3を通して郵便受けへのユーザの唯一のアクセスがあるもの)が以下のようなオプションを考えるのは、お勧めです。
* Imposing a per-user maildrop storage quota or the like.
* 1ユーザあたり1つの郵便受けストレージ割当てを課すか、同様のもの。
A disadvantage to this option is that accumulation of messages may
result in the user's inability to receive new ones into the
maildrop. Sites which choose this option should be sure to inform
users of impending or current exhaustion of quota, perhaps by
inserting an appropriate message into the user's maildrop.
このオプションへの不都合はメッセージの蓄積がユーザのものが新しいものを郵便受けに受けることができないことをもたらすかもしれないということです。 このオプションを選ぶサイトは確実に割当ての迫るか現在の疲労困憊についてユーザに知らせるべきです、恐らく適切なメッセージをユーザの郵便受けに挿入することによって。
* Enforce a site policy regarding mail retention on the server.
* メール保有に関するサイト方針にサーバに押しつけてください。
Sites are free to establish local policy regarding the storage and
retention of messages on the server, both read and unread. For
example, a site might delete unread messages from the server after
60 days and delete read messages after 7 days. Such message
deletions are outside the scope of the POP3 protocol and are not
considered a protocol violation.
サイトは、サーバにおけるメッセージのストレージと保有に関するローカルの方針を確立するのにおいて自由であって、ともに読まれて読まれていません。 例えば、サイトは、60日後にサーバから未読メッセージを削除して、7日後に既読メッセージを削除するかもしれません。 そのようなメッセージ削除は、POP3プロトコルの範囲の外にあって、プロトコル違反であると考えられません。
Server operators enforcing message deletion policies should take
care to make all users aware of the policies in force.
メッセージ削除方針を実施するサーバオペレータは、方針を意識しているすべてのユーザを有効にするように注意するべきです。
Clients must not assume that a site policy will automate message
deletions, and should continue to explicitly delete messages using
the DELE command when appropriate.
クライアントは、サイト方針が、メッセージ削除を自動化して、適切であるときに、DELEコマンドを使用することで明らかにメッセージを削除し続けるべきであると仮定してはいけません。
It should be noted that enforcing site message deletion policies
may be confusing to the user community, since their POP3 client
may contain configuration options to leave mail on the server
which will not in fact be supported by the server.
サイトメッセージ削除方針を実施するのがユーザーコミュニティに混乱させられているかもしれないことに注意されるべきです、彼らのPOP3クライアントが事実上、サーバによってサポートされないサーバに関するメールを残す設定オプションを含むかもしれないので。
One special case of a site policy is that messages may only be
downloaded once from the server, and are deleted after this has
been accomplished. This could be implemented in POP3 server
サイト方針の1つの特別なケースはメッセージがサーバからの一度ダウンロードされるだけであるかもしれなく、これが達成された後に削除されるということです。 POP3サーバでこれを実装することができました。
Myers & Rose Standards Track [Page 17] RFC 1939 POP3 May 1996
マイアーズとバラ標準化過程[17ページ]RFC1939POP3 May 1996
software by the following mechanism: "following a POP3 login by a
client which was ended by a QUIT, delete all messages downloaded
during the session with the RETR command". It is important not to
delete messages in the event of abnormal connection termination
(ie, if no QUIT was received from the client) because the client
may not have successfully received or stored the messages.
Servers implementing a download-and-delete policy may also wish to
disable or limit the optional TOP command, since it could be used
as an alternate mechanism to download entire messages.
以下のメカニズムによるソフトウェア: 「クライアントによるQUITが終わらせたPOP3ログインに続いて、RETRコマンドとのセッションの間にダウンロードされたすべてのメッセージを削除してください。」 クライアントが首尾よくメッセージを受け取りませんし、また保存していないかもしれないので、異常な接続終了の場合、メッセージを削除しないのは重要です(ie、いいえなら、クライアントからQUITを受け取りました)。 aを実装するサーバが、方針をダウンロードして、削除します。また、任意のTOPコマンドを無効にするか、または制限することを願うかもしれません、全体のメッセージをダウンロードするのに代替のメカニズムとしてそれを使用できたので。
9. POP3 Command Summary
9. POP3コマンド概要
Minimal POP3 Commands:
最小量のPOP3は命令します:
USER name valid in the AUTHORIZATION state
PASS string
QUIT
AUTHORIZATION州のPASSストリングQUITで妥当なUSER名
STAT valid in the TRANSACTION state
LIST [msg]
RETR msg
DELE msg
NOOP
RSET
QUIT
TRANSACTION州のLIST[msg]RETR msg DELE msg NOOP RSET QUITで有効なSTAT
Optional POP3 Commands:
任意のPOP3は命令します:
APOP name digest valid in the AUTHORIZATION state
AUTHORIZATION状態で有効なAPOP名前ダイジェスト
TOP msg n valid in the TRANSACTION state
UIDL [msg]
TRANSACTION州のUIDLで有効なTOP msg n[msg]
POP3 Replies:
POP3は返答します:
+OK
-ERR
+OKは間違えます。
Note that with the exception of the STAT, LIST, and UIDL commands,
the reply given by the POP3 server to any command is significant
only to "+OK" and "-ERR". Any text occurring after this reply
may be ignored by the client.
「STAT、LIST、およびUIDLコマンドを除いて、POP3サーバによってどんなコマンドにも与えられた回答がOKに」 +だけに重要であることに注意してください」と「-間違えてください。」 この回答の後に起こるどんなテキストもクライアントによって無視されるかもしれません。
Myers & Rose Standards Track [Page 18] RFC 1939 POP3 May 1996
マイアーズとバラ標準化過程[18ページ]RFC1939POP3 May 1996
10. Example POP3 Session
10. 例のPOP3セッション
S: <wait for connection on TCP port 110>
C: <open connection>
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: <the POP3 server sends message 1>
S: .
C: DELE 1
S: +OK message 1 deleted
C: RETR 2
S: +OK 200 octets
S: <the POP3 server sends message 2>
S: .
C: DELE 2
S: +OK message 2 deleted
C: QUIT
S: +OK dewey POP3 server signing off (maildrop empty)
C: <close connection>
S: <wait for next connection>
S: TCPポート110>Cにおける接続のための<待ち: <の開いている接続>S: + OK POP3サーバ ready <1896.697170952@dbc.mtview.ca.us 、gt;、C: APOP mrose c4c9334bac560ecc979e58001b3e22fb S: + mroseの郵便受けが2メッセージ(320の八重奏)C持っているOK: スタットS: + OK2 320C: リストS: + OK2つのメッセージ(320の八重奏)S: 1 120秒間: 2 200秒間: . C: RETR1秒間: + OKの120の八重奏S: POP3サーバがメッセージ1>Sを送る<: . C: DELE1秒間: + OKメッセージ1はCを削除しました: RETR2秒間: + OKの200の八重奏S: POP3サーバがメッセージ2>Sを送る<: . C: DELE2秒間: + OKメッセージ2はCを削除しました: Sをやめてください: + (郵便受け空)のCに調印されるOK dewey POP3サーバ: <浅からぬ関係>S: 次の接続>のための<待ち
11. Message Format
11. メッセージ・フォーマット
All messages transmitted during a POP3 session are assumed to conform to the standard for the format of Internet text messages [RFC822].
POP3セッションの間に送られたすべてのメッセージがインターネット・テキスト・メッセージ[RFC822]の形式の規格に従うと思われます。
It is important to note that the octet count for a message on the server host may differ from the octet count assigned to that message due to local conventions for designating end-of-line. Usually, during the AUTHORIZATION state of the POP3 session, the POP3 server can calculate the size of each message in octets when it opens the maildrop. For example, if the POP3 server host internally represents end-of-line as a single character, then the POP3 server simply counts each occurrence of this character in a message as two octets. Note that lines in the message which start with the termination octet need not (and must not) be counted twice, since the POP3 client will remove all byte-stuffed termination characters when it receives a multi-line response.
サーバー・ホストに関するメッセージのための八重奏カウントが地方のコンベンションのため行末を指定するためにそのメッセージに割り当てられた八重奏カウントと異なるかもしれないことに注意するのは重要です。 通常、郵便受けを開くと、POP3セッションのAUTHORIZATION状態の間、POP3サーバは八重奏における、それぞれのメッセージのサイズについて計算できます。 例えば、POP3サーバー・ホストが単独のキャラクタとして内部的に行末を表すなら、POP3サーバは2つの八重奏として単にメッセージにおける、このキャラクタの各発生を数えます。 そして、メッセージで終了八重奏でどの始めを裏打ちする注意がそうする必要はない、()、二度数えられてください、マルチ系列応答を受けるとき、POP3クライアントがすべてのバイトで詰められた行終了文字を外すので、そうしなければなりません。
Myers & Rose Standards Track [Page 19] RFC 1939 POP3 May 1996
マイアーズとバラ標準化過程[19ページ]RFC1939POP3 May 1996
12. References
12. 参照
[RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
821, USC/Information Sciences Institute, August 1982.
[RFC821] ポステル、J.、「簡単なメール転送プロトコル」、STD10、RFC821、科学が1982年8月に設けるUSC/情報。
[RFC822] Crocker, D., "Standard for the Format of ARPA-Internet Text
Messages", STD 11, RFC 822, University of Delaware, August 1982.
[RFC822] クロッカー、D.、「アルパインターネットテキスト・メッセージの形式の規格」、STD11、RFC822、デラウエア大学、1982年8月。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
MIT Laboratory for Computer Science, April 1992.
[RFC1321] Rivest、R.、「MD5メッセージダイジェストアルゴリズム」、RFC1321、MITコンピュータサイエンス研究所、1992年4月。
[RFC1730] Crispin, M., "Internet Message Access Protocol - Version
4", RFC 1730, University of Washington, December 1994.
[RFC1730] クリスピン、M.、「バージョン4インチ、RFC1730、ワシントン大学、1994年インターネットメッセージアクセス・プロトコル--12月。」
[RFC1734] Myers, J., "POP3 AUTHentication command", RFC 1734,
Carnegie Mellon, December 1994.
[RFC1734] マイアーズ、J.、「POP3 AUTHenticationコマンド」、RFC1734、カーネギー・メロン、1994年12月。
13. Security Considerations
13. セキュリティ問題
It is conjectured that use of the APOP command provides origin identification and replay protection for a POP3 session. Accordingly, a POP3 server which implements both the PASS and APOP commands should not allow both methods of access for a given user; that is, for a given mailbox name, either the USER/PASS command sequence or the APOP command is allowed, but not both.
APOPコマンドの使用がPOP3セッションのために発生源識別と反復操作による保護を提供すると推測されます。 それに従って、両方がPASSとAPOPコマンドであると実装するPOP3サーバは与えられたユーザのためのアクセスの両方のメソッドを許容するべきではありません。 それは、与えられたメールボックス名(コマンドが許容されているUSER/PASSコマンド・シーケンスかAPOPのどちらか)のためにありますが、ともにいるというわけではありません。
Further, note that as the length of the shared secret increases, so does the difficulty of deriving it.
共有秘密キーの長さがそれを引き出すという困難を増強して、そう、するとき、さらに、それに注意してください。
Servers that answer -ERR to the USER command are giving potential attackers clues about which names are valid.
どの名前に関して与えているかUSERへの答え-ERRが潜在的攻撃者手がかりを命令するサーバは有効です。
Use of the PASS command sends passwords in the clear over the network.
PASSコマンドの使用はネットワークの上の明確でパスワードを送ります。
Use of the RETR and TOP commands sends mail in the clear over the network.
RETRとTOPコマンドの使用はネットワークの上の明確でメールを送ります。
Otherwise, security issues are not discussed in this memo.
さもなければ、このメモで安全保障問題について議論しません。
14. Acknowledgements
14. 承認
The POP family has a long and checkered history. Although primarily a minor revision to RFC 1460, POP3 is based on the ideas presented in RFCs 918, 937, and 1081.
POPファミリーには、長くて市松模様の歴史があります。 主としてRFC1460への小さい方の改正ですが、POP3はRFCs918、937、および1081年に提示された考えに基づいています。
In addition, Alfred Grimstad, Keith McCloghrie, and Neil Ostroff provided significant comments on the APOP command.
さらに、アルフレッド・グリムスター、キースMcCloghrie、およびニールOstroffはAPOPコマンドの重要なコメントを提供しました。
Myers & Rose Standards Track [Page 20] RFC 1939 POP3 May 1996
マイアーズとバラ標準化過程[20ページ]RFC1939POP3 May 1996
15. Authors' Addresses
15. 作者のアドレス
John G. Myers Carnegie-Mellon University 5000 Forbes Ave Pittsburgh, PA 15213
ジョンG.マイアーズカーネギーメロン大学5000フォーブズ・Aveピッツバーグ、PA 15213
EMail: jgm+@cmu.edu
メール: jgm+@cmu.edu
Marshall T. Rose Dover Beach Consulting, Inc. 420 Whisman Court Mountain View, CA 94043-2186
Whisman法廷マウンテンビュー、マーシャルT.バラドーヴァービーチコンサルティングInc.420カリフォルニア94043-2186
EMail: mrose@dbc.mtview.ca.us
メール: mrose@dbc.mtview.ca.us
Myers & Rose Standards Track [Page 21] RFC 1939 POP3 May 1996
マイアーズとバラ標準化過程[21ページ]RFC1939POP3 May 1996
Appendix A. Differences from RFC 1725
RFC1725からの付録A.差
This memo is a revision to RFC 1725, a Draft Standard. It makes the following changes from that document:
このメモはRFC1725、Draft Standardへの改正です。 それはそのドキュメントからの以下の変更を行います:
- clarifies that command keywords are case insensitive.
- はっきりさせる、コマンドキーワードは大文字と小文字を区別しないです。
- specifies that servers must send "+OK" and "-ERR" in
upper case.
- 「サーバが」 + 」 大文字におけるOKの「間違えてください」を送らなければならないと指定します。
- specifies that the initial greeting is a positive response,
instead of any string which should be a positive response.
- 初期の挨拶が積極的な応答であるべきであるどんなストリングの代わりに積極的な応答であると指定します。
- clarifies behavior for unimplemented commands.
- 非実装しているコマンドのための振舞いをはっきりさせます。
- makes the USER and PASS commands optional.
- USERとPASSコマンドを任意にします。
- clarified the set of possible responses to the USER command.
- USERコマンドへの可能な応答のセットをはっきりさせました。
- reverses the order of the examples in the USER and PASS
commands, to reduce confusion.
- 混乱を抑えるためにUSERとPASSコマンドにおける、例の注文を逆にします。
- clarifies that the PASS command may only be given immediately
after a successful USER command.
- はっきりさせる、うまくいっているUSERコマンド直後PASSが命令するのを与えるだけであるかもしれません。
- clarified the persistence requirements of UIDs and added some
implementation notes.
- UIDsの固執要件をはっきりさせて、いくつかの実装注意を加えました。
- specifies a UID length limitation of one to 70 octets.
- 1〜70の八重奏のUID長さの制限を指定します。
- specifies a status indicator length limitation
of 512 octets, including the CRLF.
- CRLFを含む512の八重奏の自動運転表示灯長さの制限を指定します。
- clarifies that LIST with no arguments on an empty mailbox
returns success.
- 空のメールボックスリターン成功で議論なしでそのLISTをはっきりさせます。
- adds a reference from the LIST command to the Message Format
section
- LISTコマンドからMessage Format部までの参照を加えます。
- clarifies the behavior of QUIT upon failure
- 失敗のQUITの動きをはっきりさせます。
- clarifies the security section to not imply the use of the
USER command with the APOP command.
- APOPコマンドでUSERコマンドの使用を含意しないようにセキュリティ部をはっきりさせます。
- adds references to RFCs 1730 and 1734
- RFCs1730と1734の参照を加えます。
- clarifies the method by which a UA may enter mail into the
transport system.
- UAがメールを輸送システムに入力するかもしれないメソッドをはっきりさせます。
Myers & Rose Standards Track [Page 22] RFC 1939 POP3 May 1996
マイアーズとバラ標準化過程[22ページ]RFC1939POP3 May 1996
- clarifies that the second argument to the TOP command is a
number of lines.
- TOPコマンドへの議論が多くの系列である秒にそれをはっきりさせます。
- changes the suggestion in the Security Considerations section
for a server to not accept both PASS and APOP for a given user
from a "must" to a "should".
- サーバが与えられたユーザのためにPASSとAPOPの両方を“must"から“should"に受け入れないように、Security Considerations部での提案を変えます。
- adds a section on scaling and operational considerations
- 比例していて操作上の問題のセクションを加えます。
Appendix B. Command Index
付録B.コマンド索引
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
APOP… 15DELE… 8 記載してください… 6NOOP… 9 通ってください… 14 やめてください… 5 やめてください… 10RETR… 8RSET… 9スタット… 6 付けます。 11UIDL… 12ユーザ… 13
Myers & Rose Standards Track [Page 23]
マイアーズとバラ標準化過程[23ページ]
一覧
スポンサーリンク
