RFC1460 日本語訳
1460 Post Office Protocol - Version 3. M. Rose. June 1993. (Format: TXT=38827 bytes) (Obsoletes RFC1225) (Obsoleted by RFC1725) (Status: DRAFT STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group M. Rose Request for Comments: 1460 Dover Beach Consulting, Inc. Obsoletes: 1225 June 1993
コメントを求めるワーキンググループM.バラ要求をネットワークでつないでください: コンサルティングInc.が時代遅れにする1460ドーヴァービーチ: 1225 1993年6月
Post Office Protocol - Version 3
POP--バージョン3
Status of this Memo
このMemoの状態
This RFC specifies an IAB standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このRFCはIAB標準化過程プロトコルをインターネットコミュニティに指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態の「IABの公式のプロトコル標準」の現行版を参照してください。 このメモの分配は無制限です。
Overview
概要
This memo is a revision to RFC 1225, a Draft Standard. It makes the following changes from that document:
このメモはRFC1225、Draft Standardへの改正です。 それはそのドキュメントからの以下の変更を行います:
- the RPOP facility is removed;
- RPOP施設を取り除きます。
- the optional APOP facility is added (which is in interoperable, operational use in at least three implementations);
- 任意のAPOP施設は加えられます(少なくとも3つの実装で共同利用できて、操作上使用中です)。
- a typo was corrected with respect to the interaction of LAST and RSET;
- 誤植はLASTとRSETの相互作用に関して修正されました。
- section numbers were added; and,
- セクション番号は加えられました。 そして
- an acknowledgements section was added.
- 承認部は加えられました。
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.
インターネットのあるタイプの、より小さいノードでは、メッセージ輸送システム(MTS)を維持するのはしばしば非実用的です。 例えば、ワークステーションには十分なリソース(サイクル、椎間腔)が、SMTPサーバー[RFC821]と関連ローカルの郵便配達システムが居住しているように保たれて、絶え間なく動いていることを許可するためにないかもしれません。
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").
同様に、長い量の時間の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
これにもかかわらず、これらのより小さいノードに関するメールに対処できるのがしばしば非常に役に立って、それらは、しばしばユーザが支援するエージェント(UA)であるとサポートします。
Rose [Page 1] RFC 1460 POP3 June 1993
ローズ[1ページ]RFC1460POP3 June 1993
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.
メール取り扱いに関するタスク。 この問題、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サーバー・ホストであるかもしれません)。
If this method is followed, then the client host appears to the MTS as a user agent, and should NOT be regarded as a "trusted" MTS entity in any sense whatsoever. This concept, along with the role of the POP3 as a part of a split-UA model is discussed later in this memo.
このメソッドに従うなら、クライアントホストをユーザエージェントとしてMTSにおいて見えて、後でこのメモで分裂-UAモデルの一部について議論するので. POP3の役割に伴うこの概念が何でもであってもどんな意味でも「信じられた」MTS実体と見なすべきではありません。
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 keyword possibly followed by an argument. All commands are terminated by a CRLF pair.
POP3のコマンドは議論がことによるとあとに続いたキーワードから成ります。 すべてのコマンドがCRLF組によって終えられます。
Responses in the POP3 consist of a success indicator and a keyword possibly followed by additional information. All responses are terminated by a CRLF pair. There are currently two success 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
あるコマンドへの応答はマルチ系列です。 これらの場合では、どんな追加系列も送って、それぞれが終わりました。(応答とCRLFの最初の系列を送った後に、場合は以下で明確に示されます)。
Rose [Page 2] RFC 1460 POP3 June 1993
ローズ[2ページ]RFC1460POP3 June 1993
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.
CRLFで、対にしてください。 応答のすべての系列を送ったとき、最終的な系列を送ります、終了八重奏から成って。「(小数が046をインチコード化する、」、)、そして、CRLF組。 何かマルチ系列応答の系列が終了八重奏で始まるなら、系列は未定プレ応答のその系列への終了八重奏で「バイトで、詰められます」。
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.
したがって、マルチ系列応答は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 finished its transactions, 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サーバ側の動作を要求します。クライアントがトランザクションを終えたとき、セッションはUPDATE状態に入れます。 この状態では、POP3サーバは、TRANSACTION状態の間に取得されたどんなリソースも発表して、さようならを言います。 そして、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 issue the USER command. If the POP3 server responds with a positive success indicator ("+OK"), then the client may issue either the PASS command to complete the authorization, or the QUIT command to terminate the POP3 session. If the POP3 server responds with a negative success indicator ("-ERR") to the USER command, then the client may either issue a new USER command or may issue the QUIT command.
POP3セッションが現在、AUTHORIZATION状態にあります。 クライアントは現在、USERコマンドを発行しなければなりません。 POP3サーバが積極的な成功インディケータ(「+ OK」)で反応するなら、クライアントは承認を完成する通過コマンドかPOP3セッションを終える辞任コマンドのどちらかを発行するかもしれません。 POP3サーバが否定的成功インディケータ(「-間違える」)でユーザコマンドに反応するなら、クライアントは、新しいユーザコマンドを発行するか、または辞任コマンドを発行するかもしれません。
Rose [Page 3] RFC 1460 POP3 June 1993
ローズ[3ページ]RFC1460POP3 June 1993
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. If so, the POP3 server then acquires an exclusive-access lock on the maildrop. If the lock is successfully acquired, the POP3 server parses the maildrop into individual messages (read note below), determines the last message (if any) present in the maildrop that was referenced by the RETR command, and responds with a positive success indicator. The POP3 session now enters the TRANSACTION state. If the lock can not be acquired or the client should is denied access to the appropriate maildrop or the maildrop can't be parsed for some reason, the POP3 server responds with a negative success indicator. (If a lock was acquired but the POP3 server intends to respond with a negative success indicator, the POP3 server must release the lock prior to rejecting the command.) At this point, the client may either issue a new USER command and start again, or the client may issue the QUIT command.
クライアントがPASSコマンドを発行するとき、POP3サーバはUSERからの議論組を使用します、そして、PASSは適切な郵便受けへのアクセスがクライアントに与えられるべきであるかどうか決定すると命令します。 そうだとすれば、そして、POP3サーバは郵便受けで排他的なアクセス錠を入手します。 首尾よく錠を入手するなら、POP3サーバは、個々のメッセージ(以下での注意を読む)に郵便受けを分析して、RETRコマンドで参照をつけられた郵便受けにおける現在の最後のメッセージ(もしあれば)を決定して、積極的な成功インディケータで反応します。 POP3セッションは今、TRANSACTION状態に入ります。 ある理由で郵便受けを分析できません、そして、錠を入手できないか、またはクライアントが入手するなら、適切な郵便受けには否定されたアクセスがあるか、またはPOP3サーバは否定的成功インディケータで反応します。 (錠を入手しましたが、POP3サーバが否定的成功インディケータで応じるつもりであるなら、コマンドを拒絶する前に、POP3サーバは錠をリリースしなければなりません。) ここに、クライアントが、新しいUSERコマンドを発行して、再開するかもしれませんか、またはクライアントはQUITコマンドを発行するかもしれません。
NOTE: Minimal implementations of the POP3 need only be able to break a maildrop into its component messages; they need NOT be able to parse individual messages. More advanced implementations may wish to have this capability, for reasons discussed later.
以下に注意してください。 POP3の最小限の器具は郵便受けをコンポーネントメッセージに細かく分けるだけでよいことができます。 彼らは個々のメッセージを分析する必要はないことができます。 より高度な実装には、この能力が後で議論した理由でありたいかもしれません。
After the POP3 server has parsed the maildrop into individual messages, it assigns a message-id to each message, and notes the size of the message in octets. The first message in the maildrop is assigned a message-id of "1", the second is assigned "2", and so on, so that the n'th message in a maildrop is assigned a message-id of "n". In POP3 commands and responses, all message-id's and message sizes are expressed in base-10 (i.e., decimal).
POP3サーバが個々のメッセージに郵便受けを分析した後に、それは、メッセージイドを各メッセージに割り当てて、八重奏における、メッセージのサイズに注意します。 メッセージイドが郵便受けにおける最初のメッセージに割り当てられる、「1インチ、「2インチ、などに、「n」のメッセージイドは郵便受けでn'thが通信させるそうに割り当てられること」が2番目に割り当てられます。 POP3コマンドと応答では、メッセージイドのすべてのものとメッセージサイズはベース-10(すなわち、10進の)で表されます。
It sets the "highest number accessed" to be that of the last message referenced by the RETR command.
それは、「アクセスされた最多数」に最後のメッセージのものであるようにRETRコマンドで参照をつけられて、設定します。
Here are summaries for the three POP3 commands discussed thus far:
ここに、これまでのところ議論した3つのPOP3コマンドのための概要があります:
USER name Arguments: a server specific user-id (required) Restrictions: may only be given in the AUTHORIZATION state after the POP3 greeting or after an unsuccessful USER or PASS command Possible Responses: +OK name is welcome here -ERR never heard of name Examples: C: USER mrose S: +OK mrose is a real hoopy frood
USERはArgumentsを命名します: サーバの特定のユーザID(必要である)制限: POP3挨拶か失敗のUSERかPASSがPossible Responsesを命令した後にAUTHORIZATION状態で与えるだけであるかもしれません: + OK名はここで名前Examplesについて決して聞かれなかった-ERRを歓迎することです: C: USER mrose S: +OK mroseは本当のhoopy froodです。
Rose [Page 4] RFC 1460 POP3 June 1993
ローズ[4ページ]RFC1460POP3 June 1993
... C: USER frated S: -ERR sorry, frated doesn't get his mail here
... C: USER frated S: -ERR残念で、fratedされる、彼のメールをここに受け取りません。
PASS string Arguments: a server/user-id specific password (required) Restrictions: may only be given in the AUTHORIZATION state after a successful USER command Possible Responses: +OK maildrop locked and ready -ERR invalid password -ERR unable to lock maildrop 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 unable to lock mrose's maildrop, file already locked
PASSはArgumentsを結びます: サーバ/ユーザIDの特定のパスワード(必要である)制限: うまくいっているUSERコマンドPossible Responsesの後のAUTHORIZATION状態で与えるだけであるかもしれません: 郵便受けExamplesをロックできない+ OK郵便受けのロックされて持ち合わせの-ERR無効のパスワード-ERR: 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: -mroseの郵便受け、既にロックされたファイルをロックできないERR
QUIT Arguments: none Restrictions: none Possible Responses: +OK Examples: C: QUIT S: +OK dewey POP3 server signing off
議論をやめてください: Restrictionsのいずれも:でない Possible Responsesのいずれも:でない + OKの例: 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 burst 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.
スタット議論: Restrictionsのいずれも:でない TRANSACTION状態で与えるだけであるかもしれません。
Rose [Page 5] RFC 1460 POP3 June 1993
ローズ[5ページ]RFC1460POP3 June 1993
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 first octets present must indicate the number of messages in the maildrop. Following this is 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サーバが低下リストに、ある形式を使用するのに必要です。 最初の八重奏プレゼントは郵便受けにおける、メッセージの数を示さなければなりません。 これに続くのは、八重奏で、郵便受けのサイズです。 このメモは郵便受けサイズに続くことに要件を全く作りません。 最小限の器具は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 Examples: C: STAT S: +OK 2 320
可能な応答: + OK nn mm Examples: C: スタットS: + OK2 320
LIST [msg] Arguments: a message-id (optionally) If a message-id is given, it may NOT refer to a message marked as deleted. Restrictions: may only be given in the TRANSACTION state. Discussion:
[msg]議論を記載してください: それは、メッセージイドであるならメッセージイド(任意に)を与えて、削除されるようにマークされたメッセージを示さないかもしれません。 制限: TRANSACTION状態で与えるだけであるかもしれません。 議論:
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
議論を全く与えないで、POP3サーバが積極的な応答を発行して、次に、与えられた応答がマルチ系列であるなら。 初期かOKだったときにPOP3サーバが系列で郵便受けにおける各メッセージに関して反応させる後
Rose [Page 6] RFC 1460 POP3 June 1993
ローズ[6ページ]RFC1460POP3 June 1993
containing information for that message. This line is called a "scan listing" for that message.
そのメッセージのための情報を含んでいます。 この系列はそのメッセージのために「スキャンリスト」と呼ばれます。
In order to simplify parsing, all POP3 servers are required to use a certain format for scan listings. The first octets present must be the message-id of the message. Following the message-id is the 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 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
可能な応答: + OKスキャンリストはそのようなメッセージの-ERRノーExamplesに続きます: C: リストS: + OK2つのメッセージ(320の八重奏)S: 1 120秒間: 2 200秒間: . ... C: 2秒間、記載してください: + OK2 200… C: 3秒間、記載してください: -ERRはメッセージ、郵便受けでそのような2つのメッセージであるだけではありません。
RETR msg Arguments: a message-id (required) This message-id may NOT refer to a message marked as deleted. Restrictions: may only be given in the TRANSACTION state. Discussion:
RETR msg Arguments: 削除されるようにメッセージにマークされて、このメッセージイドが参照しないかもしれないメッセージイド(必要です)。 制限: TRANSACTION状態で与えるだけであるかもしれません。 議論:
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
POP3サーバが積極的な応答を発行するなら、与えられた応答はマルチ系列です。 イニシャル+OK、POP3メッセージがサーバで相当する後
Rose [Page 7] RFC 1460 POP3 June 1993
ローズ[7ページ]RFC1460POP3 June 1993
given message-id, being careful to byte-stuff the termination character (as with all multi-line responses).
行終了文字をバイト詰めるのに慎重であることで(すべてのマルチ系列応答のように)、メッセージイドを与えます。
If the number associated with this message is higher than the "highest number accessed" in the maildrop, the POP3 server updates the "highest number accessed" to the number associated with this message.
郵便受けでこのメッセージに関連している数が「アクセスされた最多数」より大きいなら、POP3サーバは「アクセスされた最多数」をこのメッセージに関連している数にアップデートします。
Possible Responses: +OK message follows -ERR no such message Examples: C: RETR 1 S: +OK 120 octets S: <the POP3 server sends the entire message here> S: .
可能な応答: + OKメッセージはそのようなメッセージの-ERRノーExamplesに続きます: C: RETR1秒間: + OKの120の八重奏S: POP3サーバが全体を送る<はここで>Sを通信させます: .
DELE msg Arguments: a message-id (required) This message-id may NOT refer to a message marked as deleted. Restrictions: may only be given in the TRANSACTION state. Discussion:
DELE msg Arguments: 削除されるようにメッセージにマークされて、このメッセージイドが参照しないかもしれないメッセージイド(必要です)。 制限: TRANSACTION状態で与えるだけであるかもしれません。 議論:
The POP3 server marks the message as deleted. Any future reference to the message-id 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サーバは実際にメッセージを削除しません。
If the number associated with this message is higher than the "highest number accessed" in the maildrop, the POP3 server updates the "highest number accessed" to the number associated with this message.
郵便受けでこのメッセージに関連している数が「アクセスされた最多数」より大きいなら、POP3サーバは「アクセスされた最多数」をこのメッセージに関連している数にアップデートします。
Possible Responses: +OK message deleted -ERR no such message Examples: C: DELE 1 S: +OK message 1 deleted ... C: DELE 2 S: -ERR message 2 already deleted
可能な応答: + OKそのようなメッセージのメッセージの削除された-ERRノーExamples: C: DELE1秒間: + 1が削除したOKメッセージ… C: DELE2秒間: -既に削除されたERRメッセージ2
NOOP Arguments: none Restrictions: may only be given in the TRANSACTION state.
NOOP議論: Restrictionsのいずれも:でない TRANSACTION状態で与えるだけであるかもしれません。
Rose [Page 8] RFC 1460 POP3 June 1993
ローズ[8ページ]RFC1460POP3 June 1993
Discussion:
議論:
The POP3 server does nothing, it merely replies with a positive response.
それは、積極的な応答でPOP3サーバが何もしないと単に返答します。
Possible Responses: +OK Examples: C: NOOP S: +OK
可能な応答: + OKの例: C: NOOP S: + OK
LAST Arguments: none Restrictions: may only be issued in the TRANSACTION state. Discussion:
最後の議論: Restrictionsのいずれも:でない TRANSACTION状態で発行されるだけであるかもしれません。 議論:
The POP3 server issues a positive response with a line containing the highest message number which accessed. Zero is returned in case no message in the maildrop has been accessed during previous transactions. A client may thereafter infer that messages, if any, numbered greater than the response to the LAST command are messages not yet accessed by the client.
POP3サーバは系列が最も高いメッセージを含んでいる応答がアクセスされていた状態でどれに付番するかを確信しているaを発行します。 郵便受けにおけるメッセージが全く前のトランザクションの間、アクセスされていないといけないので、ゼロは返されます。 クライアントは、その後、もしあれば付番されたLASTコマンドへの応答よりすばらしいメッセージがクライアントによってまだアクセスされていなかったメッセージであると推論するかもしれません。
Possible Response: +OK nn
可能な応答: + OK nn
Examples: C: STAT S: +OK 4 320 C: LAST S: +OK 1 C: RETR 3 S: +OK 120 octets S: <the POP3 server sends the entire message here> S: . C: LAST S: +OK 3 C: DELE 2 S: +OK message 2 deleted C: LAST S: +OK 3 C: RSET S: +OK C: LAST S: +OK 0
例: C: スタットS: + OK4 320C: 最終S: + 1CのOK: RETR3秒間: + OKの120の八重奏S: POP3サーバが全体を送る<はここで>Sを通信させます: . C: 最終S: + 3CのOK: DELE2秒間: + OKメッセージ2はCを削除しました: 最終S: + 3CのOK: RSET S: + OK C: 最終S: + OK0
Rose [Page 9] RFC 1460 POP3 June 1993
ローズ[9ページ]RFC1460POP3 June 1993
RSET Arguments: none Restrictions: may only be given in the TRANSACTION state. Discussion:
RSET議論: Restrictionsのいずれも:でない TRANSACTION状態で与えるだけであるかもしれません。 議論:
If any messages have been marked as deleted by the POP3 server, they are unmarked. The POP3 server then replies with a positive response. In addition, the "highest number accessed" is also reset to zero.
何かメッセージがPOP3サーバによって削除されるようにマークされたなら、それらは無印です。 そして、POP3サーバは積極的な応答で返答します。 また、さらに、「アクセスされた最多数」はゼロにリセットされます。
Possible Responses: +OK Examples: C: RSET S: +OK maildrop has 2 messages (320 octets)
可能な応答: + OKの例: 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状態に入らないことに注意してください。)
QUIT Arguments: none Restrictions: none Discussion:
議論をやめてください: Restrictionsのいずれも:でない Discussionのいずれも:でない
The POP3 server removes all messages marked as deleted from the maildrop. It then releases the exclusive-access lock on the maildrop and replies as to the success of these operations. The TCP connection is then closed.
POP3サーバは郵便受けから削除されるようにマークされたすべてのメッセージを取り除きます。 そして、それは郵便受けと回答のときにこれらの操作の成功に関して排他的なアクセス錠をリリースします。 そして、TCP接続は閉店します。
Possible Responses: +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) ...
可能な応答: + OKの例: C: Sをやめてください: + サインオフする(郵便受け空の)OK dewey POP3サーバ… C: Sをやめてください: + サインオフするOK dewey POP3サーバ(あと2つのメッセージ)…
Rose [Page 10] RFC 1460 POP3 June 1993
ローズ[10ページ]RFC1460POP3 June 1993
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 Arguments: a message-id (required) and a number. This message-id may NOT refer to a message marked as deleted. Restrictions: may only be given in the TRANSACTION state. Discussion:
TOP msg n Arguments: メッセージイド(必要である)と数。 このメッセージイドは削除されるようにマークされたメッセージを示さないかもしれません。 制限: TRANSACTION状態で与えるだけであるかもしれません。 議論:
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 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 Examples: C: TOP 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 S: -ERR no such message
可能な応答: + メッセージのOK先端はそのようなメッセージの-ERRノーExamplesに続きます: C: 最高10秒間: + OK S: POP3サーバがメッセージのヘッダー、空白行、およびメッセージ欄>Sの最初の10の系列を送る<: . ... C: トップ100S: -ERRはそのようなメッセージではありません。
Rose [Page 11] RFC 1460 POP3 June 1993
ローズ[11ページ]RFC1460POP3 June 1993
APOP name digest Arguments: a server specific user-id and a digest string (both required). Restrictions: may only be given in the AUTHORIZATION state after the POP3 greeting Discussion:
APOPはダイジェストArgumentsを命名します: サーバの特定のユーザIDとダイジェストは(必要である両方)を結びます。 制限: POP3挨拶Discussionの後のAUTHORIZATION状態で与えるだけであるかもしれません:
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 secret. This
POP3クライアントはこのタイムスタンプ、および次に、問題のメモをAPOPコマンドにします。 「名前」パラメタはUSERコマンドの「名前」パラメタに同じ意味論を持っています。 「ダイジェスト」パラメタは、共有秘密キーがあとに続いたタイムスタンプ(角ブラケットを含んでいる)から成るストリングにMD5アルゴリズム[RFC1321]を適用することによって、計算されます。 これ
Rose [Page 12] RFC 1460 POP3 June 1993
ローズ[12ページ]RFC1460POP3 June 1993
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州に残っています。
Possible Responses: +OK maildrop locked and ready -ERR permission denied Examples: S: +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us> C: APOP mrose c4c9334bac560ecc979e58001b3e22fb S: +OK maildrop has 1 message (369 octets)
可能な応答: + OKのロックされて持ち合わせのExamplesが否定された郵便受け-ERR許可: 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 "tanstaaf". Hence, the MD5 algorithm is applied to the string
この例では、共有秘密キーはストリング"tanstaaf"です。 したがって、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: USER name valid in the AUTHORIZATION state PASS string QUIT
最小量のPOP3は命令します: AUTHORIZATION州のPASSストリングQUITで妥当なUSER名
STAT valid in the TRANSACTION state LIST [msg] RETR msg DELE msg NOOP LAST RSET
TRANSACTION州のLIST[msg]RETR msg DELE msg NOOP LAST RSETで有効なSTAT
Rose [Page 13] RFC 1460 POP3 June 1993
ローズ[13ページ]RFC1460POP3 June 1993
QUIT valid in the UPDATE state
UPDATE状態で有効なQUIT
Optional POP3 Commands: APOP name digest valid in the AUTHORIZATION state
任意のPOP3は命令します: AUTHORIZATION状態で有効なAPOP名前ダイジェスト
TOP msg n valid in the TRANSACTION state
TRANSACTION状態で有効なTOP msg n
POP3 Replies: +OK -ERR
POP3は返答します: +OKは間違えます。
Note that with the exception of the STAT command, 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コマンドを除いて、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: 次の接続>のための<待ち
Rose [Page 14] RFC 1460 POP3 June 1993
ローズ[14ページ]RFC1460POP3 June 1993
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 byte 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 client can calculate the size of each message in octets when it parses the maildrop into messages. 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 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クライアントがすべてのバイトで詰められた行終了文字を外すので。
11. The POP and the Split-UA model
11. POPとSplit-UAモデル
The underlying paradigm in which the POP3 functions is that of a split-UA model. The POP3 client host, being a remote PC based workstation, acts solely as a client to the message transport system. It does not provide delivery/authentication services to others. Hence, it is acting as a UA, on behalf of the person using the workstation. Furthermore, the workstation uses SMTP to enter mail into the MTS.
POP3が機能する基本的なパラダイムは分裂-UAモデルのものです。 リモートPCに基づいているワークステーションでありPOP3クライアントホストは唯一クライアントとしてメッセージ輸送システムに務めます。 それは他のものへの配送/認証サービスを提供しません。 したがって、それはワークステーションを使用している人を代表してUAとして機能しています。 その上、ワークステーションは、メールをMTSに入力するのにSMTPを使用します。
In this sense, we have two UA functions which interface to the message transport system: Posting (SMTP) and Retrieval (POP3). The entity which supports this type of environment is called a split-UA (since the user agent is split between two hosts which must interoperate to provide these functions).
この意味で、私たちには、メッセージ輸送システムに接続する2つのUA機能があります: (SMTP)と検索(POP3)を掲示します。 このタイプの環境をサポートする実体は分裂-UAと呼ばれます(ユーザエージェントが2人のホストの間で分けられるので(これらの機能を提供するために共同利用しなければなりません))。
ASIDE: Others might term this a remote-UA instead. There are arguments supporting the use of both terms.
傍らに: 他のもの力の用語、代わりにこのaリモートUA。 両方の用語の使用をサポートする議論があります。
This memo has explicitly referenced TCP as the underlying transport agent for the POP3. This need not be the case. In the MZnet split- UA, for example, personal micro-computer systems are used which do not have IP-style networking capability [MZnet]. To connect to the POP3 server host, a PC establishes a terminal connection using some simple protocol (PhoneNet). A program on the PC drives the connection, first establishing a login session as a normal user. The login shell for this pseudo-user is a program which drives the other half of the terminal protocol and communicates with one of two servers. Although MZnet can support several PCs, a single pseudo- user login is present on the server host. The user-id and password
このメモはPOP3の基本的な輸送エージェントとして明らかにTCPに参照をつけました。 これはそうである必要はありません。 例えば、MZnet分裂UAパーソナルマイコンシステムは使用されています(IP-スタイルが能力[MZnet]をネットワークでつなぎながら、ありません)。 POP3サーバー・ホストに接するために、PCは何らかの簡単なプロトコル(PhoneNet)を使用することで端末の接続を確立します。 最初に普通のユーザとログインセッションを書き立てて、PCの上のプログラムは接続を運転します。 この疑似ユーザのためのログインシェルは端末プロトコルのもう片方の半分を追い立てて、2つのサーバの1つとコミュニケートするプログラムです。 MZnetは、いくつかのPC、シングルが疑似ユーザであるとサポートすることができますが、ログインはサーバー・ホストに存在しています。 ユーザIDとパスワード
Rose [Page 15] RFC 1460 POP3 June 1993
ローズ[15ページ]RFC1460POP3 June 1993
for this pseudo-user login is known to all members of MZnet. Hence, the first action of the login shell, after starting the terminal protocol, is to demand a USER/PASS authorization pair from the PC. This second level of authorization is used to ascertain who is interacting with the MTS. Although the server host is deemed to support a "trusted" MTS entity, PCs in MZnet are not. Naturally, the USER/PASS authorization pair for a PC is known only to the owner of the PC (in theory, at least).
この疑似ユーザに関しては、ログインはすべてのメンバーにとってMZnetを知られています。 したがって、ログインシェルの最初の作用は端末プロトコルを始めた後にPCからのUSER/PASS承認組を要求することです。 この第2レベルの承認は、だれがMTSと対話しているかを確かめるのに使用されます。 サーバー・ホストが「信じられた」MTS実体をサポートすると考えられますが、MZnetのPCは考えられるというわけではありません。 当然、PCのためのUSER/PASS承認組は所有者だけにおいてPC(理論で少なくとも)を知られています。
After successfully verifying the identity of the client, a modified SMTP server is started, and the PC posts mail with the server host. After the QUIT command is given to the SMTP server and it terminates, a modified POP3 server is started, and the PC retrieves mail from the server host. After the QUIT command is given to the POP3 server and it terminates, the login shell for the pseudo-user terminates the terminal protocol and logs the job out. The PC then closes the terminal connection to the server host.
首尾よくクライアントのアイデンティティについて確かめた後に、変更されたSMTPサーバーは、始められてサーバー・ホストがいるPCポストメールです。 QUITコマンドをSMTPサーバーに与えて、終わった後に、変更されたPOP3サーバは始められます、そして、PCはサーバー・ホストからのメールを検索します。 QUITコマンドをPOP3サーバに与えて、終わった後に、疑似ユーザのためのログインシェルは、端末プロトコルを終えて、仕事をログアウトします。 そして、PCは端末の接続をサーバー・ホストに終えます。
The SMTP server used by MZnet is modified in the sense that it knows that it's talking to a user agent and not a "trusted" entity in the message transport system. Hence, it does performs the validation activities normally performed by an entity in the MTS when it accepts a message from a UA.
MZnetによって使用されたSMTPサーバーはメッセージ輸送システムで「信じられた」実体ではなく、ユーザエージェントと話しているのを知っているという意味で変更されます。 したがって、それは実行します。通常、それがUAからメッセージを受け入れるMTSの実体によって実行された合法化活動を実行します。
The POP3 server used by MZnet is modified in the sense that it does not require a USER/PASS combination before entering the TRANSACTION state. The reason for this (of course) is that the PC has already identified itself during the second-level authorization step described above.
MZnetによって使用されたPOP3サーバはTRANSACTION状態に入る前にUSER/PASS組み合わせを必要としないという意味で変更されます。 この理由は(もちろん)PCが上で説明された第2レベル承認ステップの間既にそれ自体を特定しているということです。
NOTE: Truth in advertising laws require that the author of this memo state that MZnet has not actually been fully implemented. The concepts presented and proven by the project led to the notion of the MZnet split-slot model. This notion has inspired the split-UA concept described in this memo, led to the author's interest in the POP, and heavily influenced the the description of the POP3 herein.
以下に注意してください。 広告法規による真実は、このメモの作者が、MZnetが実際に完全に実装されるというわけではなかったと述べるのを必要とします。 プロジェクトによって提示されて、証明された概念はMZnet分裂スロットモデルの概念につながりました。 この概念は、このメモで説明された分裂-UA概念を奮い立たせて、POPへの作者の関心につながって、大いにここにPOP3の記述に影響を及ぼしました。
In fact, some UAs present in the Internet already support the notion of posting directly to an SMTP server and retrieving mail directly from a POP3 server, even if the POP3 server and client resided on the same host!
事実上、インターネットの現在のいくつかのUAsが既に、直接SMTPサーバーに郵送して、直接POP3サーバからのメールを検索するという概念をサポートします、POP3サーバとクライアントが同じホストの上に住んだとしても!
ASIDE: this discussion raises an issue which this memo purposedly avoids: how does SMTP know that it's talking to a "trusted" MTS entity?
傍らに: この議論はこのメモが目的的に避ける問題を提起します: SMTPは、それがどのように「信じられた」MTS実体と話しているのを知っていますか?
Rose [Page 16] RFC 1460 POP3 June 1993
ローズ[16ページ]RFC1460POP3 June 1993
12. References
12. 参照
[MZnet] Stefferud, E., Sweet, J., and T. Domae, "MZnet: Mail Service for Personal Micro-Computer Systems,: Proceedings, IFIP 6.5 International Conference on Computer Message Systems, Nottingham, U.K., May 1984.
E.の、そして、甘い[MZnet]Stefferud、J.、およびT.Domae、「MZnet:」 パーソナルマイコンシステムのためのサービスを郵送してください、: 議事(コンピュータメッセージシステムに関するIFIP6.5国際会議、ノッティンガム、イギリス)は1984がそうするかもしれません。
[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", MIT Laboratory for Computer Science, April 1992.
1992年4月のR. [RFC1321]Rivest、「MD5メッセージダイジェストアルゴリズム」MITコンピュータサイエンス研究所。
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 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名」のためにありますが、ともにいるというわけではありません。
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 [RFC1225], POP3 is based on the ideas presented in RFCs 918, 937, and 1081.
POPファミリーには、長くて市松模様の歴史があります。 主として[RFC1225]への小さい方の改正ですが、POP3はRFCs918、937、および1081年に提示された考えに基づいています。
In addition, Alfred Grimstad, Keith McCloghrie, and Neil Ostroff provided significant comments on the APOP command.
さらに、アルフレッド・グリムスター、キースMcCloghrie、およびニールOstroffはAPOPコマンドの重要なコメントを提供しました。
15. Author's Address
15. 作者のアドレス
Marshall T. Rose Dover Beach Consulting, Inc. Mountain View, CA 94043-2186
Inc.マウンテンビュー、カリフォルニア94043-2186に相談するマーシャル・T.バラドーヴァービーチ
Phone: +1 415 968 1052 Fax: +1 415 968 2510
以下に電話をしてください。 +1 415 968、1052Fax: +1 415 968 2510
EMail: mrose@dbc.mtview.ca.us X.500: rose, dbc, us
メール: mrose@dbc.mtview.ca.us X.500: バラ、dbc、私たち
Rose [Page 17]
上昇しました。[17ページ]
一覧
スポンサーリンク