RFC1725 日本語訳
1725 Post Office Protocol - Version 3. J. Myers, M. Rose. November 1994. (Format: TXT=35058 bytes) (Obsoletes RFC1460) (Obsoleted by RFC1939) (Status: STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Myers
Request for Comments: 1725 Carnegie Mellon
Obsoletes: 1460 M. Rose
Category: Standards Track Dover Beach Consulting, Inc.
November 1994
コメントを求めるワーキンググループJ.マイアーズの要求をネットワークでつないでください: 1725 カーネギー・メロンは以下を時代遅れにします。 1460年のM.バラカテゴリ: Inc.1994年11月に相談する標準化過程ドーヴァービーチ
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)の現行版を参照してください。 このメモの分配は無制限です。
Overview
概要
This memo is a revision to RFC 1460, a Draft Standard. It makes the following changes from that document:
このメモはRFC1460、Draft Standardへの改正です。 それはそのドキュメントからの以下の変更を行います:
- removed text regarding "split-UA model", which didn't add
anything to the understanding of POP
- 「分裂-UAはモデル化すること」に関する取り除かれたテキスト。(そのテキストはPOPの理解に何も加えませんでした)。
- clarified syntax of commands, keywords, and arguments
- コマンド、キーワード、および議論のはっきりさせられた構文
- clarified behavior on broken connection
- 失意の接続のはっきりさせられた振舞い
- explicitly permitted an inactivity autologout timer
- 明らかに受入れられて、不活発はタイマをautologoutします。
- clarified the requirements of the "exclusive-access lock"
- 「排他的なアクセス錠」の要件をはっきりさせます。
- removed implementation-specific wording regarding the parsing of
the maildrop
- 郵便受けの構文解析に関する取り除かれた実装特有の言葉遣い
- allowed servers to close the connection after a failed
authentication command
- 失敗した認証コマンドの後に接続を終える許容サーバ
- removed the LAST command
- 取り除いて、LASTは命令します。
- fixed typo in example of TOP command
- TOPコマンドに関する例の固定誤植
- clarified that the second argument to the TOP command is non-
negative
- はっきりさせられて、TOPへの2番目の議論が命令するのは、非否定的です。
- added the optional UIDL command
- 加えられて、任意のUIDLは命令します。
Myers & Rose [Page 1] RFC 1725 POP3 November 1994
マイアーズとローズ[1ページ]RFC1725POP3 November 1994
- added warning regarding length of shared secrets with APOP
- APOPがある共有秘密キーの長さに関する付記された警告
- added additional warnings to the security considerations section
- セキュリティ問題部への付記された追加警告
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 is used to allow a workstation to retrieve mail that the server is holding for it.
これにもかかわらず、これらのより小さいノードに関するメールに対処できるのがしばしば非常に役に立って、それらは、メール取り扱いに関するタスクを支援するためにしばしばユーザエージェント(UA)をサポートします。 この問題、MTS実体が申し出であることを支えることができるノードを解決するために、郵便受けサービスはそれほどノードをこれらに授けませんでした。 ポスト紙オフィスプロトコル--バージョン3(POP3)が、役に立つファッションでワークステーションがサーバー・ホストの上でダイナミックに郵便受けにアクセスすることを許可することを意図します。 通常、これは、POP3がワークステーションがサーバがそれのために保持しているメールを検索するのを許容するのに使用されることを意味します。
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 (this relay host could be, but need not be, the
POP3 server host for the client host).
クライアントホストの上のユーザエージェントがメッセージを輸送システムに入力したがっているとき、それはSMTP接続を中継ホストに確立します(ある必要はないのを除いて、この中継ホストはクライアントホストのためのPOP3サーバー・ホストであるかもしれません)。
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
初めは、サーバー・ホストは、TCPポート110の上で聴くことによって、POP3サービスを始めます。 クライアントホストがサービスを利用したがっているとき、それはサーバー・ホストとのTCP接続を確立します。 接続が確立されるとき、POP3サーバは挨拶を送ります。 クライアント、POP3のサーバの当時の交換命令、および応答
Myers & Rose [Page 2] RFC 1725 POP3 November 1994
マイアーズとローズ[2ページ]RFC1725POP3 November 1994
(respectively) until the connection is closed or aborted.
(それぞれ) 接続が閉店するか、または中止されるまで。
Commands in the POP3 consist of a 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. There are currently two status
indicators: positive ("+OK") and negative ("-ERR").
POP3の応答は追加情報がことによるとあとに続いた自動運転表示灯とキーワードから成ります。 すべての応答がCRLF組によって終えられます。 現在、2つの自動運転表示灯があります: 積極的であって(「+ 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 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 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.
POP3セッションは生涯多くの州を通って進歩をします。 いったんTCP接続が開かれて、POP3サーバが挨拶を送ると、セッションはAUTHORIZATION状態に入ります。 この状態では、クライアントはPOP3サーバに身元を明らかにしなければなりません。クライアントがいったん首尾よくこれをすると、サーバはクライアントの郵便受けに関連しているリソースを取得します、そして、セッションはTRANSACTION状態に入力します。 この状態では、クライアントはPOP3サーバ側の動作を要求します。クライアントがQUITコマンドを発行したとき、セッションはUPDATE状態に入れます。 この状態では、POP3サーバは、TRANSACTION状態の間に取得されたどんなリソースも発表して、さようならを言います。 そして、TCP接続は閉店します。
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
POP3サーバには、不活発自動ログアウト・タイマーがあるかもしれません。 そのようなタイマは少なくとも10分の持続時間のものであるに違いありません。 その間隔の間のクライアントからのどんなコマンドの領収書も、自動ログアウト・タイマーをリセットするために十分であるはずです。 タイマが期限が切れる場合、セッションに入りません。
Myers & Rose [Page 3] RFC 1725 POP3 November 1994
マイアーズとローズ[3ページ]RFC1725POP3 November 1994
the UPDATE state--the server should close the TCP connection without removing any messages or sending any response to the client.
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 string terminated by CRLF. An example might be:
TCP接続がPOP3クライアントによっていったん開かれると、POP3サーバは1つの系列挨拶を発行します。 これはCRLFによって終えられたどんなストリングであるかもしれません。 例は以下の通りです。
S: +OK POP3 server ready
S: +OK POP3サーバ準備ができています。
Note that this greeting is a POP3 reply. The POP3 server should always give a positive response as the greeting.
この挨拶がPOP3回答であることに注意してください。 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. The APOP command is described later in this document.
POP3セッションが現在、AUTHORIZATION状態にあります。 クライアントは、現在、POP3サーバにそれ自体を特定して、認証しなければなりません。これをするための2台の可能なメカニズムがこのドキュメント、USER、PASSコマンド組み合わせ、およびAPOPコマンドで説明されます。 APOPコマンドは後で本書では説明されます。
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サーバが否定的自動運転表示灯(「-間違える」)でユーザコマンドに反応するなら、クライアントは、新しい認証コマンドを発行するか、または辞任コマンドを発行するかもしれません。
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は適切な郵便受けへのアクセスがクライアントに与えられるべきであるかどうか決定すると命令します。
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 the maildrop cannot be opened for some reason (for example, a lock can not be acquired, the client is denied access to the appropriate 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
一度、POP3サーバは、適切な郵便受けへのアクセスをクライアントに与えるべきであり、次に、POP3サーバがセッションがUPDATE状態に入る前に、メッセージが変更されるか、または取り除かれるのを防ぐために必要に応じて郵便受けで排他的なアクセス錠を入手することをどんな認証コマンドの使用目的でも決定したことがあります。 首尾よく錠を入手するなら、POP3サーバは陽性反応インディケータで反応します。 POP3セッションは今、削除されるようにマークされたメッセージなしでTRANSACTION状態に入ります。 ある理由で郵便受けを開くことができないなら(例えば、錠を入手できませんか、適切な郵便受けへのアクセスをクライアントに拒絶できませんか、郵便受けを分析できません)、POP3サーバは否定的自動運転表示灯で反応します。 (錠を入手しましたが、POP3サーバが否定的自動運転表示灯で応じるつもりであるなら、コマンドを拒絶する前に、POP3サーバは錠をリリースしなければなりません。) 否定的自動運転表示灯を返した後に、サーバは閉じるかもしれません。
Myers & Rose [Page 4] RFC 1725 POP3 November 1994
マイアーズとローズ[4ページ]RFC1725POP3 November 1994
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.
接続。 サーバが接続を終えないなら、クライアントが、新しい認証コマンドを発行して、再開するかもしれませんか、またはクライアントは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 n'th message in a maildrop is assigned a message-number of "n". In POP3 commands and responses, all message-number's and message sizes are expressed in base-10 (i.e., decimal).
POP3サーバが郵便受けを開いた後に、それは、メッセージ番号を各メッセージに割り当てて、八重奏における、それぞれのメッセージのサイズに注意します。 メッセージ番号が郵便受けにおける最初のメッセージに割り当てられる、「1インチ、「2インチ、などに、「n」のメッセージ番号は郵便受けでn'thが通信させるそうに割り当てられること」が2番目に割り当てられます。 POP3コマンドと応答では、すべてのメッセージ番号とメッセージサイズはベース-10(すなわち、10進の)で表されます。
Here are summaries for the three POP3 commands discussed thus far:
ここに、これまでのところ議論した3つのPOP3コマンドのための概要があります:
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状態で与えるだけであるかもしれません。
Possible Responses:
+OK name is a valid mailbox
-ERR never heard of mailbox name
可能な応答: + OK名は-ERRがメールボックス名について決して聞かなかった有効なメールボックスです。
Examples:
C: USER mrose
S: +OK mrose is a real hoopy frood
...
C: USER frated
S: -ERR sorry, no mailbox for frated here
例: C: USER mrose S: +OK mroseは本当のhoopy froodです… C: USER frated S: -ERR残念である、どんなメールボックス、もここで、fratedしませんでした。
PASS string
PASSストリング
Arguments:
a server/mailbox-specific password (required)
議論: メールボックスサーバ/特有のパスワード(必要)です。
Restrictions:
may only be given in the AUTHORIZATION state after a
successful USER command
制限: うまくいっているUSERコマンドの後にAUTHORIZATION状態で与えるだけであるかもしれません。
Discussion:
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サーバはパスワードの一部として議論における空間を扱うかもしれません、引数分離子の代わりに。
Myers & Rose [Page 5] RFC 1725 POP3 November 1994
マイアーズとローズ[5ページ]RFC1725POP3 November 1994
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: +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
例: C: USER mrose S: +OK mroseは本当のhoopy frood Cです: PASS秘密S: +OK mroseの郵便受けには、2つのメッセージ(320の八重奏)があります… C: USER mrose S: +OK mroseは本当のhoopy frood Cです: PASS秘密S: -既にロックされたERR郵便受け
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状態に入力します。
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状態で与えるだけであるかもしれません。
Myers & Rose [Page 6] RFC 1725 POP3 November 1994
マイアーズとローズ[6ページ]RFC1725POP3 November 1994
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 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
議論: メッセージ番号(任意の)。(存在しているなら、そのメッセージ番号は削除されるようにマークされたメッセージを示さないかもしれません)。
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.
議論を全く与えないで、POP3サーバが積極的な応答を発行して、次に、与えられた応答がマルチ系列であるなら。
Myers & Rose [Page 7] RFC 1725 POP3 November 1994
マイアーズとローズ[7ページ]RFC1725POP3 November 1994
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.
初期かOKだったことの後に、郵便受けにおける各メッセージに関して、系列がそのメッセージのための情報を含んでいて、POP3サーバは反応します。 また、この系列はそのメッセージのために「スキャンリスト」と呼ばれます。
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.
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
S: 2 200
S: .
...
C: LIST 2
S: +OK 2 200
...
C: LIST 3
S: -ERR no such message, only 2 messages in maildrop
例: C: リストS: + OK2つのメッセージ(320の八重奏)S: 1 120秒間: 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状態で与えるだけであるかもしれません。
Myers & Rose [Page 8] RFC 1725 POP3 November 1994
マイアーズとローズ[8ページ]RFC1725POP3 November 1994
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状態で与えるだけであるかもしれません。
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
議論: なし
Myers & Rose [Page 9] RFC 1725 POP3 November 1994
マイアーズとローズ[9ページ]RFC1725POP3 November 1994
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
with a positive response.
議論: 何かメッセージがPOP3サーバによって削除されるようにマークされたなら、それらは無印です。 そして、POP3サーバは積極的な応答で返答します。
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
議論: なし
Myers & Rose [Page 10] RFC 1725 POP3 November 1994
マイアーズとローズ[10ページ]RFC1725POP3 November 1994
Restrictions: none
制限: なし
Discussion:
The POP3 server removes all messages marked as deleted from
the maildrop. It then releases any exclusive-access lock
on the maildrop and replies as to the status of these
operations. The TCP connection is then closed.
議論: POP3サーバは郵便受けから削除されるようにマークされたすべてのメッセージを取り除きます。 そして、それはこれらの操作の状態に関して郵便受けと回答でのどんな排他的なアクセス錠もリリースします。 そして、TCP接続は閉店します。
Possible Responses:
+OK
可能な応答: + OK
Examples:
C: QUIT
S: +OK dewey POP3 server signing off (maildrop empty)
...
C: QUIT
S: +OK dewey POP3 server signing off (2 messages left)
...
例: C: Sをやめてください: + サインオフする(郵便受け空の)OK dewey POP3サーバ… C: 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
(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
議論: POP3サーバが積極的な応答を発行するなら、与えられた応答はマルチ系列です。 初期かOKだったことの後に、POP3サーバはメッセージ、空白のヘッダーを送ります。
Myers & Rose [Page 11] RFC 1725 POP3 November 1994
マイアーズとローズ[11ページ]RFC1725POP3 November 1994
line separating the headers from the body, and then the
number of lines indicated message's body, being careful to
byte-stuff the termination character (as with all multi-
line responses).
ボディーからのヘッダーを分離して、次に系列の数を切り離す系列はメッセージのボディーを示しました、行終了文字をバイト詰めるのに慎重であることで(すべてのマルチ系列応答のように)。
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
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
例: C: 10秒間の最高1: + OK S: POP3サーバがメッセージのヘッダー、空白行、およびメッセージ欄>Sの最初の10の系列を送る<: . ... C: トップ1003秒間: -ERRはそのようなメッセージではありません。
UIDL [msg]
UIDL[msg]
Arguments:
a message-number (optionally) If a message-number is given,
it 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.
構文解析を簡素化するために、すべてのPOP3サーバがユニークなイドリストに、ある形式を使用するのに必要です。 ユニークなイドリストはシングルスペースがあとに続いたメッセージのメッセージ番号とメッセージのユニークなイドから成ります。
Myers & Rose [Page 12] RFC 1725 POP3 November 1994
マイアーズとローズ[12ページ]RFC1725POP3 November 1994
No information follows the unique-id in the unique-id listing.
どんな情報もユニークなイドリストでユニークなイドに従いません。
The unique-id of a message is an arbitrary server-determined
string, consisting of characters in the range 0x21 to 0x7E,
which uniquely identifies a message within a maildrop and
which persists across sessions. The server should never reuse
an unique-id in a given maildrop, for as long as the entity
using the unique-id exists.
メッセージのユニークなイドは任意のサーバで決定しているストリングです、範囲0x21で0x7E(郵便受けの中で唯一メッセージを特定して、セッションの向こう側に固執している)にキャラクタから成って。 サーバは与えられた郵便受けにおけるユニークなイドを決して再利用するべきではありません、ユニークなイドを使用する実体が存在している限り。
Note that messages marked as deleted are not listed.
削除されるようにマークされたメッセージが記載されていないことに注意してください。
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つのメッセージであるだけではありません。
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
制限: POP3挨拶の後に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分の注文にはセッション開始の間隔があるかもしれません。 したがって、パスワード・キャプチャの危険は大いに高められます。
Myers & Rose [Page 13] RFC 1725 POP3 November 1994
マイアーズとローズ[13ページ]RFC1725POP3 November 1994
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
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クライアントはこのタイムスタンプ、および次に、問題のメモをAPOPコマンドにします。 '名前'パラメタはUSERコマンドの'名前'パラメタに同じ意味論を持っています。 'ダイジェスト'パラメタは、共有秘密キーがあとに続いたタイムスタンプ(角ブラケットを含んでいる)から成るストリングにMD5アルゴリズム[RFC1321]を適用することによって、計算されます。 この共有秘密キーは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キャラクタの例よりかなり長い)。
Myers & Rose [Page 14] RFC 1725 POP3 November 1994
マイアーズとローズ[14ページ]RFC1725POP3 November 1994
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. POP3 Command Summary
8. 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
TRANSACTION州のLIST[msg]RETR msg DELE msg NOOP RSETで有効なSTAT
QUIT valid in the UPDATE state
UPDATE状態で有効なQUIT
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は間違えます。
Myers & Rose [Page 15] RFC 1725 POP3 November 1994
マイアーズとローズ[15ページ]RFC1725POP3 November 1994
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に」 +だけに重要であることに注意してください」と「-間違えてください。」 この回答の後に起こるどんなテキストもクライアントによって無視されるかもしれません。
9. Example POP3 Session
9. 例の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: 次の接続>のための<待ち
10. Message Format
10. メッセージ・フォーマット
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
サーバー・ホストに関するメッセージのための八重奏カウントが地方のコンベンションのため行末を指定するためにそのメッセージに割り当てられた八重奏カウントと異なるかもしれないことに注意するのは重要です。 通常、郵便受けを開くと、POP3セッションのAUTHORIZATION状態の間、POP3サーバは八重奏における、それぞれのメッセージのサイズについて計算できます。 例えば、POP3サーバー・ホストが単独のキャラクタとして内部的に行末を表すなら、POP3サーバは単に重要です。
Myers & Rose [Page 16] RFC 1725 POP3 November 1994
マイアーズとローズ[16ページ]RFC1725POP3 November 1994
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 be counted twice, since the POP3 client will remove all byte- stuffed termination characters when it receives a multi-line response.
2つの八重奏としてのメッセージにおける、このキャラクタの各発生。 メッセージの終了八重奏から始まる系列が二度数えられる必要はないことに注意してください、マルチ系列応答を受けるとき、POP3クライアントがすべてのバイトの詰められた行終了文字を外すので。
11. References
11. 参照
[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月。
12. Security Considerations
12. セキュリティ問題
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 must not allow both methods of access for a given user; that is, for a given "USER name" either the PASS or APOP command is allowed, but not both.
APOPコマンドの使用がPOP3セッションのために発生源識別と反復操作による保護を提供すると推測されます。 それに従って、両方がPASSとAPOPコマンドであると実装するPOP3サーバは与えられたユーザのためのアクセスの両方のメソッドを許容してはいけません。 それは、許容されているPASSかAPOPのどちらかが、命令する与えられた「USER名」のためにありますが、ともにいるというわけではありません。
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.
さもなければ、このメモで安全保障問題について議論しません。
13. Acknowledgements
13. 承認
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 [Page 17] RFC 1725 POP3 November 1994
マイアーズとローズ[17ページ]RFC1725POP3 November 1994
14. Authors' Addresses
14. 作者のアドレス
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 [Page 18]
マイアーズとローズ[18ページ]
一覧
スポンサーリンク
