RFC1081 日本語訳
1081 Post Office Protocol: Version 3. M.T. Rose. November 1988. (Format: TXT=37009 bytes) (Obsoleted by RFC1225) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group M. Rose
Request for Comments: 1081 TWG
November 1988
コメントを求めるワーキンググループM.バラ要求をネットワークでつないでください: 1081 TWG1988年11月
Post Office Protocol - Version 3
POP--バージョン3
Status of this Memo
このMemoの状態
This memo suggests a simple method for workstations to dynamically access mail from a mailbox server. This RFC specifies a proposed protocol for the Internet community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このメモはワークステーションがメールボックスサーバからメールにダイナミックにアクセスする簡単なメソッドを示します。このRFCは提案されたプロトコルをインターネットコミュニティに指定して、改良のために議論と提案を要求します。 このメモの分配は無制限です。
This memo is based on RFC 918 (since revised as RFC 937). Although similar in form to the original Post Office Protocol (POP) proposed for the Internet community, the protocol discussed in this memo is similar in spirit to the ideas investigated by the MZnet project at the University of California, Irvine.
このメモはRFC918に基づいています(RFC937として改訂されるので)。 フォームにおいてインターネットコミュニティのために提案されたオリジナルのポストオフィスプロトコル(POP)と同様ですが、このメモで議論したプロトコルは精神においてカリフォルニア大学アーバイン校のMZnetプロジェクトによって調査された考えと同様です。
Further, substantial work was done on examining POP in a PC-based environment. This work, which resulted in additional functionality in this protocol, was performed by the ACIS Networking Systems Group at Stanford University. The author gratefully acknowledges their interest.
さらに、PCベースの環境でPOPを調べるとき、かなりの仕事をしました。 この仕事(このプロトコルの追加機能性をもたらした)がスタンフォード大学でアーキスNetworking Systems Groupによって行われました。 作者は感謝して彼らの関心を承認します。
Introduction
序論
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 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サーバーと関連ローカルの郵便配達システムが居住しているように保たれて、絶え間なく動いていることを許可するためにないかもしれません。 同様に、長い量の時間の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がワークステーションがサーバがそれのために保持しているメールを検索するのを許容するのに使用されることを意味します。
Rose [Page 1] RFC 1081 POP3 November 1988
ローズ[1ページ]RFC1081POP3 November 1988
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がそれの申し出を修理するホストについて言及しますが。
A Short Digression
短い脱線
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実体と見なすべきではありません。
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 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
あるコマンドへの応答はマルチ系列です。 これらの場合では、どんな追加系列も送ります、CRLF組によって終えられたそれぞれ。(応答とCRLFの最初の系列を送った後に、場合は以下で明確に示されます)。 応答のすべての系列を送ったとき、最終的な系列を送ります、終了八重奏から成って。「(小数が046をインチコード化する、」、)、そして、CRLF組。 何かマルチ系列応答の系列が終了八重奏で始まるなら、系列は未定プレ応答のその系列への終了八重奏で「バイトで、詰められます」。 したがって、マルチ系列応答は5つの八重奏"CRLF.CRLF"と共に終えられます。 マルチ系列応答を調べるとき、クライアントは、系列が終了八重奏で始まるかどうか確認するためにチェックします。 そうだとすれば、CRLF以外の八重奏が続くなら、系列(終了八重奏)の最初の八重奏ははがれます。 そうだとすれば、CRLFである、すぐに。
Rose [Page 2] RFC 1081 POP3 November 1988
ローズ[2ページ]RFC1081POP3 November 1988
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.
続き、行終了文字、次に、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接続は閉店します。
The AUTHORIZATION State
承認状態
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 dewey POP3 server ready (Comments to: PostMaster@UDEL.EDU)
S.+OK dewey POP3サーバ準備ができています。(: PostMaster@UDEL.EDU へのコメント)
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サーバが否定的成功インディケータ(「-間違える」)でユーザコマンドに反応するなら、クライアントは、新しいユーザコマンドを発行するか、または辞任コマンドを発行するかもしれません。
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
クライアントがPASSコマンドを発行するとき、POP3サーバはUSERからの議論組を使用します、そして、PASSは適切な郵便受けへのアクセスがクライアントに与えられるべきであるかどうか決定すると命令します。 そうだとすれば、そして、POP3サーバは郵便受けで排他的なアクセス錠を入手します。 首尾よく錠を入手するなら、POP3サーバは、個々のメッセージ(以下での注意を読む)に郵便受けを分析して、RETRコマンドで参照をつけられた郵便受けにおける現在の最後のメッセージ(もしあれば)を決定して、積極的な成功インディケータで反応します。 POP3セッションは今、TRANSACTION状態に入ります。 錠を入手できないか、またはクライアントが入手するなら、適切な郵便受けには否定されたアクセスがあることができませんか、いくつかのために郵便受けは分析できません。
Rose [Page 3] RFC 1081 POP3 November 1988
ローズ[3ページ]RFC1081POP3 November 1988
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.
推論してください、そして、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
...
C: USER frated
S: -ERR sorry, frated doesn't get his mail here
USERはArgumentsを命名します: サーバの特定のユーザID(必要である)制限: POP3挨拶か失敗のUSERかPASSがPossible Responsesを命令した後にAUTHORIZATION状態で与えるだけであるかもしれません: + OK名はここで名前Examplesについて決して聞かれなかった-ERRを歓迎することです: C: USER mrose S: +OK mroseは本当のhoopy froodです… 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
PASSはArgumentsを結びます: サーバ/ユーザIDの特定のパスワード(必要である)制限: うまくいっているUSERコマンドPossible Responsesの後のAUTHORIZATION状態で与えるだけであるかもしれません: + OKの郵便受けロックされて持ち合わせの-ERR無効のパスワード
Rose [Page 4] RFC 1081 POP3 November 1988
ローズ[4ページ]RFC1081POP3 November 1988
-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
-郵便受けExamplesをロックできない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サーバ
The TRANSACTION State
トランザクション状態
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.
Discussion:
スタット議論: Restrictionsのいずれも:でない TRANSACTION状態で与えるだけであるかもしれません。 議論:
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
構文解析を簡素化するために、すべてのPOP3サーバが低下リストに、ある形式を使用するのに必要です。 最初の八重奏プレゼントは郵便受けにおける、メッセージの数を示さなければなりません。 これに続くのは、サイズです。
Rose [Page 5] RFC 1081 POP3 November 1988
ローズ[5ページ]RFC1081POP3 November 1988
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.
八重奏における郵便受けについて。 このメモは郵便受けサイズに続くことに要件を全く作りません。 最小限の器具は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
containing information for that message. This line
is called a "scan listing" for that message.
議論を全く与えないで、POP3サーバが積極的な応答を発行して、次に、与えられた応答がマルチ系列であるなら。 初期かOKだったことの後に、郵便受けにおける各メッセージに関して、系列がそのメッセージのための情報を含んでいて、POP3サーバは反応します。 この系列はそのメッセージのために「スキャンリスト」と呼ばれます。
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
構文解析を簡素化するために、すべてのPOP3サーバがスキャンリストに、ある形式を使用するのに必要です。 最初の八重奏プレゼントはメッセージのメッセージイドであるに違いありません。 メッセージイドに従うのは、八重奏で、メッセージのサイズです。 このメモはスキャンリストでメッセージサイズに続くことに要件を全く作りません。 最小限の器具はその系列をただ終わらせるべきです。
Rose [Page 6] RFC 1081 POP3 November 1988
ローズ[6ページ]RFC1081POP3 November 1988
the response with a CRLF pair. More advanced
implementations may include other information, as
parsed from the message.
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
given message-id, being careful to byte-stuff the
termination character (as with all multi-line
responses).
POP3サーバが積極的な応答を発行するなら、与えられた応答はマルチ系列です。 初期かOKだったことの後に、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サーバは「アクセスされた最多数」をこのメッセージに関連している数にアップデートします。
Rose [Page 7] RFC 1081 POP3 November 1988
ローズ[7ページ]RFC1081POP3 November 1988
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.
Discussion:
NOOP議論: Restrictionsのいずれも:でない TRANSACTION状態で与えるだけであるかもしれません。 議論:
The POP3 server does nothing, it merely replies with a
positive response.
それは、積極的な応答でPOP3サーバが何もしないと単に返答します。
Possible Responses:
+OK
可能な応答: + OK
Rose [Page 8] RFC 1081 POP3 November 1988
ローズ[8ページ]RFC1081POP3 November 1988
Examples:
C: NOOP
S: +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 1
例: 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: + OK1
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
POP3によって削除されるように何かメッセージがマークされたなら
Rose [Page 9] RFC 1081 POP3 November 1988
ローズ[9ページ]RFC1081POP3 November 1988
server, they are unmarked. The POP3 server then
replies with a positive response. In addition, the
"highest number accessed" is also reset to the value
determined at the beginning of the POP3 session.
サーバ、それらは無印です。 そして、POP3サーバは積極的な応答で返答します。 また、さらに、「アクセスされた最多数」はPOP3セッションの始めに決定している値にリセットされます。
Possible Responses:
+OK
Examples:
C: RSET
S: +OK maildrop has 2 messages (320 octets)
可能な応答: + OKの例: C: RSET S: + OK郵便受けには、2つのメッセージがあります。(320の八重奏)
The UPDATE State
アップデート状態
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つのメッセージ)…
Optional POP3 Commands
任意のPOP3コマンド
The POP3 commands discussed above must be supported by all minimal implementations of POP3 servers.
POP3サーバのすべての最小限の器具で上で議論したPOP3コマンドをサポートしなければなりません。
Rose [Page 10] RFC 1081 POP3 November 1988
ローズ[10ページ]RFC1081POP3 November 1988
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はそのようなメッセージではありません。
RPOP user
Arguments: a client specific user-id (required)
Restrictions: may only be given in the AUTHORIZATION
state after a successful USER command; in addition,
may only be given if the client used a reserved
RPOPユーザArguments: クライアントの特定のユーザID(必要である)制限: うまくいっているUSERコマンドの後にAUTHORIZATION状態で与えるだけであるかもしれません。 さらに、クライアントが予約されたaを使用した場合にだけ、与えるかもしれません。
Rose [Page 11] RFC 1081 POP3 November 1988
ローズ[11ページ]RFC1081POP3 November 1988
(privileged) TCP port to connect to the server.
Discussion:
. 議論をサーバに接続する(特権がある)のTCPポート:
The RPOP command may be used instead of the PASS
command to authenticate access to the maildrop. In
order for this command to be successful, the POP3
client must use a reserved TCP port (port < 1024) to
connect tothe server. The POP3 server uses the
argument pair from the USER and RPOP commands to
determine if the client should be given access to
the appropriate maildrop. Unlike the PASS command
however, the POP3 server considers if the remote user
specified by the RPOP command who resides on the POP3
client host is allowed to access the maildrop for the
user specified by the USER command (e.g., on Berkeley
UNIX, the .rhosts mechanism is used). With the
exception of this differing in authentication, this
command is identical to the PASS command.
RPOPコマンドは郵便受けへのアクセスを認証するPASSコマンドの代わりに使用されるかもしれません。 うまくいくこのコマンドにおいて整然とします、POP3クライアントはtotheサーバを接続するのに、予約されたTCPポート(<1024を移植する)を使用しなければなりません。POP3サーバはUSERからの議論組を使用します、そして、RPOPは適切な郵便受けへのアクセスがクライアントに与えられるべきであるかどうか決定すると命令します。 しかしながら、PASSコマンドと異なって、POP3サーバは、リモート・ユーザーがRPOPコマンドで指定したならだれがPOP3クライアントホストの上に住んでいるかがUSERコマンドで指定されたユーザのために郵便受けにアクセスできる(例えば、バークレーUNIXでは、.rhostsメカニズムは使用されている)と考えます。 認証におけるこの相違を除いて、このコマンドはPASSコマンドと同じです。
Note that the use of this feature has allowed much wider
penetration into numerous hosts on local networks (and
sometimes remote networks) by those who gain illegal
access to computers by guessing passwords or otherwise
breaking into the system.
この特徴の使用が企業内情報通信網(そして、時々リモートなネットワーク)にパスワードを推測するか、またはそうでなければ、システムに侵入することによってコンピュータへの不法なアクセスを得る人ではるかに広い侵入を多数のホストに許容したことに注意してください。
Possible Responses:
+OK maildrop locked and ready
-ERR permission denied
Examples:
C: USER mrose
S: +OK mrose is a real hoopy frood
C: RPOP mrose
S: +OK mrose's maildrop has 2 messages (320
octets)
可能な応答: + OKのロックされて持ち合わせのExamplesが否定された郵便受け-ERR許可: C: USER mrose S: +OK mroseは本当のhoopy frood Cです: RPOP mrose S: +OK mroseの郵便受けには、2つのメッセージがあります。(320の八重奏)
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 12] RFC 1081 POP3 November 1988
ローズ[12ページ]RFC1081POP3 November 1988
QUIT valid in the UPDATE state
UPDATE状態で有効なQUIT
Optional POP3 Commands:
RPOP user valid in the AUTHORIZATION state
任意のPOP3は命令します: AUTHORIZATION状態で有効なRPOPユーザ
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に」 +だけに重要であることに注意してください」と「-間違えてください。」 この回答の後に起こるどんなテキストもクライアントによって無視されるかもしれません。
Example POP3 Session
例のPOP3セッション
S: <wait for connection on TCP port 110>
...
C: <open connection>
S: +OK dewey POP3 server ready (Comments to: PostMaster@UDEL.EDU)
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: 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: TCPポート110>における接続のための<待ち… C: <の開いている接続>S: + OKのdewey POP3サーバ持ち合わせ(: PostMaster@UDEL.EDU へのコメント)のC: USER mrose S: +OK mroseは本当のhoopy frood Cです: PASS秘密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を削除しました: やめてください。
Rose [Page 13] RFC 1081 POP3 November 1988
ローズ[13ページ]RFC1081POP3 November 1988
S: +OK dewey POP3 server signing off (maildrop empty)
C: <close connection>
S: <wait for next connection>
S: + (郵便受け空)のCに調印されるOK dewey POP3サーバ: <浅からぬ関係>S: 次の接続>のための<待ち
Message Format
メッセージ・フォーマット
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クライアントがすべてのバイトで詰められた行終了文字を外すので。
The POP and the Split-UA model
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. 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
このメモはPOP3の基本的な輸送エージェントとして明らかにTCPに参照をつけました。 これはそうである必要はありません。 例えば、MZnet分裂UAパーソナルマイコンシステムは使用されています(IP-スタイルが能力をネットワークでつなぎながら、ありません)。 POP3サーバー・ホストに接するために、PCは何らかの簡単なプロトコル(PhoneNet)を使用することで端末の接続を確立します。 最初に普通のユーザとログインセッションを書き立てて、PCの上のプログラムは接続を運転します。 ログインシェル
Rose [Page 14] RFC 1081 POP3 November 1988
ローズ[14ページ]RFC1081POP3 November 1988
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 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).
この疑似ユーザが端末プロトコルのもう片方の半分を追い立てて、2つのサーバの1つとコミュニケートするプログラムであるので。 MZnetはいくつかのPCをサポートすることができますが、ただ一つの疑似ユーザログインはサーバー・ホストに存在しています。 この疑似ユーザログインのためのユーザIDとパスワードはすべてのメンバーにとって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 POP server, even if the POP server and client resided on the same host!
事実上、インターネットの現在のいくつかのUAsが既に、直接SMTPサーバーに郵送して、直接POPサーバからのメールを検索するという概念をサポートします、POPサーバとクライアントが同じホストの上に住んだとしても!
ASIDE: this discussion raises an issue which this memo
傍らに: この議論が問題を提起する、どれ、このメモ
Rose [Page 15] RFC 1081 POP3 November 1988
ローズ[15ページ]RFC1081POP3 November 1988
purposedly avoids: how does SMTP know that it's talking
to a "trusted" MTS entity?
目的は以下を避けます。 SMTPは、それがどのように「信じられた」MTS実体と話しているのを知っていますか?
References
参照
[MZnet] Stefferud, E., J. Sweet, 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.
[MZnet]Stefferud、E.、J.甘い、そして、T.Domae、「MZnet:」 「パーソナルマイコンシステムのためのメールサービス」(議事、コンピュータメッセージシステムに関するIFIP6.5国際会議、ノッティンガム、イギリス)は1984がそうするかもしれません。
[RFC821] Postel, J., "Simple Mail Transfer Protocol",
USC/Information Sciences Institute, August 1982.
[RFC821] ポステル、J.、「簡単なメール転送プロトコル」とUSC/情報科学は、1982年8月に設けます。
[RFC822] Crocker, D., "Standard for the Format of ARPA-Internet
Text Messages", University of Delaware, August 1982.
[RFC822] クロッカー、D.、「アルパインターネットテキスト・メッセージの形式の規格」、デラウエア大学、1982年8月。
[RFC937] Butler, M., J. Postel, D. Chase, J. Goldberger, and J.
Reynolds, "Post Office Protocol - Version 2", RFC 937,
USC/Information Sciences Institute, February 1985.
[RFC937] バトラー、M.、J.ポステル、D.チェイス、J.Goldberger、およびJ.レイノルズ、「郵便局は議定書を作ります--バージョン2インチ、USC/情報科学が1985年2月に設けるRFC937。」
[RFC1010] Reynolds, J., and J. Postel, "Assigned Numbers", RFC
1010, USC/Information Sciences Institute, May 1987.
[RFC1010] USC/情報科学が設けるレイノルズ、J.、およびJ.ポステル、「規定番号」、RFC1010は1987がそうするかもしれません。
Author's Address:
作者のアドレス:
Marshall Rose The Wollongong Group 1129 San Antonio Rd. Palo Alto, California 94303
マーシャル・ローズウォロンゴングループ1129サンアントニオ通り パロアルト、カリフォルニア 94303
Phone: (415) 962-7100
以下に電話をしてください。 (415) 962-7100
Email: MRose@TWG.COM
メール: MRose@TWG.COM
Rose [Page 16]
上昇しました。[16ページ]
一覧
スポンサーリンク
