RFC780 日本語訳
0780 Mail Transfer Protocol. S. Sluizer, J. Postel. May 1981. (Format: TXT=80352 bytes) (Obsoletes RFC0772) (Obsoleted by RFC0788, STD0010) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
MAIL TRANSFER PROTOCOL
メール転送プロトコル
Suzanne Sluizer
スザンヌSluizer
and
そして
Jonathan B. Postel
ジョナサン・B.ポステル
RFC 780
RFC780
May 1981
1981年5月
Information Sciences Institute
University of Southern California
4676 Admiralty Way
Marina del Rey, California 90291
南カリフォルニア4676海軍本部Wayマリナデルレイ、カリフォルニア 90291人の情報Sciences Institute大学
(213) 822-1511
(213) 822-1511
May 1981 RFC 780 Mail Transfer Protocol
1981RFC780が転送プロトコルを郵送しますように。
TABLE OF CONTENTS
目次
1. INTRODUCTION .................................................. 1
1. 序論… 1
2. THE MTP MODEL ................................................. 2
2. MTPはモデル化します… 2
3. BASIC MAIL .................................................... 4
3. 基本のメール… 4
3.1. Forwarding ............................................... 5
3.2. Source Routing ........................................... 6
3.1. 転送します。 5 3.2. ソースルート設定… 6
4. MULTI-RECIPIENT MAIL .......................................... 8
4. マルチ受取人メール… 8
4.1. Scheme Selection: MRSQ ................................... 8
4.2. Message Text Specification: MAIL ......................... 9
4.3. Recipient Specification: MRCP ........................... 10
4.4. Scheme Mechanics: Recipients First ...................... 10
4.5. Scheme Mechanics: Text First ............................ 12
4.6. Discussion .............................................. 12
4.1. 選択を計画してください: MRSQ… 8 4.2. メッセージ・テキスト仕様: メール… 9 4.3. 受取人仕様: MRCP… 10 4.4. 整備士を計画してください: 受取人、1番目… 10 4.5. 整備士を計画してください: テキスト、1番目… 12 4.6. 議論… 12
5. SPECIFICATIONS ............................................... 16
5. 仕様… 16
5.1. MTP Commands ............................................ 16
5.1.1. Command Semantics ..................................... 16
5.1.2. Command Syntax ........................................ 18
5.2. MTP Replies ............................................. 22
5.2.1. Reply Codes by Function Group ......................... 23
5.2.2. Reply Codes in Numeric Order .......................... 24
5.3. Sequencing of Commands and Replies ...................... 25
5.4. State Diagrams .......................................... 28
5.5. Details ................................................. 30
5.5.1. Minimum Implementation ................................ 30
5.5.2. Transparency .......................................... 30
5.5.3. Sizes ................................................. 30
5.1. MTPは命令します… 16 5.1.1. 意味論を命令してください… 16 5.1.2. 構文を命令してください… 18 5.2. MTPは返答します… 22 5.2.1. 機能による回答コードは分類されます… 23 5.2.2. 数値の回答コードは注文されます… 24 5.3. コマンドと回答の配列… 25 5.4. ダイヤグラムを述べてください… 28 5.5. 詳細… 30 5.5.1. 最小の実現… 30 5.5.2. 透明… 30 5.5.3. サイズ… 30
APPENDIX A: TCP ................................................. 32 APPENDIX B: NCP ................................................. 33 APPENDIX C: NITS ................................................ 34 APPENDIX D: X.25 ................................................ 35 APPENDIX E: Theory of Reply Codes ............................... 36
付録A: TCP… 32 付録B: NCP… 33 付録C: 夜… 34 付録D: X.25… 35 付録E: 回答コードの理論… 36
GLOSSARY ......................................................... 39
用語集… 39
REFERENCES ....................................................... 42
参照… 42
Network Working Group S. Sluizer
Request for Comments: 780 J. Postel
ISI
Replaces: RFC 772 May 1981
Sluizerがコメントのために要求するワーキンググループS.をネットワークでつないでください: 780 J.ポステルISIは以下を取り替えます。 RFC772 1981年5月
MAIL TRANSFER PROTOCOL
メール転送プロトコル
1. INTRODUCTION
1. 序論
The objective of Mail Transfer Protocol (MTP) is to transfer mail reliably and efficiently.
メールTransferプロトコル(MTP)の目的は確かに効率的にメールを移すことです。
MTP is designed to be independent of the particular transmission subsystem and requires only a reliable ordered data stream channel. Appendices describe the use of MTP with various transport services. A Glossary provides the definitions of terms as used in this document.
MTPは特定のトランスミッションサブシステムから独立しているように設計されていて、高信頼の規則正しいデータストリーム・チャンネルだけを必要とします。 付録は様々な輸送サービスによるMTPの使用について説明します。 Glossaryは本書では使用されるように用語の定義を提供します。
An important feature of MTP is its capability to relay mail from one transport environment to another. A transport service provides an interprocess communication environment (IPCE). An IPCE may cover one network, several networks, or a subset of a network. A process can communicate directly with another process anywhere in its own IPCE. Mail is a special case of interprocess communication. Mail can be communicated between proceses in different IPCEs by relaying through a process connected to two (or more) IPCEs. More specifically, mail can be relayed between hosts on different transport systems by a host on both transport systems. It is important to realize that transport systems (or IPCEs) are not one-to-one with networks.
MTPの重要な特徴は1つの輸送環境から別の環境までメールをリレーするその能力です。 輸送サービスはプロセス間通信環境(IPCE)を提供します。 IPCEはネットワークの1つのネットワーク、いくつかのネットワーク、または部分集合をカバーするかもしれません。 過程は別の過程でそれ自身のIPCEでどこでも直接伝達できます。 メールはプロセス間通信の特別なケースです。 異なったIPCEsのprocesesの間で過程で2に関連している(さらに)IPCEsをリレーすることによって、メールを伝えることができます。 より明確に、ホストは両方の輸送システムの上で異なった輸送システムの上でホストの間でメールをリレーできます。輸送システム(または、IPCEs)がネットワークがある1〜1でないとわかるのは重要です。
Sluizer & Postel [Page 1]
Sluizerとポステル[1ページ]
May 1981 RFC 780 Mail Transfer Protocol
1981RFC780が転送プロトコルを郵送しますように。
2. THE MTP MODEL
2. MTPモデル
The MTP design is based on the following model of communication: at the initiation of the user, the sender-MTP establishes the full-duplex transmission channel. MTP commands are generated by the sender-MTP and sent to the receiver-MTP. MTP replies are sent from the receiver-MTP to the sender-MTP in response to the commands.
MTPデザインはコミュニケーションの以下のモデルに基づいています: ユーザの手引きで、送付者-MTPは全二重伝送チャンネルを確立します。 MTPコマンドは送付者-MTPであって受信機-MTPに送りにされるので発生します。 コマンドに対応して受信機-MTPから送付者-MTPにMTP回答を送ります。
In the simplest case, once the transmission channel is established the MTP-sender sends a MAIL command indicating the sender and receiver of the mail. If the MTP-receiver can accept the mail it responds with a go ahead reply. Then the MTP-sender sends the mail data, terminating with a special sequence. If the MTP-receiver successfully processes the mail it responds with an OK reply.
最も簡単な場合では、トランスミッションチャンネルがいったん確立されると、MTP-送付者はメールコマンドにメールの送付者と受信機を示させます。 MTP-受信機がそれが先で碁で反応させるメールを受け入れることができるなら、返答してください。 そして、特別な系列で終わって、MTP-送付者はメールデータを送ります。 MTP-受信機が首尾よくメールを処理するなら、それはOK回答で応じます。
-------------------------------------------------------------
-------------------------------------------------------------
+----------+ +----------+
+------+ | | | |
| User |<-->| | MTP | |
+------+ | Sender- |Commands/Replies| Receiver-|
+------+ | MTP |<-------------->| MTP | +------+
| File |<-->| | and Mail | |<-->| File |
|System| | | | | |System|
+------+ +----------+ +----------+ +------+
+----------+ +----------+ +------+ | | | | | ユーザ| <-->、|、| MTP| | +------+ | 送付者|コマンド/回答| 受信機| +------+ | MTP| <、-、-、-、-、-、-、-、-、-、-、-、-、--、>| MTP| +------+ | ファイル| <-->、|、| そして、メール| | <-->、| ファイル| |システム| | | | | |システム| +------+ +----------+ +----------+ +------+
Sender-MTP Receiver-MTP
送付者-MTP受信機-MTP
Model for MTP Use
MTP使用には、モデル化してください。
Figure 1
図1
-------------------------------------------------------------
-------------------------------------------------------------
The MTP provides mechanisms for the transmission of mail; directly from the sending user's host to the receiving user's host when the two host are connected to the same transport service, or via one or more relay MTP-servers when the source and destination hosts are not connected to the same transport service.
MTPはメールの伝達にメカニズムを提供します。 ソースとあて先ホストが同じ輸送サービスに接続されないとき、直接送付ユーザのホストから受信ユーザのホストまで、2ホストがいつ同じ輸送サービスか1を通して接されるか、そして、以上がMTP-サーバをリレーします。
To be able to provide the relay capability the MTP-server must be supplied with the name of the ultimate destination host as well as the destination mailbox name.
MTP-サーバをリレー能力に提供できるのにあて先メールボックス名と同様に最終仕向地ホストの名前を供給しなければなりません。
[Page 2] Sluizer & Postel
[2ページ] Sluizerとポステル
RFC 780 May 1981
Mail Transfer Protocol
RFC780 1981年5月のメール転送プロトコル
The arguments to the MAIL command are a FROM path and a TO path. The TO path is a source route while the FROM path is a return route (which may be used to return a message to the sender when an error occurs with a relayed message).
メールコマンドへの議論は、FROM経路とTO経路です。 FROM経路は戻り経路(誤りがリレーされたメッセージで発生するときメッセージを送付者に返すのに使用されるかもしれない)ですが、TO経路は送信元経路です。
The preceding discussion has outlined the transmission of one copy of one message from a source to a destination host and the possibility of relaying messages between different transport services. The MTP additionally supports the transmission of one copy of a message addressed to multiple recipients.
前の議論は1つのメッセージのコピー1部のソースからあて先ホストまでのトランスミッションと異なった輸送サービスの間のメッセージをリレーする可能性について概説しました。 MTPはさらに、複数の受取人に記述されたメッセージのコピー1部のトランスミッションを支持します。
In order for mail to be successfully transmitted the destination users must be known at the destination receiver-MTP and the mail data must be correctly received and stored. In the single recipient case discussed above the positive response to the MAIL command indicated the recipient was known, and the final OK response indicated the mail was received and stored.
メールが首尾よく伝えられるために目的地受信機-MTPで目的地ユーザを知っていなければならなくて、メールデータを正しく受け取られて、格納しなければなりません。 メールへの積極的な応答を超えて議論したただ一つの受取人事件では、コマンドは、受取人が知られていたのを示して、最終的なOK応答は、メールが受け取られて、格納されたのを示しました。
To support multi-recipient mail, MTP provides two procedures: Text-First, and Recipients-First. In the text-first scheme the mail data is sent and acknowledged, then each recipient identification is sent and acknowledged (or refused) separately. In the recipients-first scheme the recipients are negotiated first, then the text is sent and acknowledged (for all recipients at once). The choice of scheme is up to the MTP-receiver, and depends on the way mail is handled in the destination host.
マルチ受取人メールを支持するために、MTPは2つの手順を提供します: 最初にテキスト、および最初に受取人。 メールデータが最初にテキスト計画では、送られて、承認されて、次に、それぞれの受取人識別は、別々に送られて、承諾されます(または、拒否されます)。 最初に受取人計画では、受取人が最初に、交渉されて、次に、テキストが送られて、承認される、(すべての受取人、すぐに) 計画のこの選択は、MTP-受信機まであって、メールがあて先ホストで扱われる方法次第です。
The multi-recipient mail procedures are optional and the determination of which scheme to use is negotiated. The use of the multi-recipient schemes is strongly encouraged by the economy they provide in transmission and processing.
マルチ受取人メール手順は任意です、そして、どの計画を使用したらよいかに関する決断は交渉されます。 マルチ受取人計画の使用はそれらがトランスミッションと処理に提供する経済によって強く奨励されます。
The mail commands and replies have a rigid syntax. Replies also have a numeric code. In the following, examples appear which use actual commands and replies. The complete lists of commands and replies appears in Section 5 on specifications.
メールコマンドと回答には、堅い構文があります。 また、回答には、数字コードがあります。 以下では、実際のコマンドと回答を使用する例が現れます。 コマンドと回答に関する全リストはセクション5に仕様で現れます。
Commands and replies are not case sensitive. That is, a command or reply word may be upper case, lower case, or any mixture of upper and lower case. Note that this is not true of mailbox user names. For some hosts the user name is case sensitive, and MTP implementations must take case to preserve the case of user names as they appear in mailbox arguments.
コマンドと回答は大文字と小文字を区別していません。 すなわち、コマンドか回答単語が、大文字と小文字の大文字、小文字、またはどんな混合物であるかもしれません。 これがメールボックスユーザ名に関して本当でないことに注意してください。 何人かのホストにとって、ユーザ名は大文字と小文字を区別しています、そして、MTP実現はメールボックス議論に現れるようにユーザ名に関するケースを保存するためにケースを取らなければなりません。
Sluizer & Postel [Page 3]
Sluizerとポステル[3ページ]
May 1981 RFC 780 Mail Transfer Protocol
1981RFC780が転送プロトコルを郵送しますように。
3. BASIC MAIL
3. 基本のメール
The basic command for transmitting mail is MAIL. This command causes the transmitted data to be entered into the recipient's mailbox, or accepted for relaying to the destination host.
メールを伝えるための基本コマンドはメールです。 このコマンドは、伝えられたデータが受信者のメールボックスの中に入力されるか、またはあて先ホストへのリレーのために受け入れられることを引き起こします。
The mail text is also sent on the transmission channel. This requires that the end of the text be signalled so that the command and reply dialog can be resumed. MTP signals the end of the mail text by sending a line containing only a period. A transparency procedure is used to prevent this interfering with the users text (see Section 5.5.2).
また、トランスミッションチャンネルでメールテキストを送ります。 これは、テキストの終わりがコマンドと回答対話を再開できるように合図されるのを必要とします。 MTPは期間だけを含む一筆書き送るのによるメールテキストの終わりに合図します。 透明手順は、ユーザテキストのこの干渉を防ぐのに用いられます(セクション5.5.2を見てください)。
MAIL <SP> FROM:<sender-path> <SP> TO:<receiver-path> <CRLF>
メール<SP>FROM:<送付者道の><SP>TO:<受信機経路><CRLF>。
The <sender-path> contains the source mailbox; the
<receiver-path> contains the destination mailbox. If accepted,
the receiver-MTP returns a 354 reply and considers all
succeeding lines to be the message text. The message text is
terminated by a line containing only a period, upon which a 250
completion reply is returned. Various errors are possible.
<送付者道の>はソースメールボックスを含んでいます。 <受信機経路>はあて先メールボックスを含んでいます。 受け入れるなら、受信機-MTPは、354回答を返して、続くすべての線がメッセージ・テキストであると考えます。 メッセージ・テキストは250完成回答が返される期間だけを含む線によって終えられます。 様々な誤りは可能です。
Actually the <sender-path> and <receiver-path> are more than
just the mailboxes, they may be source routes. The
<receiver-path> is a source routing list of hosts and
destination mailbox; the <sender-path> is a reverse source
routing list of hosts and source mailbox.
実際に<送付者道の>と<受信機経路>がまさしくメールボックス以上である、それらは送信元経路であるかもしれません。 <受信機経路>はホストとあて先メールボックスのソースルーティングリストです。 <送付者道の>はホストとソースメールボックスの逆のソースルーティングリストです。
[Page 4] Sluizer & Postel
[4ページ] Sluizerとポステル
RFC 780 May 1981
Mail Transfer Protocol
RFC780 1981年5月のメール転送プロトコル
-------------------------------------------------------------
-------------------------------------------------------------
Example of MAIL (Basic Mail)
メールに関する例(基本的なメール)
This MAIL command specifies the mail is sent by Waldo at host A,
and is to be delivered to Foo at host Y. Here we assume that host
A contacts host Y directly.
このメールコマンドは指定します。メールは、ウォールドーがホストAで送って、そのホストAが直接Yを接待するのに私たちが、思う連絡するホストY.HereでFooに渡すことです。
S: MAIL FROM:<waldo@A> TO:<Foo@Y> <CRLF>
R: 354 Start mail input; end with <CRLF>.<CRLF>
S: Blah blah blah blah....etc. etc. etc.
S: <CRLF>.<CRLF>
R: 250 Mail sent
S: FROM:<waldo@A に郵送してください、gt;、TO:<Foo@Y><CRLF>R: 354 メール入力を始めてください。 <CRLF><CRLF>Sで、終わってください: 何のかの、たわごと…などなどなど S: <CRLF><CRLF>R: 250メールは発信しました。
The mail text has now been sent to "Foo".
現在、"Foo"にメールテキストを送りました。
Example 1
例1
-------------------------------------------------------------
-------------------------------------------------------------
3.1. FORWARDING
3.1. 推進
There are two possible preliminary replies that a receiver may use
to indicate that it is accepting mail for a user whose mailbox is
not at that host.
受信機がメールボックスがそのホストにないユーザへのメールを受け入れているのを示すのに使用するかもしれない2つの可能な予備の回答があります。
151 User not local; will forward to <user>@<host>
ローカルではなく、151ユーザ。 >@<ホスト>を<ユーザに送るでしょう。
This reply indicates that the receiver-MTP knows the user's
mailbox is on another host and will take responsibility for
forwarding the mail to that host. This reply is only sent
when the sender would not expect the mail to be forwarded.
That is, when <receiver-path> as given in the command
indicates mail relaying, this reply will not be used. This
reply could be used for an organization with several hosts
when each has a list of many of the users on the hosts. A
host can accept mail for any user on its list and forward it
to the correct host.
この回答は、受信機-MTPが、別のホストの上にユーザのメールボックスがあるのを知っているのを示して、そのホストにメールを転送するのに責任を取るでしょう。 送付者が、メールが転送されると予想しないと、この回答を送るだけです。 すなわち、コマンドで与えられている<受信機経路>がメールリレーを示すとき、この回答は使用されないでしょう。 それぞれがホストの上にユーザの多くのリストを持っていると、この回答は組織に数人のホストと共に使用されるかもしれません。 ホストは、リストでどんなユーザへのメールも受け入れて、正しいホストにそれを送ることができます。
152 User Unknown; mail will be forwarded by the operator
152ユーザ未知。 メールはオペレータによって転送されるでしょう。
This reply indicates that the host does not recognize the
user name, but that it will accept the mail and have the
operator attempt to deliver it. This is useful if the user
name is misspelled, but may be a disservice if the mail is
really undeliverable.
この回答はそれには、ホストがユーザ名を認めませんが、メールを受け入れて、それを届けるオペレータ試みがあるのを示します。 これは、ユーザ名がスペルミスされるなら役に立ちますが、メールが本当に「非-提出物」であるなら、害であるかもしれません。
Sluizer & Postel [Page 5]
Sluizerとポステル[5ページ]
May 1981 RFC 780 Mail Transfer Protocol
1981RFC780が転送プロトコルを郵送しますように。
If forwarding by the operator is unacceptable or if the
sending-user would prefer to send the mail directly to the
recipient's actual host, the action may be aborted.
オペレータによる推進が容認できないか、または送付ユーザが、直接受取人の実際のホストにメールを送るのを好むなら、動作は中止されるかもしれません。
The MTP-sender must accept or reject the proposal in the
preliminary reply by sending a continue (CONT) or abort (ABRT)
command. In the case of the continue, the next reply from the
MTP-receiver will be any of the replies expected for the MAIL
command, most likely "354 Start mail input, ...". In the case of
the abort, the next reply from the MTP-receiver will be "201
Command okay, action aborted".
MTP-送付者は、aが続けている送付(CONT)かアボート(ABRT)命令で予備の回答における提案を受け入れなければならないか、または拒絶しなければなりません。 ケース、続いてください、と回答のどれかが期待していたなら、MTP-受信機からの次の回答はメールコマンド、たぶん「354Startは入力を郵送する」ために望んでいます… アボートの場合では、MTP-受信機からの次の回答は「間違いなく、動作が中止した201Command」でしょう。
3.2. SOURCE ROUTING
3.2. ソースルーティング
The receiver-path may be a source route of the form
"@ONE,@TWO,JOE@THREE", where ONE, TWO, and THREE are hosts. This
form is used to emphasize the distinction between an address and a
route.
「受信機経路は形式の送信元経路が」 @1、@TWO、 JOE@THREE であったならそうするかもしれません。」1、2、および3がホストであり このフォームは、アドレスとルートの区別を強調するのに使用されます。
At some distant future time it might be necessary to expand the
mailbox format to include a region identifier, such as
"user@host@region". If this occured the MTP path convention
could be expanded to
"host@region,host@region,...user@host@region". For example,
"ONE@R1,TWO@R2,JOE@THREE@R3".
いくつかの先々時に、領域識別子を含むようにメールボックス形式を広げるのが必要であるかもしれません、「ユーザ@host@region」などのように。 これがoccuredされるなら、「 host@region 、ホスト@region」にMTP経路コンベンションを広げることができるでしょうに…「ユーザ@host@region。」 例えば、「 ONE@R1 、2@R2、ジョー@THREE@R、3インチ」
The mailbox is an absolute address, and the route is information
about how to get there. The two concepts should not be confused.
メールボックスは絶対アドレスです、そして、ルートはどうそこに到着するかの情報です。 2つの概念は混乱するべきではありません。
The elements of the receiver-path are to be moved to the
sender-path as the message is relayed from one MTP to another. The
sender-path is a reverse source route, that is, a source route to
the originator of the message. When an MTP deletes its identifier
from the receiver-path and inserts it into the sender-path, it
must use the name it is known by in the environment it is sending
into, not the environment the mail came from, in case the MTP is
known be different names in different environments.
受信機経路の要素はメッセージが1MTPから別のMTPまでリレーされるとき送付者道に動かされることです。 送付者道は逆の送信元経路、すなわち、メッセージの創始者への送信元経路です。 MTPが受信機経路から識別子を削除して、送付者道にそれを挿入するとき、郵便配達人が来た環境ではなく、それが発信する環境で知られている名前を使用しなければならなくて、MTPが知られているといけないので異なった環境における異なった名前になってください。
When source routing is used the receiver-MTP will receive mail to
be relayed to another MTP. The receiver-MTP may accept the task
of relaying the mail or reject it in the same way it accepts or
reject mail for a local user. It does not use the 151 "User not
local" or 152 "User unknown" preliminary replies. Once the
receiver-MTP accepts the relaying task it receives the mail text
and transforms the command arguments by removing its own
identifier from the receiver-path and inserting it in the
ソースルーティングが使用されているとき、受信機-MTPは、別のMTPにリレーされるためにメールを受け取るでしょう。 受信機-MTPはメールをリレーするタスクを受け入れるか、受け入れる同じようにそれを拒絶するか、または地元のユーザのためにメールを拒絶するかもしれません。 151を使用しない、「ローカルではなく、ユーザ、」 152「ユーザ未知」準備段階は返答します。 受信機-MTPがいったんリレータスクを受け入れると、それは、メールテキストを受け取って、受信機経路からそれ自身の識別子を取り除いて、それを差し込むコマンド議論を変えます。
[Page 6] Sluizer & Postel
[6ページ] Sluizerとポステル
RFC 780 May 1981
Mail Transfer Protocol
RFC780 1981年5月のメール転送プロトコル
beginning of the sender-path. The receiver-MTP then becomes a
sender-MTP and establishes a transmission channel to the next MTP
in the receiver-path and sends it the mail.
送付者道の始まり。 受信機-MTPは次に、送付者-MTPになって、受信機経路の次のMTPにトランスミッションチャンネルを確立して、メールをそれに送ります。
If an MTP has accepted the task of relaying the mail and later
finds that the receiver-path is incorrect or that the mail cannot
be delivered for whatever reason, then it must construct a
notification message and send it to the originator of the
undeliverable mail as indicated by the sender-path. This
notification message must be from the MTP at this host. That is,
the sender-path of the notification message itself will be
"MTP@<host>", and in the notification message header the From
field will be "MTP at <host>". Of course, MTPs should not send
notification messages about problems with notification messages.
MTPが、メールをリレーするタスクを受け入れて、後で受信機経路が不正確であるか、またはいかなる理由でもメールは配達できないのがわかるなら、それが、送付者道によって示されるように「非-提出物」メールの創始者に通知メッセージを構成して、それを送らなければなりません。 この通知メッセージはこのホストでMTPから来ているに違いありません。 すなわち、通知メッセージ自体の送付者道は、「MTP@<ホスト>」であり、Fromがさばく通知メッセージヘッダーの「<ホスト>のMTP」でしょう。 もちろん、MTPsは通知メッセージに関する問題に関する通知メッセージを送るはずがありません。
Sluizer & Postel [Page 7]
Sluizerとポステル[7ページ]
May 1981 RFC 780 Mail Transfer Protocol
1981RFC780が転送プロトコルを郵送しますように。
4. MULTI-RECIPIENT MAIL
4. マルチ受取人メール
There are two MTP commands which allow the text of a message to be mailed to several recipients simultaneously; such message transmission is far more efficient than the practice of sending the text again and again for each additional recipient at a host. In one scheme, all recipients are specified first, and then the text is sent. In the other scheme, the order is reversed and the text is sent first, followed by the recipients. The sender-MTP suggests the scheme it would prefer, but receiver-MTP controls which scheme is actually used. To select a particular scheme, the MRSQ command is used; to specify recipients after a scheme is chosen, MRCP commands are given; and to furnish text, the MAIL command is used.
同時に数人の受取人に郵送されるべきメッセージのテキストを許容する2つのMTPコマンドがあります。 メッセージ送信はそれぞれの追加受取人のためにホストでテキストを再三送る習慣とはるかに同じくらい効率的です。 1つの計画では、最初にすべての受取人を指定します、そして、次に、テキストを送ります。 もう片方の計画では、オーダーを逆にします、そして、受取人によって後をつけられて、最初に、テキストを送ります。 送付者-MTPはそれが好む計画を勧めますが、受信機-MTPは、どの計画が実際に使用されるかを制御します。 特定の計画を選択するために、MRSQコマンドは使用されています。 計画が選ばれた後に受取人を指定するために、MRCPコマンドを与えます。 そして、テキストを提供するために、メールコマンドは使用されています。
Both schemes are necessary because neither by itself is optimal for all systems. MRSQ R allows more of a "bulk" mailing because everything is saved up and then mailed simultaneously. This is very useful for systems such as ITS where the MTP-receiver does not itself write mail directly, but hands it on to a central mailer demon. The more information (e.g., recipients) associated with a single "hand-off", the more efficiently mail can be delivered.
両方の計画が必要である、どちらもそれ自体、すべてが貯金されるのでシステムMRSQ Rが一層の「大量」の郵送を許容するすべてに最適であり、次に、同時に、郵送します。 これは、MTP-受信機がそれ自体をするというわけではないITSなどのシステムが直接メールを書くので非常に役に立ちますが、主要な郵送者悪霊にそれを手渡します。 より多くの情報(例えば、受取人)が単一の「ハンドオフ」に関連づければ関連づけるほど、より効率的にメールを配達できます。
By contrast, MRSQ T is geared to receiver-MTPs which want to deliver mail directly, in one-by-one incremental fashion. For each given recipient this scheme returns an individual success/failure reply code which may depend on variable mail system factors such as exceeding disk allocation, mailbox access conflicts, and so forth. If these receiver-MTPs tried to emulate MRSQ Rs bulk mailing, they would have to ensure that a success reply to the MAIL indeed meant that it had been delivered to ALL recipients specified -- not just some.
対照的に、MRSQ Tは直接と中にメールをひとつずつ配達したがっている受信機-MTPsの増加のファッションに適合しています。 それぞれの与えられた受取人に関しては、この計画は上回っているディスク配分、メールボックスアクセス闘争などなどの可変メールシステム要素に依存するかもしれない個々の成功/失敗回答コードを返します。 これらの受信機-MTPsがMRSQ Rsの大量の郵送を見習おうとするなら、彼らは、本当に、メールに関する成功回答が、指定されたすべての受取人にそれを届けました--どんなほんのいくつかも意味しなかったのを保証しなければならないでしょうに。
4.1. SCHEME SELECTION: MRSQ
4.1. 選択を計画してください: MRSQ
MRSQ is the means by which a sender-MTP can test for MRSQ/MRCP
implementation, select a particular scheme, reset its state, and
even do some rudimentary negotiation. Its format is as follows:
MRSQは送付者-MTPがMRSQ/MRCP実現がないかどうかテストして、特定の計画を選択して、状態をリセットして、何らかの初歩的な交渉ができさえする手段です。 形式は以下の通りです:
MRSQ [<SP> <scheme>] <CRLF>
MRSQ[<SP><計画>]<CRLF>。
<scheme> is a single character. The following are defined:
R Recipients first. If this is not implemented, T must be.
T Text first. If this is not implemented, R must be.
? Request for preference. This must always be implemented.
<計画>は単独のキャラクタです。 以下は定義されます: R受取人、1番目。 これが実行されないなら、Tは実行されるに違いありません。 Tテキスト、1番目。 これが実行されないなら、Rは実行されるに違いありません。 ? 好みのために、要求します。 いつもこれを実行しなければなりません。
[Page 8] Sluizer & Postel
[8ページ] Sluizerとポステル
RFC 780 May 1981
Mail Transfer Protocol
RFC780 1981年5月のメール転送プロトコル
No argument means a "selection" of none of the schemes (the
default).
どんな議論も計画(デフォルト)のいずれの「選択」でないのを意味しません。
Possible replies are:
200 OK, use the specified scheme
215 <scheme> This is the scheme I prefer
504 I understand MRSQ but can't use that scheme
5xx Command unrecognized or unimplemented
可能な回答は以下の通りです。 200OK、使用、指定された計画215<計画>Thisが私が好む計画である、504、私がMRSQを理解していますが、その計画5xx Commandを使用できない、認識されていないか非実行にされる
There are three aspects of MRSQ. The first is that an MRSQ with
no argument must always return a 200 reply and restore the default
state of having no scheme selected. Any other reply implies that
MRSQ and hence MRCP are not understood or cannot be performed
correctly.
MRSQの3つの局面があります。 1番目は議論のないMRSQがいつも200回答を返して、計画を全く選択させないデフォルト状態を回復しなければならないということです。 いかなる他の回答も、MRSQとしたがって、MRCPを理解しないことができないか、正しく実行できないのを含意します。
The second is that the use of "?" as a <scheme> asks the MTP
receiver to return a 215 reply in which the receiver specifies a
"preferred" scheme. The format of this reply is simple:
2番目は<計画>としての“?"の使用が、受信機が「都合のよい」計画を指定する215回答を返すようにMTP受信機に頼むということです。 この回答の形式は簡単です:
215 <SP> <scheme> [<SP> <string>] <CRLF>
215 <SP><計画>[<SP><ストリング>]<CRLF>。
Any other reply (e.g., 4xx or 5xx) implies that MRSQ and MRCP
are not implemented, because "?" must always be implemented if
MRSQ is.
いかなる他の回答(例えば、4xxか5xx)も、MRSQとMRCPが実行されないのを含意します、MRSQが実行するならいつも“?"を実行しなければならないので。
The third important point about MRSQ is that it always has the
side effect of reseting all schemes to their initial state. This
reset must be done no matter what the reply will be -- 200, 215,
or 504. The actions necessary for a reset will be explained when
discussing how each scheme actually works.
MRSQに関する3番目の重要なポイントはそれにはそれらの初期状態にすべての計画をresetingする副作用がいつもあるということです。 回答が何になっても、このリセットをしなければなりません--200、215、または504。 各計画が実際にどううまくいくかについて議論するとき、リセットに必要な動作は説明されるでしょう。
Note that the receiver gets to choose which scheme is used. The
sender must be prepared to do either.
受信機が、どの計画が使用されているかを選び始めることに注意してください。 送付者はする用意ができていなければなりません。
4.2. MESSAGE TEXT SPECIFICATION: MAIL
4.2. メッセージ・テキスト仕様: メール
Regardless of which scheme (if any) has been selected, a MAIL
command with a non-null receiver-path argument will behave exactly
as before; the MRSQ/MRCP commands have no effect on it. However,
a normal MAIL command does have the same side effect as MRSQ; it
"resets" all schemes to their initial state.
どの計画(もしあれば)が選択されたかにかかわらず、非ヌル受信機経路議論によるメールコマンドはまさに従来と同様振る舞うでしょう。 MRSQ/MRCPコマンドはそれで効き目がありません。 しかしながら、通常のメールコマンドには、MRSQと同じ副作用があります。 それはそれらの初期状態にすべての計画を「リセットします」。
It is only when the receiver-path argument is null that the
particular scheme chosen is important.
受信機経路議論が特定の計画が重要であることを選ぶヌルである時にすぎません。
MAIL FROM:<sender-path> <CRLF>
メールFROM:<送付者道の><CRLF>。
Sluizer & Postel [Page 9]
Sluizerとポステル[9ページ]
May 1981 RFC 780 Mail Transfer Protocol
1981RFC780が転送プロトコルを郵送しますように。
Rather than producing an error, the receiver will accept message
text for this "null" recipient specification. What it does with
it depends on which scheme is in effect, and will be described in
the section on Scheme Mechanics.
誤りを起こすよりむしろ、受信機はこの「ヌル」の受取人仕様のためにメッセージ・テキストを受け入れるでしょう。 それがそれで何をするかはどの計画が有効であるかよって、Scheme Mechanicsの上のセクションで説明されるでしょう。
4.3. RECIPIENT SPECIFICATION: MRCP
4.3. 受取人仕様: MRCP
In order to specify recipient names (i.e., mailboxes) and receive
some acknowledgment (or refusal) for each name, the following
command is used:
受取人名(すなわち、メールボックス)を指定して、各名前のための何らかの承認(または、拒否)を受けるために、以下のコマンドは使用されています:
MRCP <SP> TO:<receiver-path> <CRLF>
MRCP<SP>TO:<受信機経路><CRLF>。
Reply for no scheme:
503 No scheme specified yet; use MRSQ
Replies for scheme T are identical to those for MAIL.
Replies for scheme R (recipients first):
200 OK, name stored
452 Recipient table full, this name not stored
550 Recipient name rejected
4xx Temporary error, try this name again later
5xx Permanent error, report to sender
計画を全く代わって答えないでください: 503 計画は全くまだ指定していませんでした。 メールに、計画Tがそれらと同じであるので、MRSQ Repliesを使用してください。 計画Rのための回答、(受取人、1番目)、: 200 5xx Permanent誤り、送付者へのレポートは、OKといっぱいに、この名義の格納されなかった550Recipientが後で再び拒絶された4xx Temporary誤り、これが命名するトライと命名する格納された452Recipientテーブルと命名します。
Note that use of this command is an error if no scheme has been
selected yet; an MRSQ <scheme> must have been given if MRCP is to
be used.
計画が全くまだ選択されていないならこのコマンドの使用が誤りであることに注意してください。 MRCPが使用されているつもりであるなら、MRSQ<計画>を与えたに違いありません。
4.4. SCHEME MECHANICS: MRSQ R (RECIPIENTS-FIRST)
4.4. 整備士を計画してください: MRSQ R(最初に受取人)
In the recipients-first scheme, MRCP is used to specify names
which the MTP receiver stores in a list or table. Normally the
reply for each MRCP will be either a 200 for acceptance or a
4xx/5xx rejection code. All 5xx codes are permanent rejections
(e.g., user not known) which should be reported to the human user,
whereas 4xx codes in general connote some temporary error that may
be rectified later. None of the 4xx/5xx replies impinge on
previous or succeeding MRCP commands, except for 452 which
indicates that no further MRCPs will succeed unless a message is
sent to the already stored recipients or a reset is done.
最初に受取人計画では、MRCPは、MTP受信機がリストかテーブルに格納する名前を指定するのに使用されます。 通常、各MRCPのための回答は、承認のための200か4xx/5xx拒絶コードになどちらかでしょう。 すべての5xxコードが人間のユーザに報告されるべきである永久的な拒絶(例えば知られないユーザ)ですが、一般に、4xxコードは後で正されるかもしれない何らかの一時的な誤りを内包します。 4xx/5xx回答のいずれにも前であることの状態で衝突しないか、または452を除いて、続くMRCPは、どれが、メッセージが既に格納された受取人かリセットに送られないとどんな一層のMRCPsも成功しないのを示すか完了していると命令します。
Sending message text to stored recipients is done by giving a MAIL
command with no receiver-path argument; that is, just MAIL <SP>
FROM: <sender-path> <CRLF>. Transmission of the message text is
exactly the same as for normal MAIL. However, a positive
acknowledgment at the end of transmission means the message has
been sent to ALL recipients that were remembered with MRCP, and a
受信機経路議論なしでメールコマンドを与えることによって、格納された受取人にメッセージ・テキストを送ります。 すなわち、まさしくメール<SP>FROM: <送付者道の><CRLF>。 メッセージ・テキストの送信はまさに正常なメールのように同じです。 しかしながら、トランスミッションの端の肯定応答は、MRCP、およびaで覚えていられたすべての受取人にメッセージを送ることを意味します。
[Page 10] Sluizer & Postel
[10ページ] Sluizerとポステル
RFC 780 May 1981
Mail Transfer Protocol
RFC780 1981年5月のメール転送プロトコル
failure code means that it should be considered to have failed for
ALL of these specified recipients. This applies regardless of the
actual error code. Regardless of what the reply signifies, all
stored recipient names are flushed and forgotten -- in other
words, things are reset to their initial state. This purging of
the recipient name list must also be done as the reset side effect
of any use of MRSQ (or MAIL with a non-null receiver-path
argument).
失敗コードは、これらの指定された受取人のすべてのために失敗したのが考えられるべきであることを意味します。 これは実際のエラーコードにかかわらず適用されます。 回答が意味することにかかわらず、すべての格納された受取人名が、洗い流されて、忘れられています--言い換えれば、事態はそれらの初期状態にリセットされます。 またいずれの副作用が使用するリセットとして人名簿をしなければならないMRSQ(または、非ヌル受信機経路議論があるメール)の受取人をこの除くこと。
A 452 reply (out of storage space) to an MRCP can be handled by
using MAIL to specify the message for currently stored recipients,
and then sending more MRCPs and another MAIL, as many times as
necessary. For example, if a receiver only had room for 10 names
this would result in a 50-recipient message being sent 5 times, to
10 different recipients each time.
現在格納された受取人にメッセージを指定するのにメールを使用して、次に、より多くのMRCPsと別のメール(必要なだけの回)を送ることによって、MRCPへの452回答(集積スペースからの)を扱うことができます。 例えば、受信機に10の名前の余地があるだけであるなら、これは5回が送られる50受取人のメッセージをもたらすでしょうに、各回10人の異なった受取人に。
If a sender attempts to specify message text (MAIL with no
receiver-path argument) before any successful MRCPs have been
given, this should be treated exactly as a "normal" MAIL with a
null recipient would be; some receivers return an error, such as
"550 Null recipient".
送付者が、どんなうまくいっているMRCPsも与える前にメッセージ・テキスト(受信機経路議論のないメール)を指定するのを試みるなら、これはちょうどヌル受取人がいる「正常な」メールであるだろうことのように扱われるべきです。 いくつかの受信機が「550Null受取人」などの誤りを返します。
-------------------------------------------------------------
-------------------------------------------------------------
Example of MRSQ R (Recipients First)
MRSQ Rに関する例(受取人、1番目)
First the sender must establish that the receiver implements
MRSQ.
まず最初に、送付者は、受信機がMRSQを実行すると証明しなければなりません。
S: MRSQ <CRLF>
R: 200 OK, no scheme selected
S: MRSQ<CRLF>R: 200 OK、選択されなかった計画全く
An MRSQ with a null argument always returns a 200 if
implemented, selecting the default "scheme", i.e., none of
them. If MRSQ were not implemented, a code of 4xx or 5xx would
be returned.
すなわち、デフォルト「計画」、それらのいずれも選択しないで、実行されるなら、空の項があるMRSQはいつも200を返します。 MRSQが実行されないなら、4xxか5xxのコードは返されるでしょうに。
S: MRSQ R <CRLF>
R: 200 OK, using that scheme
S: MRSQ R<CRLF>R: 200 OK、その計画を使用すること。
All is well; now the recipients can be specified.
すべてが順調です。 現在、受取人を指定できます。
S: MRCP TO:<Foo@Y> <CRLF>
R: 200 OK
S: MRCP TO:<Foo@Y 、gt;、<CRLF>R: 200 OK
Sluizer & Postel [Page 11]
Sluizerとポステル[11ページ]
May 1981 RFC 780 Mail Transfer Protocol
1981RFC780が転送プロトコルを郵送しますように。
S: MRCP TO:<Raboof@Y> <CRLF>
R: 550 No such user here
S: MRCP TO:<Raboof@Y 、gt;、lt;、CRLF>R: ここのそのような550人のユーザでない
S: MRCP TO:<bar@Y> <CRLF>
R: 200 OK
S: MRCP TO:<bar@Y 、gt;、<CRLF>R: 200 OK
S: MRCP TO:<@Y,@X,fubar@Z> <CRLF>
R: 200 OK
S: MRCP TO:<@Y 、@X、 fubar@Z 、gt;、<CRLF>R: 200 OK
Note that the failure of "Raboof" has no effect on the storage
of mail for "Foo", "bar" or the mail to be relayed to "fubar@Z"
through host "X". Now the message text is furnished, by giving
a MAIL command with no receiver-path argument.
"Raboof"の失敗はメールの格納のときに"Foo"、「バー」またはメールがホスト「X」を通して" fubar@Z "にリレーされるために効き目がないことに注意してください。 現在、受信機経路議論なしでメールコマンドを与えることによって、メッセージ・テキストを提供します。
S: MAIL FROM:<waldo@A><CRLF>
R: 354 Start mail input; end with <CRLF>.<CRLF>
S: Blah blah blah blah....etc. etc. etc.
S: <CRLF>.<CRLF>
R: 250 Mail sent
S: FROM:<waldo@A に郵送してください、gt;、lt;、CRLF>R: 354 メール入力を始めてください。 <CRLF><CRLF>Sで、終わってください: 何のかの、たわごと…などなどなど S: <CRLF><CRLF>R: 250メールは発信しました。
The mail text has now been sent to "Foo" and "bar" as well as
relayed to "fubar@Z".
メールテキストは、現在、"Foo"と「バー」に送られて、" fubar@Z "にリレーされました。
Example 2
例2
-------------------------------------------------------------
-------------------------------------------------------------
4.5. SCHEME MECHANICS: MRSQ T (TEXT-FIRST)
4.5. 整備士を計画してください: MRSQ T(最初にテキスト)
In the text-first scheme, MAIL with no receiver-path argument is
used to specify message text, which the receiver stores away.
Succeeding MRCPs are then treated as if they were MAIL commands,
except that none of the text transfer manipulations are done; the
stored message text is sent to the specified recipient, and a
reply code is returned identical to that which an actual MAIL
would invoke. (Note that any 2xx code indicates success.)
最初にテキスト計画では、受信機経路議論のないメールは、メッセージ・テキストを指定するのに使用されます。(受信機はメッセージ・テキストを蓄えます)。 次に、続くMRCPsはまるで彼らがメールコマンドであるかのように扱われます、テキスト転送操作のいずれも完了していないのを除いて。 格納されたメッセージ・テキストを指定された受取人に送ります、そして、実際のメールが呼び出すそれと同じ状態で回答コードを返します。 (どんな2xxコードも成功を示すことに注意してください。)
The stored message text is not forgotten until the next MAIL or
MRSQ, which will either replace it with new text or flush it
entirely. Any use of MRSQ will reset this scheme by flushing
stored text, as will any use of MAIL with a non-null receiver-path
argument.
格納されたメッセージ・テキストは次のメールかMRSQまで忘れられていません。(MRSQはそれを新しいテキストに取り替えるか、またはそれを完全に洗い流すでしょう)。 MRSQのどんな使用も格納されたテキストを洗い流すことによって、この計画をリセットするでしょう、非ヌル受信機経路議論によるメールのどんな使用のようにも。
If an MRCP is seen before any message text has been stored, the
sender in effect is trying to send a null message; some receivers
might allow this, others would return an error code.
どんなメッセージ・テキストも格納される前にMRCPが見られるなら、事実上、送付者はヌルメッセージを送ろうとしています。 いくつかの受信機がこれを許容するかもしれなくて、他のものはエラーコードを返すでしょう。
[Page 12] Sluizer & Postel
[12ページ] Sluizerとポステル
RFC 780 May 1981
Mail Transfer Protocol
RFC780 1981年5月のメール転送プロトコル
-------------------------------------------------------------
-------------------------------------------------------------
Example of MRSQ T (Text First)
MRSQ Tに関する例(テキスト1番目)
First the sender must establish that the receiver implements
MRSQ.
まず最初に、送付者は、受信機がMRSQを実行すると証明しなければなりません。
S: MRSQ ? <CRLF>
R: 215 T Text first, please
S: MRSQ? <CRLF>R: 215Tテキスト、1番目をお願いします
MRSQ is indeed implemented, and the receiver says that it
prefers "T", but that needn't stop the sender from trying
something else.
本当に、MRSQは実行されます、そして、受信機は「T」を好みますが、送付者がそれによって他の何かを試みる必要はないことができないと言います。
S: MRSQ R <CRLF>
R: 504 Sorry, I really can't do that
S: MRSQ R<CRLF>R: 504 すみません、私は本当にそれができません。
It's possible that it could have understood "R" also, but in
general it's best to use the "preferred" scheme, since the
receiver knows which is most efficient for its particular site.
「R」も理解したかもしれないのが、可能ですが、一般に、「都合のよい」計画を使用するのは最も良いです、受信機が、特定のサイトに、どれが最も効率的であるかを知っているので。
S: MRSQ T <CRLF>
R: 200 OK, using that scheme
S: MRSQ T<CRLF>R: 200 OK、その計画を使用すること。
Scheme "T" is now selected, and the message text is sent by
giving a mail command with no receiver-path argument.
現在計画「T」を選択します、そして、受信機経路議論なしでメールコマンドを与えることによって、メッセージ・テキストを送ります。
S: MAIL FROM:<WALDO@A><CRLF>
R: 354 Start mail input; end with <CRLF>.<CRLF>
S: Blah blah blah blah....etc. etc. etc.
S: <CRLF>.<CRLF>
R: 250 Mail stored
S: FROM:<WALDO@A に郵送してください、gt;、lt;、CRLF>R: 354 メール入力を始めてください。 <CRLF><CRLF>Sで、終わってください: 何のかの、たわごと…などなどなど S: <CRLF><CRLF>R: 格納された250メール
Now recipients can be specified.
現在、受取人を指定できます。
S: MRCP TO:<Foo@Y> <CRLF>
R: 250 Stored mail sent
S: MRCP TO:<Foo@Y 、gt;、<CRLF>R: 250 格納されたメールは発信しました。
S: MRCP TO:<Raboof@Y> <CRLF>
R: 550 No such user here
S: MRCP TO:<Raboof@Y 、gt;、lt;、CRLF>R: ここのそのような550人のユーザでない
S: MRCP TO:<bar@Y> <CRLF>
R: 250 Stored mail sent
S: MRCP TO:<bar@Y 、gt;、<CRLF>R: 250 格納されたメールは発信しました。
S: MRCP TO:<@Y,@X,fubar@Z> <CRLF>
R: 250 Mail accepted for relaying
S: MRCP TO:<@Y 、@X、 fubar@Z 、gt;、<CRLF>R: リレーのために受け入れられた250メール
Sluizer & Postel [Page 13]
Sluizerとポステル[13ページ]
May 1981 RFC 780 Mail Transfer Protocol
1981RFC780が転送プロトコルを郵送しますように。
The text has now been sent to "Foo" and "bar" at host "Y" and
will be relayed to "fubar@Z" through host "X", and still
remains stored. A new message can be sent with another
MAIL/MRCP ... sequence, but a careful sender would reset the
state using the exchange below.
テキストは、現在、ホスト「Y」で"Foo"と「バー」に送られて、ホスト「X」を通して" fubar@Z "にリレーされて、まだ格納されたままで残っています。 別のメール/MRCP…系列と共に新しいメッセージを送ることができますが、慎重な送付者は、以下での交換を使用することで状態をリセットするでしょう。
S: MRSQ ? <CRLF>
R: 215 T Text first, please
S: MRSQ? <CRLF>R: 215Tテキスト、1番目をお願いします
Which resets the state without altering the scheme in effect.
事実上、計画を変更しないで、状態をリセットします。
Example 3
例3
-------------------------------------------------------------
-------------------------------------------------------------
4.6. DISCUSSION
4.6. 議論
Because these commands are not required in the minimum
implementation of MTP, one must be prepared to deal with sites
which don't recognize either MRSQ or MRCP. "MRSQ" and "MRSQ ?"
are explicitly designed as tests to see whether either scheme is
implemented. MRCP is not designed as a test, and a failure return
of the "unimplemented" variety could be confused with "No scheme
selected yet", or even with "Recipient unknown".
これらのコマンドはMTPの最小の実現で必要でないので、MRSQかMRCPのどちらかを認識しないサイトに対処するように準備しなければなりません。 "MRSQ"と"MRSQ?"は、どちらの計画も実行されるかどうか確認するようにテストとして明らかに設計されています。 MRCPはテストとして設計されませんでした、そして、"非実行"のバラエティーの失敗復帰は「まだ選択されていなかった計画全く」、または「受取人未知」があっても混乱できました。
There is no way to indicate in a positive response to "MRSQ ?"
that the preferred "scheme" for a receiver is that of the default
state; i.e., none of the multi-recipient schemes. The rationale
is that in this case, it would be pointless to implement MRSQ/MRCP
at all, and the response would therefore be negative.
積極的な応答で受信機の都合のよい「計画」がデフォルト状態のものであることを"MRSQ?"に示す方法が全くありません。 すなわち、マルチ受取人のだれも計画しません。 原理はこの場合全くMRSQ/MRCPを実行するのが無意味であるだろうということです、そして、したがって、応答は否定的でしょう。
One reason that the use of MAIL is restricted to null
receiver-path arguments with this multi-recipient extension is the
ambiguity that would result if a non-null receiver-path argument
were allowed. For example, if MRSQ R was in effect and some MRCPs
had been given, and a MAIL FROM:<X@Y> TO:<FOO@Z><CRLF> was done,
there would be no way to distinguish a failure reply for mailbox
"FOO" from a global failure for all recipients specified. A
similar situation exists for MRSQ T; it would not be clear whether
the text was stored and the mailbox failed, or vice versa, or
both.
メールの使用がこのマルチ受取人拡大とのヌル受信機経路議論に制限される1つの理由が非ヌル受信機経路議論が許容されているなら結果として生じるあいまいさです。 例えば、MRSQ Rが有効であり、いくつかのMRCPsを与えたか、そして、メール FROM:<X@Y 、gt;、 TO:<FOO@Z 、gt;、<CRLF>をして、すべての受取人のためのグローバルな失敗からの"FOO"が指定したメールボックスのための失敗回答を区別する方法が全くないでしょう。 同様の状況はMRSQ Tのために存在しています。 それはテキストが格納されて、メールボックスが失敗したか、逆もまた同様ですか両方をクリアすることでないでしょう。
"Resets" of all schemes are done by all MRSQs and "normal" MAILs
to avoid confusion and overly complicated implementation. The
MRSQ command implies a change or uncertainty of status, and the
MAIL command would otherwise have to use some independent
すべての計画の「リセット」が、混乱とひどく複雑な実現を避けるためにすべてのMRSQsと「正常な」MAILsによって行われます。 MRSQコマンドは状態の変化か不確実性を含意します。そうでなければ、メールコマンドは何らかの独立者を使用しなければならないでしょう。
[Page 14] Sluizer & Postel
[14ページ] Sluizerとポステル
RFC 780 May 1981
Mail Transfer Protocol
RFC780 1981年5月のメール転送プロトコル
mechanisms to avoid clobbering the data bases (e.g., message text
storage area) used by the T/R schemes. However, once a scheme is
selected, it remains in effect. The recommended way for doing a
reset, without changing the current selection, is with "MRSQ ?".
Remember that "MRSQ" alone reverts to the no-scheme state.
T/R計画によって使用されるデータベース(例えば、メッセージ・テキスト格納領域)を打ち負かすのを避けるメカニズム。 しかしながら、計画がいったん選択されると、それは有効なままで残っています。 現在の選択を変えないでリセットするためのお勧めの方法が"MRSQ?"と共にあります。 その"MRSQ"だけ、が計画がない状態に振り向けるのを覚えていてください。
Sluizer & Postel [Page 15]
Sluizerとポステル[15ページ]
May 1981 RFC 780 Mail Transfer Protocol
1981RFC780が転送プロトコルを郵送しますように。
5. SPECIFICATIONS
5. 仕様
5.1. MTP COMMANDS
5.1. MTPコマンド
5.1.1. COMMAND SEMANTICS
5.1.1. コマンド意味論
The MTP commands define the mail transfer or the mail system
function requested by the user. MTP commands are character
strings terminated by <CRLF>. The command codes themselves are
alphabetic characters terminated by <SP> if parameters follow
and <CRLF> otherwise. The syntax of mailboxes must conform to
receiver site conventions. The MTP commands are discussed
below. MTP replies are discussed in the Section 5.2.
MTPコマンドはユーザによって要求された郵便為替かメールシステム機能を定義します。 MTPコマンドは<CRLF>によって終えられた文字列です。 そうでなければ、コマンドコード自体は、パラメタが従うなら<SP>によって終えられた英字と<CRLF>です。 メールボックスの構文は受信機サイトコンベンションに従わなければなりません。 以下でMTPコマンドについて議論します。 セクション5.2でMTP回答について議論します。
MAIL (MAIL)
メール(メール)
This command is used to send mail over the transmission
channel. The argument field contains a sender-path sequence
and optional receiver-path sequence.
このコマンドは、トランスミッションチャンネルの上にメールを送るのに使用されます。 議論分野は送付者道の系列と任意の受信機経路系列を含んでいます。
The sender-path sequence consists of an optional list of
hosts and the sender mailbox. When the list of hosts is
present, it is "reverse" source routing information and
indicates that the mail was relayed through each host on the
list (the first host in the list was the most recent relay).
This list is used as source routing to return non-delivery
notices to the sender. As each relay host adds itself to
the beginning of the list, it must use its name as known in
the network to which it is relaying the mail rather than the
network from which the mail came (if they are different).
送付者道の系列はホストの任意のリストと送付者メールボックスから成ります。 ホストのリストが存在しているとき、それは、「逆」のソースルーティング情報であり、メールがリストの上の各ホストを通してリレーされたのを示します(第1代リストにおけるホストは最新のリレーでした)。 このリストは、非引渡通告書を送付者に返すのにソースルーティングとして使用されます。 各中継ホストがリストの始まりにそれ自体を加えるとき、それはそれがメールが来たネットワークよりむしろメールをリレーしているネットワークで知られているように(それらが異なるなら)人の名前を引合いに出さなければなりません。
If the receiver-path sequence is present, it consists of an
optional list of hosts and a destination mailbox. When the
list of hosts is present, it is source routing information
and indicates that the mail must be relayed to the first
host on the list.
受信機経路系列が存在しているなら、それはホストの任意のリストとあて先メールボックスから成ります。 ホストのリストが存在しているとき、それは、ソースルーティング情報であり、第1代リストの上のホストにメールをリレーしなければならないのを示します。
The receiver treats the lines following the command as mail
text from the sender. The mail text is terminated by the
character sequence "<CRLF>.<CRLF>", (see Section 5.5.2 on
Transparency).
受信機は送付者からのメールテキストとしてコマンドに続く線を扱います。 メールテキストがキャラクタシーケンス「<CRLF><CRLF>」によって終えられる、(透明でセクション5.5.2を見ます。)
As mail is relayed along the receiver-path sequence, each
relay host must remove itself from the path sequence and put
itself at the beginning of the sender-path sequence. When
mail reaches its ultimate destination (the receiver-path
メールが受信機経路系列に沿ってリレーされるとき、各中継ホストは、経路系列から立ち退いて、送付者道の系列の始めにそれ自体を置かなければなりません。 メールが最終仕向地に達する、(受信機経路
[Page 16] Sluizer & Postel
[16ページ] Sluizerとポステル
RFC 780 May 1981
Mail Transfer Protocol
RFC780 1981年5月のメール転送プロトコル
sequence has only a destination mailbox), the receiver-MTP
inserts it into the destination mailbox in accordance with
its host mail conventions. (For example, "MAIL FROM:<X@Y>
TO:<@A,@B,C@D> <CRLF>" will eventually be relayed as "MAIL
FROM:<@A,X@Y> TO:<@B,C@D> <CRLF>.)
系列にはあて先メールボックスしかない、)、ホストメールコンベンションによると、受信機-MTPはあて先メールボックスの中にそれを挿入します。 (例えば、「 FROM:<X@Y に郵送してください、gt;、 TO:<@A 、@B、 C@D 、gt;、<CRLF>、」、結局リレーされる、「 FROM:<@A 、X@Yに郵送してください、gt;、 TO:<@B 、C@D><CRLF>)、」
If the receiver-path sequence is empty, the mail is destined
for a printer or other designated place for host general
delivery mail (if allowed at this host). The mail may be
marked as sent from the sender as specified in the
sender-path sequence field.
受信機経路系列が空であるなら、メールはホスト局留め郵便メールのためのプリンタか他の集合場所に運命づけられています(このホストに許容されているなら)。 メールは送付者道の系列分野の指定されるとしての送付者から送るようにマークされるかもしれません。
MAIL RECIPIENT SCHEME QUESTION (MRSQ)
メール受取人計画問題(MRSQ)
This MTP command is used to select a scheme for the
transmission of mail to several users at the same host. The
schemes are recipients-first, or text-first.
このMTPコマンドは、同じホストの数人のユーザにメールの伝達の計画を選択するのに使用されます。 計画は、最初に受取人、または最初にテキストです。
MAIL RECIPIENT (MRCP)
メール受取人(MRCP)
This command is used to identify the individual recipients
of the mail in the transmission of mail for multiple users
at one host.
このコマンドは、1人のホストの複数のユーザのためにメールの伝達におけるメールの個々の受取人を特定するのに使用されます。
HELP (HELP)
ヘルプ(助け)
This command causes the receiver to send helpful information
regarding its implementation status over the transmission
channel to the receiver. The command may take an argument
(e.g., any command name) and return more specific
information as a response.
受信機はこのコマンドで受信機へのトランスミッションチャンネルの上に実現状態に関する役立つ情報を送ります。コマンドは、主張(例えばどんなコマンド名も)を取って、応答として、より特定の情報を返すかもしれません。
QUIT (QUIT)
やめてください。(やめます)
This command specifies that the receiver must close the
transmission channel.
このコマンドは、受信機がトランスミッションチャンネルを閉じなければならないと指定します。
NOOP (NOOP)
NOOP(NOOP)
This command does not affect any parameters or previously
entered commands. It specifies no action other than that
the receiver send an OK reply.
このコマンドは少しのパラメタや以前に入力されたコマンドにも影響しません。 受信機がOK回答を送る以外に、それは動作を全く指定しません。
Sluizer & Postel [Page 17]
Sluizerとポステル[17ページ]
May 1981 RFC 780 Mail Transfer Protocol
1981RFC780が転送プロトコルを郵送しますように。
CONTINUE (CONT)
続いてください。(CONT)
This command specifies that the previously specified action
is to be continued. This is sent only following a
preliminary reply.
このコマンドは、以前に指定された動作が続けられることであると指定します。 これを予備の回答に続かせるだけです。
ABORT (ABRT)
アボート(ABRT)
This command specifies that the previously specified action
is to be aborted. This is sent only following a preliminary
reply. It specifies no further action other than that the
receiver send an OK reply.
このコマンドは、以前に指定された動作が中止されることであると指定します。 これを予備の回答に続かせるだけです。 受信機がOK回答を送る以外に、それはこれ以上動作を指定しません。
5.1.2. COMMAND SYNTAX
5.1.2. コマンド構文
The commands begin with a command code followed by an argument
field. The command codes are four alphabetic characters.
Upper and lower case alphabetic characters are to be treated
identically. Thus any of the following may represent the mail
command:
議論分野がコマンドコードのあとに続いていて、コマンドは始まります。 コマンドコードは4つの英字です。 大文字と小文字英字は同様に扱われることです。 したがって、以下のどれかはメールコマンドを表すかもしれません:
MAIL Mail mail MaIl mAIl
メールメールメールMaIl mAIl
This also applies to any symbols representing parameter values,
such as R or r for RECIPIENT first. The command codes and the
argument fields are separated by one or more spaces.
また、これは最初にRECIPIENTのためのRかrなどのパラメタ値を表すどんなシンボルにも適用されます。 コマンドコードと議論野原は1つ以上の空間によって分離されます。
But, note that in the sender-path and receiver-path arguments
case is important. In particular, in some hosts the user "foo"
is different from the user "Foo".
しかし、送付者道と受信機経路議論場合におけるそれが重要であることに注意してください。 何人かのホストでは、ユーザ"foo"はユーザ"Foo"と特に、異なっています。
The argument field consists of a variable length character
string ending with the character sequence <CRLF>. It should be
noted that the receiver is to take no action until the end of
the line is received.
議論分野はキャラクタシーケンス<CRLF>で可変長文字列結末から成ります。 行の終わりが受け取られているまで受信機が行動を全く取ることになっていないことに注意されるべきです。
Square brackets denote an optional argument field. If the
option is not taken, the appropriate default is implied. All
characters are in the ASCII characters set.
角括弧は任意の議論分野を指示します。 オプションが取られないなら、適切なデフォルトは含意されます。 ASCII文字セットにすべてのキャラクタがあります。
[Page 18] Sluizer & Postel
[18ページ] Sluizerとポステル
RFC 780 May 1981
Mail Transfer Protocol
RFC780 1981年5月のメール転送プロトコル
The following are the MTP commands:
↓これはMTPコマンドです:
MAIL <SP> FROM:<sender-path> [<SP> TO:<receiver-path>] <CRLF>
メール<SP>FROM:<送付者道の>[<SP>TO:<受信機経路>]<CRLF>。
MRSQ [<SP> <scheme>] <CRLF>
MRSQ[<SP><計画>]<CRLF>。
MRCP <SP> TO:<receiver-path> <CRLF>
MRCP<SP>TO:<受信機経路><CRLF>。
HELP [<SP> <string>] <CRLF>
助け[<SP><ストリング>]<CRLF>。
QUIT <CRLF>
<CRLF>をやめてください。
NOOP <CRLF>
NOOP<CRLF>。
CONT <CRLF>
CONT<CRLF>。
ABRT <CRLF>
ABRT<CRLF>。
Sluizer & Postel [Page 19]
Sluizerとポステル[19ページ]
May 1981 RFC 780 Mail Transfer Protocol
1981RFC780が転送プロトコルを郵送しますように。
The syntax of the above argument fields (using BNF notation
where applicable) is given below. The "..." notation indicates
that a field may be repeated one or more times.
上の議論分野(適切であるところでBNF記法を使用する)の構文を以下に与えます。 「」 … 」 記法は、分野が1回以上繰り返されるかもしれないのを示します。
<sender-path> ::= <path>
<送付者道の>:、:= <経路>。
<receiver-path> ::= <path>
<受信機経路>:、:= <経路>。
<scheme> ::= "R" | "T" | "?"
<計画>:、:= 「R」| 「T」| "?"
<string> ::= <char> | <char> <string>
<ストリング>:、:= <炭の>。| <炭の><ストリング>。
<path> ::= "<" ["@" <host> "," ...] <mailbox> ">"
<経路>:、:= 「"<"[」 「@」 <ホスト>」、…] <メールボックス>">"
<host> ::= <a> <string> | "#" <number> | "[" <dotnum> "]"
<ホスト>:、:= <は><ストリング>です。| 「#」<番号>。| 「[「<dotnum>」]」
<mailbox> ::= <user> "@" <host>
<メールボックス>:、:= <ユーザ>"@"<ホスト>。
<user> ::= <string>
<ユーザ>:、:= <ストリング>。
<char> ::= <c> | '\' <c> | '\' <s>
<炭の>:、:= <c>。| '\'<c>。| '\'<s>。
<dotnum> ::= <snum> "." <snum> "." <snum> "." <snum>
<dotnum>:、:= 「<snum>」、」 「<snum>」、」 「<snum>」、」 <snum>。
<number> ::= <d> | <d> <number>
<番号>:、:= <d>。| <d><番号>。
<snum> ::= three digits representing an integer value in the
range 0 through 255
<snum>:、:= 範囲に0〜255に整数値を表す3ケタ
<specials> ::= '<', '>', '(', ')', '\', ',', ';', ':', '@',
'"', and the control characters (ASCII codes 0 through 37
octal inclusive and 177 octal)
<特別番組>:、:= ''<'、'>''、('、'、)、''\''、'';''、:、'、'@'、'「'制御文字'」(37 8進包括的を通したASCIIコード0と177 8進)
<a> ::= any one of the 26 letters A through Z in either case
<a>:、:= 両方のケースの中のZを通した26個の手紙Aのいずれも
<c> ::= any one of the 128 ASCII characters except
<specials>
<c>:、:= <特別番組>以外の128人のASCII文字のいずれも
<d> ::= any one of the ten digits 0 through 9
<d>:、:= 10ケタ0〜9のいずれも
<s> ::= any one of <specials>
<s>:、:= <特別番組>のいずれも
Note that the backslash, '\', is a quote character, which is
used to indicate that the next character is to be used
literally instead of with its normal interpretation. For
バックスラッシュ('\')が引用文字であることに注意してください。(その引用文字は、次のキャラクタが文字通り通常の解釈の代わりに使用されることになっているのを示すのに使用されます)。 for
[Page 20] Sluizer & Postel
[20ページ] Sluizerとポステル
RFC 780 May 1981
Mail Transfer Protocol
RFC780 1981年5月のメール転送プロトコル
example, "Joe\,Smith" could be used to indicate a single
nine character user field with comma being the fourth
character of the field.
例、分野の4番目のキャラクタであるコンマでただ一つの9キャラクタユーザ分野を示すのに「ジョー\、スミス」を使用できました。
Hosts are generally known by names which are translated to
addresses in each host. Sometimes a host is not known to the
translation function and communication is blocked. To bypass
this barrier numeric forms are also allowed for host "names".
One form is a decimal integer prefixed by a pound sign, "#",
which indicates the number is the address of the host. Another
form is four small decimal integers separated by dots and
enclosed by brackets, e.g., "[123.255.37.321]", which indicates
a 32 bit ARPA Internet Address in four eight bit fields.
一般に、ホストは各ホストでアドレスに翻訳される名前によって知られています。 時々、ホストは翻訳機能に知られていません、そして、コミュニケーションは妨げられます。 また、このバリアを迂回させるために、数値フォームはホスト「名前」のために許容されています。 1つのフォームが1ポンドのサインによって前に置かれた10進整数、数がホストのアドレスであることを示す「#」です。 別のフォームがドットによって切り離されて、例えば括弧によって同封された4つのわずかな10進整数である、「[123.255、.37、.321]、」、4時8分における32ビットのアルパインターネットアドレスが分野に噛み付いたのを示す。
Sluizer & Postel [Page 21]
Sluizerとポステル[21ページ]
May 1981 RFC 780 Mail Transfer Protocol
1981RFC780が転送プロトコルを郵送しますように。
5.2. MTP REPLIES
5.2. MTP回答
Replies to MTP commands are devised to ensure the synchronization
of requests and actions in the process of mail transfer, and to
guarantee that the sender-MTP always knows the state of the
receiver-MTP. Every command must generate exactly one reply.
Additionally, some commands must occur sequentially, such as
MRSQ T->MAIL->MRCP or MRSQ R->MRCP->MAIL.
MTPコマンドに関する回答は、郵便為替の途中に要求と動作の同期を確実にして、送付者-MTPがいつも受信機-MTPの州を知っているのを保証するために工夫されます。 あらゆるコマンドがまさに1つの回答を発生させなければなりません。 さらに、いくつかのコマンドが連続して起こらなければならなくて、MRSQ T->としてのそのようなものがメール>MRCPかMRSQ R>である、MRCP、-、>メール。
The details of the command-reply sequence are made explicit in
the Sections 5.3 and 5.4 on Sequencing and State Diagrams.
コマンド回答系列の詳細をSequencingと州Diagramsでセクション5.3と5.4で明白にします。
An MTP reply consists of a three digit number (transmitted as
three alphanumeric characters) followed by some text. The number
is intended for use by automata to determine what state to enter
next; the text is meant for the human user. It is intended that
the three digits contain enough encoded information that the
sender-MTP will not need to examine the text and may either
discard it or pass it on to the user, as appropriate. In
particular, the text may be receiver-dependent, so there are
likely to be varying texts for each reply code. Further
explanation of the assignment of reply codes is given in the
Appendix E on the Theory of Reply Codes. Formally, a reply is
defined to be the sequence: a three-digit code, <SP>, one line of
text, and <CRLF>.
MTP回答は何らかのテキストがあとに続いた3桁数(3つの英数字として、伝えられる)から成ります。 数はオートマトンによる使用が、次にどんな状態に入ったらよいかを決定することを意図します。 テキストは人間のユーザのために意味されます。 3ケタが送付者-MTPがユーザにテキストを調べる必要はなくて、それを捨てるか、またはそれを渡すかもしれないという十分なコード化された情報を含むことを意図します、適宜。 テキストが受信機特に、依存しているかもしれないので、それぞれの回答コードにおいて、異なったテキストがありそうです。 Theoryの上のAppendix Eで回答コードの課題に関する詳細な説明にReply Codesを与えます。 正式に、回答は系列になるように定義されます: 1 3ケタのコード、<SP>、テキスト行、および<CRLF>。
[Page 22] Sluizer & Postel
[22ページ] Sluizerとポステル
RFC 780 May 1981
Mail Transfer Protocol
RFC780 1981年5月のメール転送プロトコル
5.2.1. REPLY CODES BY FUNCTION GROUPS
5.2.1. 関数群による回答コード
200 Command okay
201 Command okay, action aborted
500 Syntax error, command unrecognized
[This may include errors such as command line too long]
501 Syntax error in parameters or arguments
502 Command not implemented
503 Bad sequence of commands
504 Command parameter not implemented
コマンドのオーケーの201Commandが承認する200(動作の中止になっている500Syntax誤り)は、パラメタか議論502Commandの認識されていない[これはあまりに長い間、コマンドラインなどの誤りを含むかもしれない]501Syntax誤りが504Commandパラメタが実行しなかったコマンドの503Bad系列を実行しなかったと命令します。
211 System status, or system help reply
214 Help message
[Information on how to use the receiver or the meaning of a
particular non-standard command; this reply is useful only
to the human user]
215 <scheme> is the preferred scheme
211 システム状態、または215<計画>が都合のよい計画であるというシステム助け回答214ヘルプメッセージ[特定の標準的でないコマンド; この回答の受信機か意味を使用するのがどう人間のユーザだけの役に立つかに関する情報]
120 <host> Service ready in nnn minutes
220 <host> Service ready for new user
221 <host> Service closing transmission channel
421 <host> Service not available, closing transmission channel
[This may be a reply to any command if the service knows it
must shut down]
120 新しいユーザ221<の準備ができるnnn分220<ホスト>Serviceで準備ができる<ホスト>Serviceは>のServiceの終わりのトランスミッションチャンネル421<ホスト>Serviceの利用可能で、終わりでないトランスミッションチャンネルをホスティングします。[サービスが、それが停止しなければならないのを知っているなら、これはどんなコマンドに関する回答であるかもしれません]
151 User not local; will forward to <user>@<host>
152 User unknown; mail will be forwarded by the operator
250 Requested mail action okay, completed
450 Requested mail action not taken: mailbox unavailable
[E.g., mailbox busy]
550 Requested action not taken: mailbox unavailable
[E.g., mailbox not found, no access]
451 Requested action aborted: local error in processing
452 Requested action not taken: insufficient system storage
552 Requested mail action aborted: exceeded storage allocation
[For current mailbox location]
553 Requested action not taken: mailbox name not allowed
[E.g., mailbox syntax incorrect]
354 Start mail input; end with <CRLF>.<CRLF>
ローカルではなく、151ユーザ。 <ユーザ>@<ホスト>152User未知に送るでしょう。 オペレータ250Requestedメール動作承認、取られなかった完成した450Requestedメール行動でメールを転送するでしょう: 入手できないメールボックス、[例えば、メールボックスが忙しくする、]、550 取られなかったRequested行動: メールボックス[例えば、見つけられなかったメールボックス、アクセスがありません]入手できない451Requested動作は中止になりました: 取られなかった処理452Requested行動における地方の誤り: 不十分なシステム格納552Requestedメール動作は中止になりました: 取られなかった超えられている記憶領域の割当て[現在のメールボックス位置への]553Requested行動: メールボックス名が許容しなかった、[例えば、メールボックス構文不正確である、]、354 Startは入力を郵送します。 <CRLF><CRLF>で、終わってください。
Sluizer & Postel [Page 23]
Sluizerとポステル[23ページ]
May 1981 RFC 780 Mail Transfer Protocol
1981RFC780が転送プロトコルを郵送しますように。
5.2.2. NUMERIC ORDER LIST OF REPLY CODES
5.2.2. 回答コードの数値オーダーリスト
120 <host> Service ready in nnn minutes
151 User not local; will forward to <user>@<host>
152 User unknown; mail will be forwarded by the operator
120 nnnで準備ができる<ホスト>Serviceは地方でなく151Userを書き留めます。 <ユーザ>@<ホスト>152User未知に送るでしょう。 メールはオペレータによって転送されるでしょう。
200 Command okay
201 Command okay, action aborted
211 System status, or system help reply
214 Help message
[Information on how to use the receiver or the meaning of a
particular non-standard command; this reply is useful only
to the human user]
215 <scheme> is the preferred scheme
220 <host> Service ready for new user
221 <host> Service closing transmission channel
250 Requested mail action okay, completed
200 オーケーの201Commandが承認するコマンド、動作は211System状態を中止したか、システム助け回答214ヘルプメッセージ[特定の標準的でないコマンド; この回答の受信機か意味を使用するのがどう人間のユーザだけの役に立つかに関する情報]215<計画>がトランスミッションチャンネル250Requestedメール動作承認を終える新しいユーザ221<ホスト>Serviceの準備ができる都合のよい計画220<ホスト>Serviceです、完成しています。
354 Start mail input; end with <CRLF>.<CRLF>
354 メール入力を始めてください。 <CRLF><CRLF>で、終わってください。
421 <host> Service not available, closing transmission channel
[This may be a reply to any command if the service knows it
must shut down]
450 Requested mail action not taken: mailbox unavailable
[E.g., mailbox busy]
451 Requested action aborted: local error in processing
452 Requested action not taken: insufficient system storage
421 利用可能で、終わりのトランスミッションチャンネル[サービスが、それが停止しなければならないのを知っているなら、これはどんなコマンドに関する回答であるかもしれない]450Requestedではなく、<ホスト>Serviceが取られなかった行動を郵送します: 入手できないメールボックス、[例えば、メールボックスが忙しくする、]、451 Requested動作は中止になりました: 取られなかった処理452Requested行動における地方の誤り: 不十分なシステム格納
500 Syntax error, command unrecognized
[This may include errors such as command line too long]
501 Syntax error in parameters or arguments
502 Command not implemented
503 Bad sequence of commands
504 Command parameter not implemented
550 Requested action not taken: mailbox unavailable
[E.g., mailbox not found, no access]
552 Requested mail action aborted: exceeded storage allocation
[For current mailbox location]
553 Requested action not taken: mailbox name not allowed
[E.g., mailbox syntax incorrect]
500構文エラー、パラメタか議論502Commandの認識されていない[これはあまりに長い間、コマンドラインなどの誤りを含むかもしれない]501Syntax誤りが503Bad系列を実行しなかったコマンドは504Commandパラメタが取られなかった550Requested行動を実行しなかったと命令します: メールボックス[例えば、見つけられなかったメールボックス、アクセスがありません]入手できない552Requestedメール動作は中止になりました: 取られなかった超えられている記憶領域の割当て[現在のメールボックス位置への]553Requested行動: 許容されなかったメールボックス名[例えば、メールボックス構文不正確である、]
[Page 24] Sluizer & Postel
[24ページ] Sluizerとポステル
RFC 780 May 1981
Mail Transfer Protocol
RFC780 1981年5月のメール転送プロトコル
5.3. SEQUENCING OF COMMANDS AND REPLIES
5.3. コマンドと回答の配列
The communication between the sender and receiver is intended to
be an alternating dialogue. As such, the sender issues an MTP
command and the receiver responds with a prompt primary reply.
The sender should wait for this response before sending further
commands.
送付者と受信機とのコミュニケーションは交互の対話であることを意図します。 そういうものとして、送付者はMTPコマンドを発行します、そして、受信機は迅速な第一の回答で応じます。 さらなるコマンドを送る前に、送付者はこの応答を待つべきです。
The preliminary (1xx) and intermediate (3xx) replies indicate that
further commands and information are required to complete the
required action. The preliminary replies require either a
continue or abort command to proceed; the intermediate replies
require action dependent further commands.
予備的(1xx)、そして、中間的な(3xx)回答は、さらなるコマンドと情報が必要な操作を完了するのに必要であることを示します。 予備の回答は、aが続けているどちらかを必要とするか、または続くコマンドを中止します。 中間的回答はさらなる動作に依存するコマンドを必要とします。
One important reply is the connection greetings. Under normal
circumstances, a receiver will send a 220 "Awaiting input" reply
when the connection is completed. The sender should wait for this
greeting message before sending any commands. If the receiver is
unable to accept input right away, it should send a 120 "Expected
delay" reply immediately. The sender can then indicate it is
willing to wait via a continue command, or not via the abort
command. The receiver will respond to the abort with a 201 reply,
and to the continue with the 220 reply when ready.
1つの重要な回答は接続挨拶です。 接続が終了しているとき、通常の状況下で、受信機は220「待ち入力」回答を送るでしょう。 どんなコマンドも送る前に、送付者はこのあいさつメッセージを待つべきです。 受信機がすぐ入力を受け入れることができないなら、それはすぐに、120「予想どおりの遅延」回答を送るべきです。 そして、送付者は、続行コマンドで中止コマンドで待っても構わないと思っているのを示すことができます。 そして、受信機が201回答でアボートに応じる、準備ができているときには220回答を続行してください。
Note: all the greeting type replies have the official name of
the server host as the first word following the reply code.
以下に注意してください。 すべての挨拶タイプ回答には、回答コードに従って、最初の単語としてサーバー・ホストの正式名称があります。
For example,
例えば
220 <SP> USC-ISIF <SP> Service ready <CRLF>
220 <の>のServiceの持ち合わせの<CRLF SP>USC-ISIF<SP>。
The table below lists alternative success and failure replies for
each command. These must be strictly adhered to; a receiver may
substitute text in the replies, but the meaning and action implied
by the code numbers and by the specific command reply sequence
cannot be altered.
代替の成功と失敗が各コマンドのために返答するリストの下のテーブル。 厳密にこれらを固く守らなければなりません。 受信機は回答におけるテキストを代入するかもしれませんが、コード番号と特定のコマンド回答系列によって含意された意味と動作は変更できません。
COMMAND-REPLY SEQUENCES
コマンド回答系列
Each command is listed with its possible replies. Preliminary
replies are listed first with their succeeding replies indented
under them, then success and failure completion, and finally
intermediary replies with the remaining commands from the
sequence following. The prefixes used before the possible
replies are "P" for preliminary, "I" for intermediate, "S" for
success, "F" for failure, and "E" for error. The 421 reply
各コマンドは可能な回答で記載されています。 系列からの残っているコマンドが続いていて、予備の回答は次に、最初に、それらの下で字下がりにされた彼らの続く回答、成功、失敗完成、および最終的に仲介者回答で記載されています。 可能な回答の前に使用された接頭語は、準備段階のための「P」と、中間的のための「私」と、成功のための「S」と、失敗のための「F」と、誤りのための「E」です。 421回答
Sluizer & Postel [Page 25]
Sluizerとポステル[25ページ]
May 1981 RFC 780 Mail Transfer Protocol
1981RFC780が転送プロトコルを郵送しますように。
(service not available, closing transmission channel) may be
given to any command if the MTP-receiver knows it must shut
down. This listing forms the basis for the State Diagrams, in
Section 5.4.
MTP-受信機が、それが停止しなければならないのを知っているなら、(利用可能で、終わりのトランスミッションチャンネルではなく、サービス)をどんなコマンドにも与えるかもしれません。 このリストはセクション5.4で州Diagramsの基礎を形成します。
CONNECTION ESTABLISHMENT
P: 120 -> CONT -> S: 220
F: 421
ABRT S: 201
F: 421
S: 220
F: 421
MAIL
P: 151 -> CONT -> I: 354 -> text -> S: 250
152 F: 451,552,450,
550,452,553
ABRT -> S: 201
F: 451,552,450,550,452,553
I: 354 -> text -> S: 250
F: 451,552,450,550,452,553
F: 451, 552, 450, 550, 452, 553
E: 500, 501, 502, 421
MRSQ
S: 200, 215
E: 500, 501, 502, 504, 421
MRCP
P: 151 -> CONT -> S: 200, 215, 250
152 F: 451,552,450,550,452,553
ABRT -> S: 201
F: 451,552,450,550,452,553
S: 200, 215, 250
F: 451, 552, 450, 550, 452, 553
E: 500, 501, 502, 503, 421
コネクション確立P: 120 ->CONT->S: 220F: 421ABRT S: 201F: 421秒間: 220F: 421 メールP: 151 ->CONT->I: 354 ->テキスト->S: 250 152F: 4億5155万2450、5億5045万2553ABRT->S: 201F: 45京1552兆4505億5045万2553、私: 354 ->テキスト->S: 250F: 45京1552兆4505億5045万2553F: 451、552、450、550、452、553E: 500、501、502、421MRSQ S: 200、215E: 500、501、502、504、421MRCP P: 151 ->CONT->S: 200、215、250 152F: 45京1552兆4505億5045万2553 ABRT->S: 201F: 451,552,450,550,452,553秒間: 200、215、250F: 451、552、450、550、452、553E: 500, 501, 502, 503, 421
[Page 26] Sluizer & Postel
[26ページ] Sluizerとポステル
RFC 780 May 1981
Mail Transfer Protocol
RFC780 1981年5月のメール転送プロトコル
QUIT
S: 221
E: 500, 421
HELP
S: 211, 214
E: 500, 501, 502, 504, 421
NOOP
S: 200
E: 500, 421
CONT
S: depends on previous command
F: depends on previous command
E: 500, 501, 502, 504, 421
ABRT
S: 201,
E: 500, 501, 502, 504, 421
Sをやめてください: 221E: 500、421はSを助けます: 211、214E: 500、501、502、504、421NOOP S: 200E: 500、421CONT S: 前のコマンドFによります: 前のコマンドEによります: 500、501、502、504、421ABRT S: 201、E: 500, 501, 502, 504, 421
Sluizer & Postel [Page 27]
Sluizerとポステル[27ページ]
May 1981 RFC 780 Mail Transfer Protocol
1981RFC780が転送プロトコルを郵送しますように。
5.4. STATE DIAGRAMS
5.4. 州のダイヤグラム
Following are state diagrams for a very simple minded MTP
implementation. Only the first digit of the reply codes is used.
There is one state diagram for each group of MTP commands.
以下に、非常に簡単な気にされたMTP実現のための州のダイヤグラムがあります。 回答コードの最初のケタだけが使用されています。 MTPコマンドの各グループあたり1個の州のダイヤグラムがあります。
The command groupings were determined by constructing a model for
each command and then collecting together the commands with
structurally identical models.
コマンド組分けは、各コマンドのためにモデルを構成して、次に、コマンドを一緒に集めることによって、構造的に同じモデルに決定していました。
For each command there are three possible outcomes: "success"
(S), "failure" (F), and "error" (E). In the state diagrams below
we use the symbol B for "begin", and the symbol W for "wait for
reply".
各コマンドのために、3つの可能な結果があります: 「成功」(S)、「失敗」(F)、および「誤り。」(E) 以下の州のダイヤグラムで、私たちは、「始まってください」にシンボルBを使用して、「回答のための待ち」にシンボルWを使用します。
First, the diagram that represents most of the MTP commands:
まず最初に、MTPの大部分を表すダイヤグラムは以下を命令します。
1,3 +---+
----------->| E |
| +---+
|
+---+ cmd +---+ 2 +---+
| B |---------->| W |---------->| S |
+---+ +---+ +---+
|
| 4,5 +---+
----------->| F |
+---+
1,3 +---+ ----------->| E| | +---+ | +---+ cmd+---+ 2 +---+ | B|、-、-、-、-、-、-、-、-、--、>| W|、-、-、-、-、-、-、-、-、--、>| S| +---+ +---+ +---+ | | 4,5 +---+ ----------->| F| +---+
This diagram models the commands:
このダイヤグラムはコマンドをモデル化します:
HELP, MRCP, MRSQ, NOOP, QUIT, ABRT.
ヘルプ、ABRT、MRCP(MRSQ、NOOP)はやめます。
[Page 28] Sluizer & Postel
[28ページ] Sluizerとポステル
RFC 780 May 1981
Mail Transfer Protocol
RFC780 1981年5月のメール転送プロトコル
A more complex diagram models the MAIL command:
より複雑なダイヤグラムはメールコマンドをモデル化します:
ABRT +---+ 1,3
CONT ---- ------------->| W |-------
| | +---+ |
| |1 4,5| |2 V
+---+ cmd -->+---+ 2 | | +---+
| B |---------->| W |-------------------->| E |
+---+ +---+ ------------>+---+
3| |4,5 | | |
| | | | |
-------------- ------ | | |
| | | | ---->+---+
| ----------------------->| S |
| | | | | +---+
| | -------- |
| | | | |
V 2| |1,3 | |
+---+ text +---+ | ------->+---+
| |---------->| W | --------------->| F |
+---+ +---+-------------------->+---+
4,5
ABRT+---+ 1、3CONT---- ------------->| W|------- | | +---+ | | |1 4,5| |2 +に対して---+cmd-->+---+ 2 | | +---+ | B|、-、-、-、-、-、-、-、-、--、>| W|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| E| +---+ +---+ ------------>+---+ 3| |4,5 | | | | | | | | -------------- ------ | | | | | | | ---->+---+ | ----------------------->| S| | | | | | +---+ | | -------- | | | | | | V2| |1,3 | | +---+ テキスト+---+ | ------->+---+ | |、-、-、-、-、-、-、-、-、--、>| W| --------------->| F| +---+ +---+-------------------->+---+ 4,5
Note that the "text" here is a series of lines sent from the
sender to the receiver with no response expected until the last
line is sent.
ここの「テキスト」が最終ラインを送るまで予想された応答なしで送付者から受信機に送られた一連の線であることに注意してください。
Sluizer & Postel [Page 29]
Sluizerとポステル[29ページ]
May 1981 RFC 780 Mail Transfer Protocol
1981RFC780が転送プロトコルを郵送しますように。
5.5. DETAILS
5.5. 詳細
5.5.1. MINIMUM IMPLEMENTATION
5.5.1. 最小の実現
In order to make MTP workable, the following minimum
implementation is required for all receivers:
MTPを実行可能にして、以下の最小の実現がすべての受信機に必要です:
COMMANDS -- MAIL
QUIT
NOOP
コマンド--メールはNOOPをやめました。
5.5.2. TRANSPARENCY
5.5.2. 透明
Without some provision for data transparency the character
sequence "<CRLF>.<CRLF>" ends the the mail text and cannot be
sent by the user. In general, users are not aware of such
"forbidden" sequences. To allow all user composed text to be
transmitted transparently the following procedures are used.
データ透明への何らかの支給がなければ、キャラクタシーケンス「<CRLF><CRLF>」を、メールテキストを終わらせて、ユーザは送ることができません。 一般に、ユーザは系列が「禁じられた」そのようなものを意識していません。 透明に伝えられるためにすべてのユーザに落ち着いたテキストを許容するために、以下の手順は使用されています。
1. Before sending a line of mail text the sender-MTP checks the
first character of the line. If it is a period, one additional
period is inserted at the beginning of the line.
1. 以前、送付者-MTPをメールテキストの線に送ると、線の最初のキャラクタはチェックします。 それが期間であるなら、ある追加期間は線の始めに挿入されます。
2. When a line of mail text is received by the receiver-MTP it
checks the the line. If the line is composed of a single
period it is the end of mail. If the first character is a
period and there are other characters on the line, the first
character is deleted.
2. メールテキストの台詞が受信機-MTPによって受けられるとき、それは線をチェックします。 線がただ一つの期間で構成されるなら、メールの終わりです。 最初のキャラクタが期間であり、線の上に他のキャラクタがあれば、最初のキャラクタは削除されます。
5.5.3. SIZES
5.5.3. サイズ
There are several objects that ought to have defined maximum
sizes.
最大サイズを定義するべきであった数個の物があります。
user
ユーザ
The maximum total length of a user name is 40 characters.
ユーザ名の最大の全長は40のキャラクタです。
host
ホスト
The maximum total length of a host name or number is 20
characters.
ホスト名か数の最大の全長は20のキャラクタです。
[Page 30] Sluizer & Postel
[30ページ] Sluizerとポステル
RFC 780 May 1981
Mail Transfer Protocol
RFC780 1981年5月のメール転送プロトコル
path
経路
The maximum total length of a sender-path or
receiver-path is 100 characters.
送付者道か受信機経路の最大の全長は100のキャラクタです。
command line
コマンドライン
The maximum total length of a command line including the
command word and the <CRLF> is 200 characters.
コマンド単語と<CRLF>を含むコマンドラインの最大の全長は200のキャラクタです。
reply line
回答線
The maximum total length of a reply line including the
reply code and the <CRLF> is 65 characters.
回答コードと<CRLF>を含む回答線の最大の全長は65のキャラクタです。
text line
テキスト線
The maximum total length of a text line including the the
<CRLF> is 1000 characters.
<CRLF>を含むテキスト線の最大の全長は1000のキャラクタです。
To the maximum extent possible implementation techniques which
impose no limits at all to the length of these objects should
be used.
最大の範囲可能な実現のテクニックに、どれがこれらの物の長さに限界を全く課さないかは使用されるべきです。
Sluizer & Postel [Page 31]
Sluizerとポステル[31ページ]
May 1981 RFC 780 Mail Transfer Protocol
1981RFC780が転送プロトコルを郵送しますように。
APPENDIX A
付録A
TCP Transport service
TCP Transportサービス
The Transmission Control Protocol [1] is used in the ARPA
Internet, and in any network following the US DoD standards for
internetwork protocols.
通信制御プロトコル[1]はARPAインターネット、およびインターネットワークプロトコルの米国DoD規格に続くどんなネットワークにも使用されます。
Connection Establishment
コネクション確立
The MTP transmission channel is a TCP connection established
between the sender process port U and the receiver process port
L. This single full duplex connection is used as the
transmission channel. This protocol is assigned the service
port 57 (71 octal), that is L=57.
MTPトランスミッションチャンネルは送付者過程ポートUと受信機過程ポートL.の間で確立されたTCP接続です。Thisの単独の全二重接続はトランスミッションチャンネルとして使用されます。 サービスポート57(71 8進)、すなわち、L=57はこのプロトコルに割り当てられます。
Data Transfer
データ転送
The TCP connection supports the transmission of 8-bit bytes.
The MTP data is 7-bit ASCII characters. Each character is
transmitted as a 8-bit byte with the high-order bit cleared to
zero.
TCP接続は8ビットのバイトの送信を支持します。 MTPデータは7ビットのASCII文字です。 高位のビットがゼロまできれいにされている状態で、各キャラクタは8ビットのバイトとして伝えられます。
[Page 32] Sluizer & Postel
[32ページ] Sluizerとポステル
RFC 780 May 1981
Mail Transfer Protocol
RFC780 1981年5月のメール転送プロトコル
APPENDIX B
付録B
NCP Transport service
NCP Transportサービス
The ARPANET Host-to-Host Protocol [2] (implemented by the Network
Control Program) may be used in the ARPANET.
アルパネットHostからホストへのプロトコル[2](Network Control Programによって実行されます)はアルパネットに使用されるかもしれません。
Connection Establishment
コネクション確立
The MTP transmission channel is established via NCP between the
the sender process socket U and receiver process socket L. The
Initial Connection Protocol [3] is followed resulting in a pair
of simplex connections. This pair of connections is used as
the transmission channel. This protocol is assigned the
contact socket 57 (71 octal), that is L=57.
MTPトランスミッションチャンネルは送付者過程ソケットUと受信機過程ソケットL.の間のNCPで確立されます。Initial Connectionプロトコル[3]は、1組のシンプレクス接続をもたらしながら、従われています。 接続のこの組はトランスミッションチャンネルとして使用されます。 接触ソケット57(71 8進)、すなわち、L=57はこのプロトコルに割り当てられます。
Data Transfer
データ転送
The NCP data connections are established in 8-bit byte mode.
The MTP data is 7-bit ASCII characters. Each character is
transmitted as a 8-bit byte with the high-order bit cleared to
zero.
NCPデータ接続は8ビットのバイトモードに確立されます。 MTPデータは7ビットのASCII文字です。 高位のビットがゼロまできれいにされている状態で、各キャラクタは8ビットのバイトとして伝えられます。
Sluizer & Postel [Page 33]
Sluizerとポステル[33ページ]
May 1981 RFC 780 Mail Transfer Protocol
1981RFC780が転送プロトコルを郵送しますように。
APPENDIX C
付録C
NITS
夜
The Network Independent Transport Service [4] may be used.
Network無党派Transport Service[4]は使用されるかもしれません。
Connection Establishment
コネクション確立
The MTP transmission channel is established via NITS between
the the sender process and receiver process. The sender
process executes the CONNECT primitive, and the waiting
receiver process executes the ACCEPT primitive.
MTPトランスミッションチャンネルは送付者の過程と受信機の過程の間のNITSを通して確立されます。 送付者の過程は原始的にCONNECTを実行します、そして、待ち受信機の過程は原始的にACCEPTを実行します。
Data Transfer
データ転送
The NITS connection supports the transmission of 8-bit bytes.
The MTP data is 7-bit ASCII characters. Each character is
transmitted as a 8-bit byte with the high-order bit cleared to
zero.
NITS接続は8ビットのバイトの送信を支持します。 MTPデータは7ビットのASCII文字です。 高位のビットがゼロまできれいにされている状態で、各キャラクタは8ビットのバイトとして伝えられます。
[Page 34] Sluizer & Postel
[34ページ] Sluizerとポステル
RFC 780 May 1981
Mail Transfer Protocol
RFC780 1981年5月のメール転送プロトコル
APPENDIX D
付録D
X.25 Transport service
X.25輸送サービス
It may be possible to use the X.25 service [5] as provided by the
Public Data Networks directly, but there are indications that it
is too error prone to qualify as a reliable channel. It is
suggested that a reliable end-to-end protocol such as TCP be used
on top of X.25 connections.
[5] Public Data Networksによって直接提供されるようにX.25サービスを利用するのが可能であるかもしれませんが、それは誤り高信頼のチャンネルの資格を得ることができないくらい傾向があるという指摘があります。 終わりから終わりへのTCPなどの信頼できるプロトコルがX.25接続の上で使用されることが提案されます。
Sluizer & Postel [Page 35]
Sluizerとポステル[35ページ]
May 1981 RFC 780 Mail Transfer Protocol
1981RFC780が転送プロトコルを郵送しますように。
APPENDIX E
付録E
Theory of Reply Codes
回答コードの理論
The three digits of the reply each have a special significance.
The first digit denotes whether the response is good, bad or
incomplete. An unsophisticated sender-MTP will be able to
determine its next action (proceed as planned, redo, retrench,
etc.) by simply examining this first digit. A sender-MTP that
wants to know approximately what kind of error occurred (e.g.,
mail system error, command syntax error) may examine the second
digit, reserving the third digit for the finest gradation of
information.
それぞれ回答の3ケタは特別な意義があります。 応答が良いか、悪いかまたは不完全であることにかかわらずケタが指示する1番目。 世慣れていない送付者-MTPが次の動作を決定できる、(計画通り続いてください、改装、など) 単に調べるのによるこの最初のケタに節約してください。 どういう誤りが周囲に発生したかを(例えば、システム誤りを郵送してください、コマンド構文エラー)知りたがっている送付者-MTPは2番目のケタを調べるかもしれません、情報の最もすばらしい段階のために3番目のケタを予約して。
There are five values for the first digit of the reply code:
回答コードの最初のケタのための5つの値があります:
1yz Positive Preliminary reply
1yz Positive Preliminary回答
The command has been accepted, but the requested action
is being held in abeyance, pending confirmation of the
information in this reply. The sender-MTP should send
another command specifying whether to continue or abort
the action.
コマンドを受け入れましたが、要求された動作を停止しているのに保っています、この回答における、情報の確認まで。 送付者-MTPは別のコマンドに動作を続けているか、または中止するかを指定させるはずです。
2yz Positive Completion reply
2yz Positive Completion回答
The requested action has been successfully completed. A
new request may be initiated.
要求された操作は首尾よく完了しました。 新しい要求は開始されるかもしれません。
3yz Positive Intermediate reply
3yz Positive Intermediate回答
The command has been accepted, but the requested action
is being held in abeyance, pending receipt of further
information. The sender-MTP should send another command
specifying this information. This reply is used in
command sequence groups.
コマンドを受け入れましたが、詳細の領収書まで停止しているのに要求された動作を保っています。 送付者-MTPは別のコマンドにこの情報を指定させるはずです。 この回答はコマンド・シーケンスグループに使用されます。
4yz Transient Negative Completion reply
4yz Transient Negative Completion回答
The command was not accepted and the requested action did
not occur. However, the error condition is temporary and
the action may be requested again. The sender should
return to the beginning of the command sequence (if any).
It is difficult to assign a meaning to "transient" when
two different sites (receiver- and sender- MTPs) must
agree on the interpretation. Each reply in this category
コマンドは受け入れられませんでした、そして、要求された動作は起こりませんでした。 しかしながら、エラー条件は一時的です、そして、動作は再び要求されているかもしれません。 送付者はコマンド・シーケンス(もしあれば)の始まりまで戻るべきです。 2つの異なったサイト(受信機と送付者MTPs)が解釈に同意しなければならないとき、「一時的に」意味を割り当てるのは難しいです。 このカテゴリにおける各回答
[Page 36] Sluizer & Postel
[36ページ] Sluizerとポステル
RFC 780 May 1981
Mail Transfer Protocol
RFC780 1981年5月のメール転送プロトコル
might have a different time value, but the sender-MTP is
encouraged to try again. A rule of thumb to determine if
a reply fits into the 4yz or the 5yz category (see below)
is that replies are 4yz if they can be repeated without
any change in command form or in properties of the sender
or receiver. (E.g., the command is repeated identically;
the receiver does not put up a new implementation).
力には、異なった時間的価値がありますが、送付者-MTPが再試行するよう奨励されます。 回答が4yzか5yzカテゴリに収まるなら(以下を見てください)、決定する経験則は送付者か受信機についてコマンドフォームか特性における少しも変化なしでそれらを繰り返すことができるなら回答が4yzであるということです。. (例えばコマンドは同様に繰り返されます; 受信機は新しい実現を提供しません。)
5yz Permanent Negative Completion reply
5yz Permanent Negative Completion回答
The command was not accepted and the requested action did
not occur. The sender-MTP is discouraged from repeating
the exact request (in the same sequence). Even some
"permanent" error conditions can be corrected, so the
human user may want to direct the sender-MTP to
reinitiate the command sequence by direct action at some
point in the future (e.g., after the spelling has been
changed, or the user has altered the account status.)
コマンドは受け入れられませんでした、そして、要求された動作は起こりませんでした。 送付者-MTPは、正確な要求(同じ系列の)を繰り返して、がっかりしています。 人間のユーザは、いくつかの「永久的な」エラー条件さえ修正できるので、いくつかの直接行動によるコマンド・シーケンスが将来指す再開始に送付者-MTPを向けたがっているかもしれません。(例えば、スペルを変えたか、またはユーザがアカウントステータスを変更した後に。)
The second digit encodes responses in specific categories:
2番目のケタは特定のカテゴリにおける応答をコード化します:
x0z Syntax -- These replies refer to syntax errors,
syntactically correct commands that don't fit any
functional category, and unimplemented or superfluous
commands.
x0z構文--これらの回答は構文エラー、どんな機能的なカテゴリにも合わないシンタクス上正しいコマンド、および非実行されたか余計なコマンドを示します。
x1z Information -- These are replies to requests for
information, such as status or help.
x1z情報--これらは、状態などの情報に関する要求に関する回答であるか助けます。
x2z Connections -- These are replies referring to the
transmission channel.
x2zコネクションズ--これらはトランスミッションチャンネルについて言及する回答です。
x3z Unspecified as yet.
まだ不特定のx3z。
x4z Unspecified as yet.
まだ不特定のx4z。
x5z Mail system -- These replies indicate the status of
the receiver mail system vis-a-vis the requested
transfer or other mail system action.
x5zメールシステム--これらの回答は要求された転送か他のメールシステム動作と向かいあって受信機メールシステムの状態を示します。
The third digit gives a finer gradation of meaning in each
category specified by the second digit. The list of replies
illustrates this. Each reply text is recommended rather than
mandatory, and may even change according to the command with
which it is associated. On the other hand, the reply codes
must strictly follow the specifications in this section.
3番目のケタは2番目のケタによって指定された各カテゴリにおける意味の、よりすばらしい段階を与えます。 回答のリストはこれを例証します。 それぞれの回答テキストは、義務的であるというよりむしろお勧めであり、それが関連しているコマンドに応じて、変化さえするかもしれません。 他方では、回答コードは厳密にこのセクションの仕様に従わなければなりません。
Sluizer & Postel [Page 37]
Sluizerとポステル[37ページ]
May 1981 RFC 780 Mail Transfer Protocol
1981RFC780が転送プロトコルを郵送しますように。
Receiver implementations should not invent new codes for
slightly different situations from the ones described here, but
rather adapt codes already defined.
受信機実装はここで説明されたものからわずかに異なった状況のための新法を発明するべきではありませんが、むしろ既に定義されたコードを適合させてください。
For example, a command such as NOOP whose successful execution
does not offer the sender-MTP any new information will return a
200 reply. The response is 502 when the command requests an
unimplemented non-site-specific action. A refinement of that
is the 504 reply for a command that is implemented, but that
requests an unimplemented parameter.
例えば、うまくいっている実行が送付者-MTPに少しの新情報も提供しないNOOPなどのコマンドは200回答を返すでしょう。 コマンドが非実装している非サイトの詳細動作を要求するとき、応答は502です。 その気品は実装されますが、非実装しているパラメタを要求するコマンドのための504回答です。
The reply text may be longer than a single line; in these cases
the complete text must be marked so the sender-MTP knows when it
can stop reading the reply. This requires a special format to
indicate a multiple line reply.
回答テキストは単線より長いかもしれません。 これらの場合では、全文をマークしなければならないので、送付者-MTPは、それが、いつ回答を読むのを止めることができるかを知っています。 これは、複数の系列回答を示すために特別な形式を必要とします。
The format for multi-line replies requires that every line,
except the last, begin with the reply code, followed
immediately by a hyphen, "-" (also known as minus), followed by
text. The last line will begin with the reply code, followed
immediately by <SP>, optionally some text, and <CRLF>.
マルチ系列回答のための形式は、最終を除いて、テキストがすぐにハイフン、「-」(また、マイナスとして、知られている)であとに続く回答コードのあとに続いていてあらゆる系列が始まるのを必要とします。 最終ラインはすぐ<SP>によって従われた回答コードで任意に始まるでしょう。何らかのテキスト、および<CRLF>。
For example:
123-First line
123-Second line
123-234 text beginning with numbers
123 The last line
例えば: No.123で最終ラインを始める123セカンドラインの最初に123系列123-234テキスト
The sender-MTP then simply needs to search for the reply code
followed by <SP> at the beginning of a line, and ignore all
preceding lines.
そして、送付者-MTPは単に系列の始めの<SP>によって従われた回答コードを捜し求めて、すべての前の系列を無視する必要があります。
[Page 38] Sluizer & Postel
[38ページ] Sluizerとポステル
RFC 780 May 1981
Mail Transfer Protocol
RFC780 1981年5月のメール転送プロトコル
GLOSSARY
用語集
ASCII
ASCII
American Standard Code for Information Interchange [6].
情報交換用米国標準コード[6]。
command
コマンド
A request for a mail service action sent by the sender-MTP to the
receiver-MTP.
送付者-MTPによって受信機-MTPに送られたメールサービス動作を求める要求。
host
ホスト
A computer in the internetwork environment on which mailboxes or
MTP processes reside.
メールボックスかMTPプロセスが住んでいるインターネットワーク環境におけるコンピュータ。
line
系列
A line of text ending with a <CRLF>.
<CRLF>があるテキスト行結末。
メール
A sequence of ASCII characters of arbitrary length, which conforms
to the standard set in RFC 733 (Standard for the Format of ARPA
Network Text Messages [7]).
任意の長さのASCII文字の系列、規格に従うものはRFC733にセットしました。(アーパネットText Messages[7])のFormatにおいて、標準です。
mailbox
メールボックス
A character string (address) which identifies a user to whom mail
is to be sent. Mailbox normally consists of the host and user
specifications. The standard mailbox naming convention is defined
to be "user@host". Additionally, the "container" in which mail is
stored.
送られるメールがことであるユーザを特定する文字列(アドレス)。 通常、メールボックスはホストとユーザ仕様から成ります。 一般的なメールボックス命名規則は、" user@host "になるように定義されます。 さらに、「コンテナ」はどのメールで保存されるか。
receiver-MTP process
受信機-MTPプロセス
A process which transfers mail in cooperation with a sender-MTP
process. It waits for a connection to be established via the
transport service. It receives MTP commands from the sender-MTP,
sends replies, and governs the transfer of mail.
送付者-MTPプロセスと提携してメールを移すプロセス。 それは、接続が輸送サービスで確立されるのを待っています。 それは、送付者-MTPからMTPコマンドを受け取って、回答を送って、メールの転送を治めます。
Sluizer & Postel [Page 39]
Sluizerとポステル[39ページ]
May 1981 RFC 780 Mail Transfer Protocol
1981RFC780が転送プロトコルを郵送しますように。
reply
返信
A reply is an acknowledgment (positive or negative) sent from
receiver to sender via the transmission channel in response to a
MTP command. The general form of a reply is a completion code
(including error codes) followed by a text string. The codes are
for use by programs and the text is usually intended for human
users.
回答はMTPコマンドに対応したトランスミッションチャンネルで受信機から送付者に送られた承認(肯定しているか否定している)です。 回答の一般的なフォームはテキスト文字列がいうことになった完了コード(エラーコードを含んでいる)です。 プログラムによってコードは使用のためのものです、そして、通常、テキストは人間のユーザのために意図します。
sender-MTP process
送付者-MTPプロセス
A process which transfers mail in cooperation with a receiver-MTP
process. A local language may be used in the user interface
command/reply dialogue. The sender-MTP initiates the transport
service connection. It initiates MTP commands, receives replies,
and governs the transfer of mail.
受信機-MTPプロセスと提携してメールを移すプロセス。 現地語はユーザーインタフェースコマンド/回答対話に使用されるかもしれません。 送付者-MTPは輸送サービス連結部を開始します。 それは、MTPコマンドを開始して、回答を受け取って、メールの転送を治めます。
transmission channel
トランスミッションチャンネル
A full-duplex communication path between a sender-MTP and a
receiver-MTP for the exchange of commands, replies, and mail text.
コマンド、回答、およびメールテキストの交換のための送付者-MTPと受信機-MTPの間の全二重通信経路。
transport service
輸送サービス
Any reliable stream-oriented data communication services. For
example, NCP, TCP, NITS.
どんな信頼できるストリーム指向のデータ通信サービス。 例えば、NCP、TCP、NITS。
user
ユーザ
A human being (or a process on behalf of a human being) wishing to
obtain mail transfer service. In addition, a recipient of
computer mail.
郵便為替サービスを得たがっている人間(または、人間を代表したプロセス)。 追加、コンピュータメールの受取人で。
word
単語
A human being (or a process on behalf of a human being) wishing to
obtain mail transfer service. In addition, a recipient of
computer mail.
郵便為替サービスを得たがっている人間(または、人間を代表したプロセス)。 追加、コンピュータメールの受取人で。
<CRLF>
<CRLF>。
The characters carriage return and line feed (in that order).
キャラクタ復帰と改行(そのオーダーにおける)。
[Page 40] Sluizer & Postel
[40ページ] Sluizerとポステル
RFC 780 May 1981
Mail Transfer Protocol
RFC780 1981年5月のメール転送プロトコル
<SP>
<SP>。
The space character.
間隔文字。
Sluizer & Postel [Page 41]
Sluizerとポステル[41ページ]
May 1981 RFC 780 Mail Transfer Protocol
1981RFC780が転送プロトコルを郵送しますように。
REFERENCES
参照
[1] TCP
[1] TCP
Postel, J., ed., "DOD Standard Transmission Control Protocol",
IEN 129, RFC 761, USC/Information Sciences Institute,
NTIS ADA082609, January 1980. Appears in: Computer Communication
Review, Special Interest Group on Data Communications, ACM, V.10,
N.4, October 1980.
ポステル、J.、教育、「DODの標準の通信制御プロトコル」、IEN129、RFC761、USC/情報Sciences Institute、NTIS ADA082609、1月1980日 中に現れます: コンピュータコミュニケーションレビュー、データ通信での特殊利益集団、ACM、V.10、N.4、1980年10月。
[2] NCP
[2] NCP
McKenzie,A., "Host/Host Protocol for the ARPA Network", NIC 8246,
January 1972. Also in: Feinler, E. and J. Postel, eds., "ARPANET
Protocol Handbook", NIC 7104, for the Defense Communications
Agency by SRI International, Menlo Park, California, Revised
January 1978.
マッケンジー、A.、「アーパネットのためのホスト/ホストプロトコル」、NIC8246、1972年1月。 以下でも Feinler、E.、およびJ.ポステル(eds)、「アルパネットはハンドブックについて議定書の中で述べます」、NIC7104、SRIインターナショナルによるDefense Communications Agencyのために、メンローパーク(カリフォルニア)Revised1978年1月。
[3] Initial Connection Protocol
[3] 初期の接続プロトコル
Postel, J., "Official Initial Connection Protocol", NIC 7101,
11 June 1971. Also in: Feinler, E. and J. Postel, eds., "ARPANET
Protocol Handbook", NIC 7104, for the Defense Communications
Agency by SRI International, Menlo Park, California, Revised
January 1978.
ポステル、J.、「公式の初期の接続プロトコル」、NIC7101、1971年6月11日。 以下でも Feinler、E.、およびJ.ポステル(eds)、「アルパネットはハンドブックについて議定書の中で述べます」、NIC7104、SRIインターナショナルによるDefense Communications Agencyのために、メンローパーク(カリフォルニア)Revised1978年1月。
[4] NITS
[4] 夜
PSS/SG3, "A Network Independent Transport Service", Study Group 3,
The Post Office PSS Users Group, February 1980. Available from
the DCPU, National Physical Laboratory, Teddington, UK.
「ネットワークの独立している輸送サービス」というPSS/SG3はグループ3を研究して、ポスト紙オフィスPSSユーザは1980年2月に分類します。 DCPU、国立物理研究所、Teddington、イギリスから、利用可能です。
[5] X.25
[5] X.25
CCITT, "Recommendation X.25 - Interface Between Data Terminal
Equipment (DTE) and Data Circuit-terminating Equipment (DCE) for
Terminals Operating in the Packet Mode on Public Data Networks,"
CCITT Orange Book, Vol. VIII.2, International Telephone and
Telegraph Consultative Committee, Geneva, 1976.
CCITT、「推薦X.25--公共のデータ網がパケット形態で作動して、データ端末装置(DTE)と回路を終えるデータ設備(DCE)の間で端末に連結する」CCITTオレンジブック、Vol.VIII.2、国際電信電話諮問委員会、ジュネーブ、1976。
[Page 42] Sluizer & Postel
[42ページ] Sluizerとポステル
RFC 780 May 1981
Mail Transfer Protocol
RFC780 1981年5月のメール転送プロトコル
[6] ASCII
[6] ASCII
ASCII, "USA Code for Information Interchange", United States of
America Standards Institute, X3.4, 1968. Also in: Feinler, E.
and J. Postel, eds., "ARPANET Protocol Handbook", NIC 7104, for
the Defense Communications Agency by SRI International, Menlo
Park, California, Revised January 1978.
アメリカ合衆国規格は、ASCII、「米国情報交換用符号」とX3.4、1968に設けます。 以下でも Feinler、E.、およびJ.ポステル(eds)、「アルパネットはハンドブックについて議定書の中で述べます」、NIC7104、SRIインターナショナルによるDefense Communications Agencyのために、メンローパーク(カリフォルニア)Revised1978年1月。
[7] RFC 733
[7] RFC733
Crocker, D., J. Vittal, K. Pogran, and D. Henderson, "Standard for
the Format of ARPA Network Text Messages," RFC 733, NIC 41952,
November 1977. Also in: Feinler, E. and J. Postel, eds.,
"ARPANET Protocol Handbook", NIC 7104, for the Defense
Communications Agency by SRI International, Menlo Park,
California, Revised January 1978.
クロッカー、D.、J.Vittal、K.Pogran、およびD.ヘンダーソン、「アーパネットテキスト・メッセージの形式の規格」、RFC733、NIC41952(1977年11月)。 以下でも Feinler、E.、およびJ.ポステル(eds)、「アルパネットはハンドブックについて議定書の中で述べます」、NIC7104、SRIインターナショナルによるDefense Communications Agencyのために、メンローパーク(カリフォルニア)Revised1978年1月。
Sluizer & Postel [Page 43]
Sluizerとポステル[43ページ]
一覧
スポンサーリンク
