RFC772 日本語訳
0772 Mail Transfer Protocol. S. Sluizer, J. Postel. September 1980. (Format: TXT=61061 bytes) (Obsoleted by RFC0780, STD0010) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group S. Sluizer
Request for Comments: 772 J. Postel
ISI
September 1980
Sluizerがコメントのために要求するワーキンググループS.をネットワークでつないでください: 772 J.ポステルISI1980年9月
MAIL TRANSFER PROTOCOL
メール転送プロトコル
PREFACE
序文
This is a first draft of this protocol and comments are very definitely requested.
これはこのプロトコルの最初の草稿です、そして、コメントは非常に確実に要求されています。
INTRODUCTION
序論
The objective of Mail Transfer Protocol (MTP) is to transfer mail reliably and efficiently.
メールTransferプロトコル(MTP)の目的は確かに効率的にメールを移すことです。
This paper assumes knowledge of the following protocols described in the ARPA Internet Protocol Handbook. The reader will note strong similarities to portions of the File Transfer Protocol; in part, this is due to the original ARPA Network implementation of computer mail as a feature of FTP.
この紙はARPAインターネットプロトコルHandbookで説明された以下のプロトコルに関する知識を仮定します。 読者はFile Transferプロトコルの部分に強い類似性に注意するでしょう。 これはFTPの特徴としてのコンピュータメールのオリジナルのアーパネット実装の一部ためです。
The ARPANET Host-to-Host Protocol [Network Control Protocol] (NCP)
アルパネットホスト間プロトコル[ネットワーク制御プロトコル](NCP)
The Transmission Control Protocol (TCP)
通信制御プロトコル(TCP)
The TELNET Protocol (TELNET)
telnetプロトコル(telnet)
The File Transfer Protocol (FTP)
ファイル転送プロトコル(FTP)
DISCUSSION
議論
In this section, the terminology and the MTP model are discussed. The terms defined in this section are only those that have special significance in MTP. Some of the terminology is very specific to the MTP model; some readers may wish to turn to the section on the MTP model while reviewing the terminology.
このセクションで、用語とMTPモデルについて議論します。 このセクションで定義された用語はMTPに特別な意味を持っているものにすぎません。 MTPモデルに、用語のいくつかが非常に特定です。 読者の中には用語を見直している間にMTPモデルにセクションに変わりたがっているかもしれない人もいます。
TERMINOLOGY
用語
ASCII
ASCII
The ASCII character set as defined in the ARPA Internet
Protocol Handbook. In MTP, ASCII characters are defined to be
the lower half of an eight-bit code set (i.e., the most
significant bit is zero) and is called NVT-ASCII.
ARPAインターネットプロトコルHandbookで定義されるASCII文字の組。 MTP、ASCII文字に、呼ばれたNVT-ASCIIは、1つの8ビットのコードセット(すなわち、最も重要なビットはゼロである)の下半分になるように定義されて、あります。
1
1
September 1980 RFC 772 Mail Transfer Protocol
1980年9月のRFC772メール転送プロトコル
control connection
コントロール接続
The TCP full-duplex communication path or two NCP simplex
communication paths between a sender-MTP and a receiver-MTP for
the exchange of commands, replies, and mail text. The control
connection operates according to the TELNET Protocol.
コマンド、回答、およびメールテキストの交換のための送付者-MTPと受信機-MTPの間のTCP全二重通信経路か2つのNCPシンプレクス通信路。 TELNETプロトコルによると、コントロール接続は働いています。
data mode
データモード
The mail is transmitted over the control connection as a stream
of octets. (In FTP terminology this is called stream mode.)
メールは八重奏のストリームとしてコントロール接続の上に伝えられます。 (FTP用語で、これはストリームモードと呼ばれます。)
data structure
データ構造
The internal structure of mail is considered to be a continuous
sequence of data octets. (In FTP terminology this is called
file-structure.)
メールの内部の構造はデータ八重奏の連続した系列であると考えられます。 (FTP用語で、これはファイル構造と呼ばれます。)
data representation
データ表現
The internal representation of all data (i.e., mail) is in
NVT-ASCII.
NVT-ASCIIにはすべてのデータ(すなわち、メール)の内部の表現があります。
host
ホスト
A computer in the internetwork environment on which mailboxes
reside.
メールボックスが住んでいるインターネットワーク環境におけるコンピュータ。
MTP commands
MTPコマンド
A set of commands which comprise the control information
flowing from the sender-MTP to the receiver-MTP.
送付者-MTPから受信機-MTPまで流れる制御情報を包括する1セットのコマンド。
mail
メール
An ordered set of computer data of arbitrary length, which
conforms to the standard set in RFC 733 (Standard for the
Format of ARPA Network Text Messages).
1つの順序集合に関する任意の長さに関するコンピュータのデータ。(そのコンピュータのデータはRFC733(アーパネットText Messagesの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 "になるように定義されます。 さらに、「コンテナ」はどのメールで保存されるか。
2
2
RFC 772 September 1980
Mail Transfer Protocol
RFC772 1980年9月のメール転送プロトコル
NVT
NVT
The Network Virtual Terminal as defined in the TELNET Protocol.
TELNETプロトコルで定義されるNetwork Virtual Terminal。
octet
八重奏
Bytes in MTP are octets (8 bits). This is not necessarily the
same byte size in which data is stored in a host.
MTPのバイトは八重奏(8ビット)です。 これはデータがホストに保存される必ず同じバイトサイズではありません。
reply
返信
A reply is an acknowledgment (positive or negative) sent from
receiver to sender via the control connection 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コマンドに対応したコントロール接続で受信機から送付者に送られた承認(肯定しているか否定している)です。 回答の一般的なフォームはテキスト文字列がいうことになった完了コード(エラーコードを含んでいる)です。 プログラムによってコードは使用のためのものです、そして、通常、テキストは人間のユーザのために意図します。
receiver-MTP process
受信機-MTPプロセス
A process which transfers mail in cooperation with a sender-MTP
process. It "listens" on its port/socket L for a connection
from a sender-MTP and establishes a control connection using
the TELNET Protocol. It receives MTP commands from the
sender-MTP, sends replies, and governs the transfer of mail.
送付者-MTPプロセスと提携してメールを移すプロセス。 それは、接続のためのポート/ソケットLで送付者-MTPから「聴い」て、TELNETプロトコルを使用することでコントロール接続を確立します。 それは、送付者-MTPから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
control connection from its port/socket U to the receiver-MTP
process. It initiates MTP commands, receives replies, and
governs the transfer of mail.
受信機-MTPプロセスと提携してメールを移すプロセス。 現地語はユーザーインタフェースコマンド/回答対話に使用されるかもしれません。 送付者-MTPはポート/ソケットUから受信機-MTPプロセスまでのコントロール接続を開始します。 それは、MTPコマンドを開始して、回答を受け取って、メールの転送を治めます。
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.
郵便為替サービスを得たがっている人間(または、人間を代表したプロセス)。 追加、コンピュータメールの受取人で。
3
3
September 1980 RFC 772 Mail Transfer Protocol
1980年9月のRFC772メール転送プロトコル
THE MTP MODEL
MTPモデル
With the above definitions in mind, the following model (shown in
Figure 1) may be diagrammed for an MTP service.
上の定義が念頭にある場合、以下のモデル(図1では、目立つ)はMTPサービスのために図解されるかもしれません。
------------ ------------
| | | | --------
| | MTP | |<-->| User |
| Receiver-|Commands/Replies| Sender- | --------
-------- | MTP |<-------------->| MTP | --------
| Mail |<-->| | Mail | |<-->| Mail |
|System| | | | | |System|
-------- ------------ ------------ --------
------------ ------------ | | | | -------- | | MTP| | <-->、| ユーザ| | 受信機|コマンド/回答| 送付者| -------- -------- | MTP| <、-、-、-、-、-、-、-、-、-、-、-、-、--、>| MTP| -------- | メール| <-->、|、| メール| | <-->、| メール| |システム| | | | | |システム| -------- ------------ ------------ --------
Receiver-MTP Sender-MTP
受信機-MTP送付者-MTP
Model for MTP Use
MTP使用には、モデル化してください。
Figure 1
図1
In the model described in Figure 1, the sender-MTP initiates the
TCP/NCP control connection which follows the TELNET Protocol. At
the initiation of the user, standard MTP commands are generated by
the sender-MTP and transmitted to the receiver-MTP via the control
connection. Standard replies are sent from the receiver-MTP to
the sender-MTP over the control connection in response to the
commands. In addition, mail is sent over the control connection.
図1、送付者-MTP開始で説明されたモデルでは、TCP/NCPはTELNETプロトコルに従う接続を監督します。 ユーザの手引きで、標準のMTPコマンドは送付者-MTPであって受信機-MTPにコントロール接続を通して伝えられることによって生成されます。 コントロール接続の上でコマンドに対応して受信機-MTPから送付者-MTPに標準の回答を送ります。 さらに、コントロール接続の上にメールを送ります。
MAIL TRANSFER FUNCTIONS
郵便為替機能
The control connection is used for the transfer of commands which describe the functions to be performed, the replies to commands, as well as the actual transfer of mail. Mail is transferred only via the control connection.
コントロール接続は実行されるために機能について説明するコマンドの転送に使用されます、コマンドに関する回答、メールの実際の転送と同様に。 単にコントロール接続でメールを移します。
The communication channel from the sender-MTP to the receiver-MTP is established by a TCP/NCP control connection from the sender to a standard receiver port/socket. The sender-MTP is responsible for sending MTP commands, interpreting the replies received, and sending the mail; the receiver-MTP interprets commands, sends replies, and receives the mail.
送付者-MTPから受信機-MTPまでの通信チャネルは送付者から標準の受信機ポート/ソケットまでのTCP/NCPコントロール接続によって確立されます。 受け取られて、メールを送る回答を解釈して、送付者-MTPは送付MTPコマンドに責任があります。 受信機-MTPはコマンドを解釈して、回答を送って、メールを受け取ります。
4
4
RFC 772 September 1980
Mail Transfer Protocol
RFC772 1980年9月のメール転送プロトコル
MAIL REPRESENTATION AND STORAGE
メール表現とストレージ
Mail is transferred from a storage device in the sending host to a
storage device in the receiving host. It may be necessary to
perform certain transformations on the mail because data storage
representations in the two systems are different. For example,
NVT-ASCII has different data storage representations in different
systems. PDP-10's generally store NVT-ASCII as five 7-bit ASCII
characters, left-justified in a 36-bit word. 360's store
NVT-ASCII as four 8-bit EBCDIC codes in a 32-bit word. Multics
stores NVT-ASCII as four 9-bit characters in a 36-bit word.
受信ホストで送付ホストの記憶装置から記憶装置までメールを移します。 2台のシステムにおけるデータ保存表現が異なっているので、メールに、ある変換を実行するのが必要であるかもしれません。 例えば、NVT-ASCIIには、異系統における異なったデータ保存表現があります。一般に、PDP-10のものは5人の7ビットのASCII文字としてNVT-ASCIIを保存します、左では、36ビットの単語で、正当です。 360は32ビットの単語による4つの8ビットのEBCDICコードとしてNVT-ASCIIを保存します。 Multicsは36ビットの単語による4つの9ビットのキャラクタとしてNVT-ASCIIを保存します。
For the sake of simplicity, all data must be represented in MTP as
NVT-ASCII. This means that characters must be converted into the
standard NVT-ASCII representation when transmitting text,
regardless of whether the sending and receiving hosts are
dissimilar. The sender converts the data from its internal
character representation to the standard 8-bit NVT-ASCII
representation (see the TELNET specification). The receiver
converts the data from the standard form to its own internal form.
In accordance with this standard, the <CRLF> sequence should be
used to denote the end of a line of text.
簡単にするために、NVT-ASCIIとしてMTPにすべてのデータを表さなければなりません。 これは、テキストを伝えるとき、標準のNVT-ASCII表現にキャラクタを変換しなければならないことを意味します、発信と受信ホストが異なっているかどうかにかかわらず。 送付者は内部の文字表示から標準の8ビットのNVT-ASCII表現までデータを変換します(TELNET仕様を見てください)。 受信機は標準形式から内部のそれ自身のフォームまでデータを変換します。 この規格によると、<CRLF>系列は、テキストの線の端を指示するのに使用されるべきです。
The mail in MTP has no internal structure and is considered to be
a continuous sequence of data octets.
MTPのメールは、どんな内部の構造も持たないで、データ八重奏の連続した系列であると考えられます。
ERROR RECOVERY AND RESTART
エラー回復AND再開
There is no provision for detecting bits lost or scrambled in data
transfer; this level of error control is handled by the TCP/NCP.
In addition, there is no restart procedure provided to protect
senders from gross system failures (including failures of a host,
an MTP-process, or the underlying network).
データ転送で、なくされているか、またはスクランブルをかけられるビットを検出することへの支給が全くありません。 このレベルの誤り制御はTCP/NCPによって扱われます。 さらに、総計のシステム障害から送付者を保護するために提供された再開手順が全くありません(ホスト、MTP-プロセス、または基本的なネットワークの失敗を含んでいて)。
MTP COMMANDS
MTPコマンド
COMMAND SEMANTICS
コマンド意味論
The MTP commands define the mail transfer or the mail system
function requested by the user. The syntax of mailboxes must
conform to receiver site conventions (with standard defaults
applicable). In response to an MTP transfer command, the mail
shall always be transferred over the control connection.
MTPコマンドはユーザによって要求された郵便為替かメールシステム機能を定義します。 メールボックスの構文は受信機サイトコンベンション(標準省略時解釈が適切の)に従わなければなりません。 MTP転送命令に対応して、いつもコントロール接続の上にメールを移すものとします。
The Mail Transfer Protocol follows the specifications of the
TELNET Protocol for all communications over the control
メールTransferプロトコルはコントロールの上のすべてのコミュニケーションのためのTELNETプロトコルの仕様に従います。
5
5
September 1980 RFC 772 Mail Transfer Protocol
1980年9月のRFC772メール転送プロトコル
connection. Although the language used for TELNET communication
can be a negotiated option, the "TELNET language" and the
corresponding "TELNET end of line code" are required to be
NVT-ASCII and <CRLF> respectively. No other specifications of the
TELNET Protocol will be cited.
接続。 TELNETコミュニケーションに使用される言語は交渉されたオプションであるかもしれませんが、「TELNET言語」と対応する「TELNET行末コード」が、それぞれNVT-ASCIIと<CRLF>になるのに必要です。 TELNETプロトコルの他の仕様は全く引用されないでしょう。
MTP commands are NVT-ASCII strings terminated by <CRLF>. The
command codes themselves are alphabetic characters terminated by
the character <SP> (space) if parameters follow and <CRLF>
otherwise.
MTPコマンドは<CRLF>によって終えられたNVT-ASCIIストリングです。 そうでなければ、コマンドコード自体は、パラメタが従うならキャラクタ<SP>(スペース)によって終えられた英字と<CRLF>です。
The MTP commands are discussed below. In the description of a few
of the commands in this section the possible replies are given
explicitly. MTP replies are discussed in the next section.
以下でMTPコマンドについて議論します。 このセクションのコマンドのいくつかの記述では、明らかに可能な回答を与えます。 次のセクションでMTP回答について議論します。
MAIL (MAIL)
メール(メール)
This command allows a sender-MTP to send mail over the
control connection. The argument field contains a sender
and optional path sequence. If the 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 forwarded to the first host on the list. Following
this command line the receiver treats all subsequent
characters as mail text from the sender. The mail text is
terminated by the character sequence "CRLF.CRLF".
このコマンドで、送付者-MTPはコントロール接続の上にメールを送ることができます。 議論分野は送付者と任意の経路系列を含んでいます。 経路系列が存在しているなら、それはホストの任意のリストとあて先メールボックスから成ります。 ホストのリストが存在しているとき、それは、ソースルーティング情報であり、第1代リストの上のホストにメールを転送しなければならないのを示します。 このコマンドラインに続いて、受信機は送付者からのメールテキストとしてすべてのその後のキャラクタを扱います。 メールテキストはキャラクタシーケンス"CRLF.CRLF"によって終えられます。
As mail is forwarded along the path sequence, each
forwarding host must remove itself from the list. When mail
reaches its ultimate destination (the path sequence has only
a (possibly empty) destination mailbox), the receiver
inserts it into the destination mailbox in accordance with
its host mail conventions. If the second argument field is
blank (one or more spaces) or empty (<CRLF>), the mail is
destined for a printer or other designated place for site
general delivery mail. The mail may be marked as sent from
the sender as specified by the first argument field.
経路系列に沿ってメールを転送するとき、それぞれの推進ホストはリストから立ち退かなければなりません。 メールが最終仕向地に達すると(経路系列には、(ことによると空)のあて先メールボックスしかありません)、ホストメールコンベンションによると、受信機はあて先メールボックスの中にそれを挿入します。 2番目の議論分野が空白であるか(1つ以上の空間)、または人影がないなら(<CRLF>)、メールはサイト局留め郵便メールのためのプリンタか他の集合場所に運命づけられています。 メールは最初の議論分野のそばの指定されるとしての送付者から送るようにマークされるかもしれません。
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 to list the recipients first, or to send the
mail first.
このMTPコマンドは、同じホストの数人のユーザにメールの伝達の体系を選択するのに使用されます。 体系は、最初に、受取人を記載するか、または最初にメールを送ることです。
6
6
RFC 772 September 1980
Mail Transfer Protocol
RFC772 1980年9月のメール転送プロトコル
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 control
connection to the receiver. The command may take an
argument (e.g., any command name) and return more specific
information as a response. The reply is type 211 or 214.
受信機はこのコマンドで受信機とのコントロール接続の上に実装状態に関する役立つ情報を送ります。コマンドは、主張(例えばどんなコマンド名も)を取って、応答として、より特定の情報を返すかもしれません。 回答はタイプ211か214です。
QUIT (QUIT)
やめてください。(やめます)
This command specifies that the receiver must close the
control connection.
このコマンドは、受信機がコントロール接続を終えなければならないと指定します。
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回答を送る以外に、それは動作を全く指定しません。
COMMAND SYNTAX
コマンド構文
The commands (and their functions and semantics) are TELNET
NVT-ASCII strings transmitted over the control connection. The
functions and semantics of commands are described in the section
on MTP Commands. The reply sequences are discussed in the section
on Sequencing of Commands and Replies. Scenarios illustrating the
use of commands are provided in the section on Typical MTP
Scenarios. The command syntax is specified in this section.
コマンド(そして、それらの機能と意味論)はコントロール接続の上に伝えられたTELNET NVT-ASCIIストリングです。 コマンドの機能と意味論はMTP Commandsの上のセクションで説明されます。 CommandsとRepliesのSequencingの上のセクションで回答系列について議論します。 コマンドの使用を例証するシナリオをTypical MTP Scenariosの上のセクションに提供します。 コマンド構文はこのセクションで指定されます。
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つ以上の空間によって分離されます。
7
7
September 1980 RFC 772 Mail Transfer Protocol
1980年9月のRFC772メール転送プロトコル
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 line code
is received.
議論分野はキャラクタシーケンス<CRLF>で可変長文字列結末から成ります。 行末コードが受け取られているまで受信機が行動を全く取ることになっていないことに注意されるべきです。
The syntax is specified below in NVT-ASCII. All characters in the
argument field are ASCII characters. Square brackets denote an
optional argument field. If the option is not taken, the
appropriate default is implied.
構文は以下でNVT-ASCIIで指定されます。 議論分野のすべてのキャラクタがASCII文字です。 角括弧は任意の議論分野を指示します。 オプションが取られないなら、適切なデフォルトは含意されます。
The following are the MTP commands:
↓これはMTPコマンドです:
MAIL <SP> FROM:<sender> [<SP> TO:<path>] <CRLF>
メール<SP>FROM:<送付者>[<SP>TO:<経路>]<CRLF>。
MRSQ [<SP> <scheme>] <CRLF>
MRSQ[<SP><体系>]<CRLF>。
MRCP <SP> TO:<path> <CRLF>
MRCP<SP>TO:<経路><CRLF>。
HELP [<SP> <string>] <CRLF>
助け[<SP><ストリング>]<CRLF>。
QUIT <CRLF>
<CRLF>をやめてください。
NOOP <CRLF>
NOOP<CRLF>。
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> ::= "<" <mailbox> ">"
<送付者>:、:= "<"<メールボックス>">"
<path> ::= "<" ["@" <host> "," ...] <mailbox> ">"
<経路>:、:= 「"<"[」 「@」 <ホスト>」、…] <メールボックス>">"
<scheme> ::= "R" | "T" | "?"
<体系>:、:= 「R」| 「T」| "?"
<string> ::= <char> | <char><string>
<ストリング>:、:= <炭の>。| <炭の><ストリング>。
<mailbox> ::= <user> "@" <host>
<メールボックス>:、:= <ユーザ>"@"<ホスト>。
<host> ::= <string>
<ホスト>:、:= <ストリング>。
<user> ::= <string>
<ユーザ>:、:= <ストリング>。
<char> ::= any of the 128 ASCII characters except <CR> and <LF>
<炭の>:、:= <CR>と<LF>以外の128人のASCII文字のいずれも
8
8
RFC 772 September 1980
Mail Transfer Protocol
RFC772 1980年9月のメール転送プロトコル
CONTROL FUNCTIONS
コントロール機能
Most time-sharing systems provide mechanisms to allow a terminal
user to regain control of a "runaway" process. When used locally,
such systems have access to all user-supplied signals, whether
these are normal characters or special "out of band" signals.
When terminals are connected to the system through the network,
the system does not necessarily have access to all user signals;
the network's flow control mechanisms may cause such signals to be
buffered elsewhere, for example in the user's host.
ほとんどの時分割システムが、端末ユーザが「暴走」プロセスのコントロールを取り戻すのを許容するためにメカニズムを提供します。 局所的に使用されると、そのようなシステムはすべてのユーザによって供給された信号に近づく手段を持っています、これらが普通のキャラクタか「バンド」特別な信号であることにかかわらず。 端末がネットワークを通してシステムにつなげられるとき、システムは必ずすべてのユーザ信号に近づく手段を持っているというわけではありません。 ネットワークのフロー制御メカニズムで、ほかの場所と、例えば、ユーザのホストでそのような信号をバッファリングするかもしれません。
To counter this problem, the TELNET "Synch" mechanism is used. A
Synch signal consists of a TCP Urgent or an NCP Interrupt
notification, coupled with the TELNET command DATA MARK (DM).
This notification, which is not subject to the flow control
pertaining to the TELNET connection, is used to invoke special
handling of the data stream by the process which receives it. In
this mode the data stream is immediately scanned for a TELNET
Interrupt Process (IP) command. (The rationale for the use of the
TELNET IP command is to allow an existing server TELNET module to
sit "under" the MTP. If this code were directly implemented in
the MTP the IP command would be unnecessary.) The TELNET command
DM is the synchronizing mark in the data stream which indicates
that any special signal has already occurred and the recipient can
return to normal processing of the data stream. For a more
complete understanding of this mechanism, see the TELNET Protocol
Specification in the Internet Protocol Handbook.
この問題を打ち返すために、TELNET「同時性」メカニズムは使用されています。 Synch信号はTELNETコマンドDATA MARK(DM)に結びつけられたTCP UrgentかNCP Interrupt通知から成ります。 この通知(TELNET接続に関係するフロー制御を受けることがない)は、それを受けるプロセスでデータ・ストリームの特別な取り扱いを呼び出すのに使用されます。 このモードで、データ・ストリームはすぐに、TELNET Interrupt Process(IP)コマンドのためにスキャンされます。 (TELNET IPの使用のための原理は、“under"が既存のサーバTELNETモジュールを座らせることになっていると命令します。MTP。 このコードがMTPで直接実装されるなら、IPコマンドは不要でしょうに。) TELNETコマンドDMはどんな特別な信号も既に発生して、受取人がデータ・ストリームの正常処理に戻ることができるのを示すデータ・ストリームにおいて連動マークです。 このメカニズムをさらに完全に理解するために、インターネットプロトコルHandbookのTELNETプロトコルSpecificationを見てください。
The effect of this mechanism is to to discard all characters (up
to the DM) between the sender of the Synch and its recipeint.
Thus, all characters in the control connection are ignored until
the TELNET command DM is received. The full sequence is
illustrated below. Each vertical bar (|) represents the boundary
between data octets; IAC refers to the TELNET command code
Interpret As Command.
Synchの送付者とそのrecipeintの間ですべてのキャラクタを捨てる(DMまで)ために、このメカニズムの効果があります。 したがって、TELNETコマンドDMが受け取られているまで、コントロール接続におけるすべてのキャラクタが無視されます。 完全な系列は以下で例証されます。 各縦棒、(|、)、データ八重奏の間の境界を表します。 IACはTELNETコマンドコードInterpret As Commandについて言及します。
Old New
-+-+-+-+-+-----+---+--+---+--+-
...|M|A|I|L| ... |IAC|IP|IAC|DM|...
-+-+-+-+-+-----+---+--+---+--+-
古い新しい+++++-----+---+--+---+--+- ...|M|A|I|L| ... |IAC|IP|IAC|DM|... -+-+-+-+-+-----+---+--+---+--+-
9
9
September 1980 RFC 772 Mail Transfer Protocol
1980年9月のRFC772メール転送プロトコル
MTP REPLIES
MTP回答
Replies to Mail Transfer Protocol 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. Every command must generate at least one reply, although there may be more than one. In the latter case, the multiple replies must be easily distinguished. Additionally, some commands must occur sequentially, such as MRSQ T->MAIL->MRCP or MRSQ R->MRCP->MAIL. Replies to these sequences show the existence of an intermediate state if all preceding commands have been successful. A failure at any point in the sequence necessitates the repetition of the entire sequence from the beginning.
メールTransferプロトコルコマンドに関する回答は、郵便為替の途中に要求と動作の同期を確実にして、送付者-MTPがいつも受信機の状態を知っているのを保証するために工夫されます。あらゆるコマンドが少なくとも1つの回答を生成しなければなりません、1つ以上があるかもしれませんが。 後者の場合では、容易に複数の回答を区別しなければなりません。 さらに、いくつかのコマンドが連続して起こらなければならなくて、MRSQ T->としてのそのようなものがメール>MRCPかMRSQ R>である、MRCP、-、>メール。 これらの系列に関する回答は、すべての前のコマンドがうまくいっているかどうかを中間的状態の存在に示します。 系列の任意な点での失敗は始めからの全体の系列の反復を必要とします。
The details of the command-reply sequence are made explicit in the
section on State Diagrams.
州Diagramsの上のセクションでコマンド回答系列の詳細を明白にします。
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.
MTP回答は何らかのテキストがあとに続いた3桁数(3つの英数字として、伝えられる)から成ります。 数はオートマトンによる使用が、次にどんな状態に入ったらよいかを決定することを意図します。 テキストは人間のユーザのために意味されます。 3ケタが送付者-MTPがユーザにテキストを調べる必要はなくて、それを捨てるか、またはそれを渡すかもしれないという十分なコード化された情報を含むことを意図します、適宜。 テキストが受信機特に、依存しているかもしれないので、それぞれの回答コードにおいて、異なったテキストがありそうです。
Formally, a reply is defined to be the sequence: a three-digit code, space <SP>, one line of text (where the maximum line length is 65), and a terminal <CRLF>. Occasionally the text is longer than a single line; in these cases the complete text must be bracketed so the sender-MTP knows when it can stop reading the reply. This requires a special first line format to indicate a multiple line reply, and another on the last line to so designate it. Both lines will contain the appropriate reply code which indicates the transaction state.
正式に、回答は系列になるように定義されます: 3ケタのコード、スペース<SP>、1個のテキスト行(最大の行長が65であるところ)、および端末の<CRLF>。 時折、テキストは単線より長いです。 これらの場合では、全文に腕木を付けなければならないので、送付者-MTPは、それが、いつ回答を読むのを止めることができるかを知っています。 これは、特別な最初の系列形式が複数の系列回答を示すのが必要であり、したがって、最終ラインの別のものがそれを指定するのを必要とします。 両方の系列はトランザクション状態を示す適切な回答コードを含むでしょう。
Thus the format for multi-line replies is that the first line will
begin with the exact required reply code, followed immediately by
a Hyphen, "-" (also known as minus), followed by text. The last
line will begin with the same code, followed immediately by space
<SP>, optionally some text, and <CRLF>.
したがって、マルチ系列回答のための形式はテキストがすぐにHyphen、「-」(また、マイナスとして、知られている)であとに続く正確な必要な回答コードのあとに続いていて最初の系列が始まるということです。 最終ラインはすぐスペース<SP>によって従われた同じコードで任意に始まるでしょう。何らかのテキスト、および<CRLF>。
10
10
RFC 772 September 1980
Mail Transfer Protocol
RFC772 1980年9月のメール転送プロトコル
For example:
123-First line
Second line
234 A line beginning with numbers
123 The last line
例えば: No.123で最終ラインを始める最初に123系列Second系列234A系列
The sender-MTP then simply needs to search for the second
occurrence of the same reply code followed by <SP> (space> at the
beginning of a line, and ignore all intermediary lines. If an
intermediary line begins with a three-digit number, the receiver
must pad the front to avoid confusion.
次に、送付者-MTPは、単に<SP>によって従われた同じ回答コードの2番目の発生を捜し求める必要があります。系列の始めに>を区切ってください、そして、すべての仲介者系列を無視してください。(仲介者系列が3桁数で始まるなら、受信機は、混乱を避けるために前部を水増ししなければなりません。
This scheme allows standard system routines to be used for
reply information, with "artificial" first and last lines
tacked on. In the rare cases where these routines are able to
generate three digits and a space at the beginning of any line,
the beginning of each text line should be offset by some
neutral text, like space.
この体系は、標準のシステムルーチンが回答情報に付加される「人工」の1番目と最終ラインで使用されるのを許容します。 これらのルーチンがどんな系列の始めにも3ケタとスペースを生成することができるまれなケースの中では、それぞれのテキスト系列の始まりは何らかの中立テキストによって相殺されるべきです、スペースのように。
This scheme assumes that multi-line replies may not be nested. In
general, reply nesting will not occur except for random system
messages (also called spontaneous replies) which may interrupt
another reply. System messages (i.e., those not processed by the
receiver-MTP) will NOT carry reply codes and may occur anywhere in
the command-reply sequence. They may be ignored by the sender-MTP
as they are only information for the human user.
この体系は、マルチ系列回答が入れ子にされないかもしれないと仮定します。 一般に、別の回答を中断するかもしれない無作為のシステムメッセージ(また、自然発生的な回答と呼ばれる)以外に、回答巣篭もりは起こらないでしょう。 システムメッセージ(すなわち、受信機-MTPによって処理されなかったもの)は、回答コードを運ばないで、コマンド回答系列でどこでも現れるかもしれません。 それらは、情報にすぎないので人間のユーザのために送付者-MTPによって無視されるかもしれません。
The three digits of the reply each have a special significance. This is intended to allow a range of very simple to very sophisticated response by the sender-MTP. The first digit denotes whether the response is good, bad or incomplete. (Referring to the state diagram) 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ケタは特別な意義があります。 これが送付者-MTPによる非常に洗練された応答に非常に簡単の範囲を許容することを意図します。 応答が良いか、悪いかまたは不完全であることにかかわらずケタが指示する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 requested action is being initiated; expect another
reply before proceeding with a new command. (The sender-MTP
sending another command before the completion reply would be
要求された動作は開始されています。 新しいコマンドを続ける前に、別の回答を予想してください。 (完成回答がそうであるのになる前の別のものを送る送付者-MTPコマンド
11
11
September 1980 RFC 772 Mail Transfer Protocol
1980年9月のRFC772メール転送プロトコル
in violation of protocol. However, receiver-MTP processes
should queue any commands that arrive while a preceding
command is in progress.)
プロトコルを違反して。 しかしながら、受信機-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 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).
コマンドは受け入れられませんでした、そして、要求された動作は起こりませんでした。 しかしながら、エラー条件は一時的です、そして、動作は再び要求されているかもしれません。 送付者はコマンド・シーケンス(もしあれば)の始まりまで戻るべきです。 2つの異なったサイト(受信機と送付者MTPs)が解釈に同意しなければならないとき、「一時的に」意味を割り当てるのは難しいです。 このカテゴリにおける各回答には、異なった時間的価値があるかもしれませんが、送付者-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
his/her directory status.)
コマンドは受け入れられませんでした、そして、要求された動作は起こりませんでした。 送付者-MTPは、正確な要求(同じ系列の)を繰り返して、がっかりしています。 人間のユーザは、いくつかの「永久的な」エラー条件さえ修正できるので、いくつかの直接行動によるコマンド・シーケンスが将来指す再開始に送付者-MTPを向けたがっているかもしれません。(例えば、スペルを変えたか、またはユーザがその人のディレクトリ状態を変更した後に。)
12
12
RFC 772 September 1980
Mail Transfer Protocol
RFC772 1980年9月のメール転送プロトコル
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 control
connection.
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 below
will illustrate 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. Receiver
implementations should not invent new codes for slightly different
situations from the ones described here, but rather adapt codes
already defined.
3番目のケタは2番目のケタによって指定された各カテゴリにおける意味の、よりすばらしい段階を与えます。 以下での回答のリストはこれを例証するでしょう。 それぞれの回答テキストは、義務的であるというよりむしろお勧めであり、それが関連しているコマンドに応じて、変化さえするかもしれません。 他方では、回答コードは厳密にこのセクションの仕様に従わなければなりません。 受信機実現はここで説明されたものからわずかに異なった状況のための新法を発明するべきではありませんが、むしろ既に定義されたコードを適合させてください。
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回答です。
REPLY CODES BY FUNCTION GROUPS
関数群による回答コード
200 Command okay
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
200はオーケーの500Syntax誤りを命令します、パラメタか502Commandがコマンドの503Bad系列を実行しなかったという主張におけるコマンド認識されていない[これはあまりに長い間、コマンドラインなどの誤りを含むかもしれない]501Syntax誤り
13
13
September 1980 RFC 772 Mail Transfer Protocol
1980年9月のRFC772メール転送プロトコル
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 control connection
421 <host> Service not available, closing control connection
[This may be a reply to any command if the service knows it
must shut down]
120 コントロール接続421<を閉じる新しいユーザ221<ホスト>Serviceの準備ができるnnn分220<ホスト>Serviceで準備ができる<ホスト>Serviceは>の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 space
552 Requested mail action aborted: exceeded storage allocation
[For current mailbox location]
553 Requested action not taken: mailbox name not allowed
354 Start mail input; end with <CR><LF>.<CR><LF>
ローカルではなく、151ユーザ。 <ユーザ>@<ホスト>152User未知に送るでしょう。 オペレータ250Requestedメール動作承認、取られなかった完成した450Requestedメール行動でメールを転送するでしょう: 入手できないメールボックス、[例えば、メールボックスが忙しくする、]、550 取られなかったRequested行動: メールボックス[例えば、見つけられなかったメールボックス、アクセスがありません]入手できない451Requested動作は中止になりました: 取られなかった処理452Requested行動における地方の誤り: 不十分なシステム集積スペース552Requestedメール動作は中止になりました: 取られなかった超えられている記憶領域の割当て[現在のメールボックス位置への]553Requested行動: メールボックス名は354Startメール入力を許しませんでした。 <CR><LF><CR><LF>で、終わってください。
NUMERIC ORDER LIST OF REPLY CODES
回答コードの数値オーダーリスト
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
200 Command okay
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 control connection
250 Requested mail action okay, completed
354 Start mail input; end with <CR><LF>.<CR><LF>
120 nnnで準備ができる<ホスト>Serviceは地方でなく151Userを書き留めます。 <ユーザ>@<ホスト>152User未知に送るでしょう。 オペレータ200のCommandのオーケーの211System状態でメールを転送するだろうか、システム助け回答214ヘルプメッセージ[特定の標準的でないコマンド; この回答の受信機か意味を使用するのがどう人間のユーザだけの役に立つかに関する情報]215<計画>はコントロール接続250Requestedメール動作承認を終える新しいユーザ221<ホスト>Serviceの準備ができる都合のよい計画220<ホスト>Serviceです、完成した354Startメール入力。 <CR><LF><CR><LF>で、終わってください。
14
14
RFC 772 September 1980
Mail Transfer Protocol
RFC772 1980年9月のメール転送プロトコル
421 <host> Service not available, closing control connection
[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 space
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
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
421 <ホスト>のServiceの利用可能で、終わりでないコントロール接続[サービスが、それが停止しなければならないのを知っているなら、これはどんなコマンドに関する回答であるかもしれない]450Requestedは取られなかった行動を郵送します: 入手できないメールボックス、[例えば、メールボックスが忙しくする、]、451 Requested動作は中止になりました: 取られなかった処理452Requested行動における地方の誤り: 不十分なシステム集積スペース500Syntax誤り、パラメタか議論502Commandの認識されていない[これはあまりに長い間、コマンドラインなどの誤りを含むかもしれない]501Syntax誤りが503Bad系列を実行しなかったコマンドは取られなかった550Requested行動を命令します: メールボックス[例えば、見つけられなかったメールボックス、アクセスがありません]入手できない552Requestedメール動作は中止になりました: 取られなかった超えられている記憶領域の割当て[現在のメールボックス位置への]553Requested行動: 許容されなかったメールボックス名
DISCUSSION OF MAIL TRANSFER
郵便為替の議論
The basic command for transmitting mail is MAIL. This command causes the transmitted data to be entered into the recipient's mailbox.
メールを伝えるための基本コマンドはメールです。 このコマンドで、伝えられたデータを受信者のメールボックスの中に入力します。
MAIL <SP> "FROM:" <sender> [<SP> "TO:" <path>] <CRLF>
<SP>「FROM:」というメール <送付者>[<SP>「TO:」<経路>]<CRLF>。
<sender> is a mailbox and <path> is a source routing list of
hosts and destination mailbox. If accepted, it returns a 354
reply and considers all succeeding lines to be the message
text. It is terminated by a line containing only a period,
upon which a 250 completion reply is returned. Various errors
are possible.
<送付者>はメールボックスです、そして、<経路>はホストとあて先メールボックスのソースルーティングリストです。 受け入れるなら、それは、354回答を返して、続くすべての線がメッセージ・テキストであると考えます。 それは250完成回答が返される期間だけを含む線によって終えられます。 様々な誤りは可能です。
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 receiver.
受信機がメールボックスがその受信機にないユーザへのメールを受け入れているのを示すのに使用するかもしれない2つの可能な予備の回答があります。
151 User not local; will forward to <user>@<host>
ローカルではなく、151ユーザ。 >@<ホスト>を<ユーザに送るでしょう。
This reply indicates that the receiver knows the user's mailbox
is on another host and will take responsibility for forwarding
the mail to that host. For example, at BBN (or ISI) there are
several hosts. Each has a list of many of the users on the
hosts. Each host can accept mail for any user on their list
and forward it to the correct host.
この回答は、受信機がユーザのメールボックスが別のホストの上でそうであることを知って、そのホストにメールを転送するのに責任を取るのを示します。 例えば、BBN(または、ISI)に、数人のホストがいます。 それぞれがホストの上にユーザの多くのリストを持っています。 各ホストは、それらのリストでどんなユーザへのメールも受け入れて、正しいホストにそれを送ることができます。
15
15
September 1980 RFC 772 Mail Transfer Protocol
1980年9月のRFC772メール転送プロトコル
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.
この回答はそれには、ホストがユーザ名を認めませんが、メールを受け入れて、それを届けるオペレータ試みがあるのを示します。 これは、ユーザ名がスペルミスされるなら役に立ちますが、メールが本当に「非-提出物」であるなら、害であるかもしれません。
If forwarding by the operator is unacceptable or if the user would prefer to send the mail directly to the recipient's actual host, the dialogue may be terminated upon receipt of one of these preliminary responses.
オペレータによる推進が容認できないか、またはユーザが、直接受取人の実際のホストにメールを送るのを好むなら、対話はこれらの予備の応答の1つを受け取り次第終えられるかもしれません。
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 site. In one, all recipients are specified first, and then the text is sent. In the other, the order is reversed and the text is sent first, followed by the recipients. Both schemes are necessary because neither by itself is optimal for all systems, as will be explained later. 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では、最初にすべての受取人を指定します、そして、次に、テキストを送ります。 もう片方では、オーダーを逆にします、そして、受取人によって後をつけられて、最初に、テキストを送ります。 両方の計画が必要である、どちらもそれ自体、すべてのシステムに最適であることで、意志として、後で説明されてください。 特定の計画を選択するために、MRSQコマンドは使用されています。 計画が選ばれた後に受取人を指定するために、MRCPコマンドを与えます。 そして、テキストを提供するために、メールコマンドは使用されています。
SCHEME SELECTION: MRSQ
選択を計画してください: 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は実行されるに違いありません。 ? 好みのために、要求します。 いつもこれを実行しなければなりません。
No argument means a "selection" of none of the schemes (the
default).
どんな議論も計画(デフォルト)のいずれの「選択」でないのを意味しません。
Possible replies are:
200 OK, we'll use specified scheme
215 <scheme> This is the scheme I prefer
501 I understand MRSQ but can't use that scheme
5xx Command unrecognized or unimplemented
可能な回答は以下の通りです。 200OK、私たちが指定された計画215<計画>Thisを使用するつもりである、私が好む計画が501である、私がMRSQを理解していますが、その計画5xx Commandを使用できない、認識されていないか非実行にされる
16
16
RFC 772 September 1980
Mail Transfer Protocol
RFC772 1980年9月のメール転送プロトコル
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> <arbitrary text>] <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 resetting all schemes to their initial state. This
reset must be done no matter what the reply will be -- 200, 215,
or 501. The actions necessary for a reset will be explained when
discussing how each scheme actually works.
MRSQに関する3番目の重要なポイントはそれにはそれらの初期状態にすべての計画をリセットする副作用がいつもあるということです。 回答が何になっても、このリセットをしなければなりません--200、215、または501。 各計画が実際にどううまくいくかについて議論するとき、リセットに必要な動作は説明されるでしょう。
MESSAGE TEXT SPECIFICATION: MAIL
メッセージ・テキスト仕様: メール
Regardless of which scheme (if any) has been selected, a MAIL
command with a non-null "TO" 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" the current scheme to its initial state.
どの計画(もしあれば)が選択されたかにかかわらず、非ヌル“TO"議論によるメールコマンドはまさに従来と同様振る舞うでしょう。 MRSQ/MRCPコマンドはそれで効き目がありません。 しかしながら、通常のメールコマンドには、MRSQと同じ副作用があります。 それは現在の計画を初期状態に「リセットします」。
It is only when the "TO" argument is null (e.g., MAIL FROM:<X@Y>
<CRLF>) that the particular scheme chosen is important. Rather
than producing an error (as most receivers currently do), the
receiver will accept message text for this "null" specification.
What it does with it depends on which scheme is in effect, and
will be described in the section on Scheme Mechanics.
“TO"議論がヌルである時にすぎない、(例えば、 FROM:<X@Y に郵送してください、gt;、<CRLF>) 選ばれた特定の計画は重要です。 誤り(ほとんどの受信機として、現在、する)を起こすよりむしろ、受信機はこの「ヌル」の仕様のためにメッセージ・テキストを受け入れるでしょう。 それがそれで何をするかはどの計画が有効であるかよって、Scheme Mechanicsの上のセクションで説明されるでしょう。
17
17
September 1980 RFC 772 Mail Transfer Protocol
1980年9月のRFC772メール転送プロトコル
RECIPIENT SPECIFICATION: MRCP
受取人仕様: 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:<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
553 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といっぱいに、この名義の格納されなかった553Recipientが後で再び拒絶された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<計画>を与えたに違いありません。
SCHEME MECHANICS: MRSQ R (RECIPIENTS-FIRST)
整備士を計画してください: 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も成功しないのを示すか完了していると命令します。
18
18
RFC 772 September 1980
Mail Transfer Protocol
RFC772 1980年9月のメール転送プロトコル
Sending message text to stored recipients is done by giving a MAIL
command with no "TO" argument; that is, just MAIL <SP> <sender>
<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 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.
“TO"議論なしでメールコマンドを与えることによって、格納された受取人にメッセージ・テキストを送ります。 すなわち、まさしくメール<SP><送付者><CRLF>。 メッセージ・テキストの送信はまさに正常なメールのように同じです。 しかしながら、トランスミッションの端の肯定応答は、MRCPと共に覚えていられたすべての受取人にメッセージを送ることを意味します、そして、失敗コードはこれらの指定された受取人のすべてのために失敗したのが考えられるべきであることを意味します。 これは実際のエラーコードにかかわらず適用されます。 回答が意味することにかかわらず、すべての格納された受取人名が、洗い流されて、忘れられています--言い換えれば、事態はそれらの初期状態にリセットされます。 またいずれの副作用が使用するリセットとして人名簿をしなければならないMRSQの受取人をこの除くこと。
A 452 reply 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 "TO"
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も与える前にメッセージ・テキスト(“TO"議論のないメール)を指定するのを試みるなら、これはちょうどヌル受取人がいる「正常な」メールであるだろうことのように扱われるべきです。 いくつかの受信機が「550Null受取人」などの誤りを返します。
See the example in Appendix A for a mail transfer using MRSQ R.
MRSQ Rを使用して、郵便為替のためにAppendix Aの例を見てください。
SCHEME MECHANICS: MRSQ T (TEXT-FIRST)
整備士を計画してください: MRSQ T(最初にテキスト)
In the text-first scheme, MAIL with no "TO" 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.)
最初にテキスト計画では、“TO"議論のないメールは、メッセージ・テキストを指定するのに使用されます。(受信機はメッセージ・テキストを蓄えます)。 次に、続く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 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が見られるなら、事実上、送付者はヌルメッセージを送ろうとしています。 いくつかの受信機がこれを許容するかもしれなくて、他のものはエラーコードを返すでしょう。
19
19
September 1980 RFC 772 Mail Transfer Protocol
1980年9月のRFC772メール転送プロトコル
See the example in Appendix B for a mail transfer using MRSQ T.
MRSQ Tを使用して、郵便為替のためにAppendix Bの例を見てください。
WHY TWO SCHEMES ANYWAY?
2がとにかく計画される理由?
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 of great power. 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の大量の郵送を見習おうとするなら、彼らは、本当に、メールに関する成功回答が、指定されたすべての受取人にそれを届けました--どんなほんのいくつかも意味しなかったのを保証しなければならないでしょうに。
NOTES:
注意:
* 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を実行するのが無意味であるだろうということです、そして、したがって、応答は否定的でしょう。
20
20
RFC 772 September 1980
Mail Transfer Protocol
RFC772 1980年9月のメール転送プロトコル
* One reason that the use of MAIL is restricted to null "TO"
arguments with this multi-recipient extension is the ambiguity
that would result if a non-null "TO" 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><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.
* メールの使用がこのマルチ受取人拡大とのヌル“TO"議論に制限される1つの理由が非ヌル“TO"議論が許容されているなら結果として生じるあいまいさです。 例えば、MRSQ Rが有効であり、いくつかのMRCPsを与えたか、そして、メール FROM:<X@Y 、gt;、TO:<FOO><CRLF>をして、すべての受取人のためのグローバルな失敗からの"FOO"が指定したメールボックスのための失敗回答を区別する方法が全くないでしょう。 同様の状況はMRSQ Tのために存在しています。 それはテキストが格納されて、メールボックスが失敗したか、逆もまた同様ですか両方をクリアすることでないでしょう。
* "Resets" 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 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" just as an FTP "TYPE A" remains
selected. 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.
* 「リセット」が、混乱とひどく複雑な実現を避けるためにすべてのMRSQsと「正常な」MAILsによって行われます。 MRSQコマンドは状態の変化か不確実性を含意します。そうでなければ、メールコマンドは、T/R計画によって使用されるデータベース(例えば、メッセージ・テキスト格納領域)を打ち負かすのを避けるのにいくつかの独立しているメカニズムを使用しなければならないでしょう。 しかしながら、計画がいったん選択されると、ちょうどFTP「タイプA」が選択されたままで残っているのに従って、それは「有効な」ままで残っています。 現在の選択を変えないでリセットするためのお勧めの方法が"MRSQ?"と共にあります。 その"MRSQ"だけ、が計画がない状態に振り向けるのを覚えていてください。
* It is permissible to intersperse other MTP commands among the
MRSQ/MRCP/MAIL sequences.
* MRSQ/MRCP/メール系列の中に他のMTPコマンドを点在させるのは許されています。
21
21
September 1980 RFC 772 Mail Transfer Protocol
1980年9月のRFC772メール転送プロトコル
DECLARATIVE SPECIFICATIONS
叙述的な仕様
MINIMUM IMPLEMENTATION
最小の実現
In order to make MTP workable without needless error messages, the
following minimum implementation is required for all receivers:
MTPを不必要なエラーメッセージなしで実行可能にして、以下の最小の実現がすべての受信機に必要です:
COMMANDS -- QUIT
MAIL
NOOP
コマンド--メールNOOPをやめてください。
In terms of FTP, the values of the transfer parameters must be:
FTPに関して、転送パラメタの値は以下の通りでなければなりません。
TYPE -- ASCII
MODE -- STREAM
STRU -- FILE-STRUCTURE
タイプ--ASCIIモード--流れのSTRU--ファイル構造
All hosts must use the above values for mail transfer.
すべてのホストが郵便為替に上の値を使用しなければなりません。
CONNECTIONS
接続
The receiver-MTP shall "listen" on Port L. The sender-MTP shall
initiate the TCP/NCP control connection. The control connection
consists of a full-duplex connection under TCP; it is two simplex
connections under NCP. Receiver- and sender- MTPs should follow
the conventions of the TELNET Protocol as specified in the ARPA
Internet Protocol Handbook. Receivers are under no obligation to
provide for editing of command lines and may specify that it be
done in the sender host. The control connection shall be closed
by the receiver at the sender's request after all transfers and
replies are completed.
受信機-MTPはPort L.で「聴くものとします」。送付者-MTPはTCP/NCPコントロール接続を開始するものとします。 コントロール接続はTCPの下で全二重接続から成ります。 それはNCPの下で2つのシンプレクス接続です。 受信機と送付者MTPsはARPAインターネットプロトコルHandbookの指定されるとしてのTELNETプロトコルのコンベンションに続くはずです。 受信機は、コマンドラインの編集に備えるどんな義務の下にもなくて、送付者ホストでそれをすると指定するかもしれません。 送付者の要求によって、すべての転送と回答が終了した後に、コントロール接続は受信機によって閉店させられるものとします。
SEQUENCING OF COMMANDS AND REPLIES
コマンドと回答の配列
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 initial primary success or failure
response before sending further commands.
送付者と受信機とのコミュニケーションは交互の対話であることを意図します。 そういうものとして、送付者はMTPコマンドを発行します、そして、受信機は迅速な第一の回答で応じます。 さらなるコマンドを送る前に、送付者はこの初期の第一の成否応答を待つべきです。
Certain commands require a second reply for which the sender
should also wait. These replies may, for example, report on the
progress or completion of mail transfer. They are secondary
replies to mail transfer commands.
あるコマンドはまた送付者が待つべきである2番目の回答を必要とします。 例えば、これらの回答は郵便為替の進歩か完成に関して報告するかもしれません。 それらは郵便為替命令に関する二次回答です。
One important group of informational replies is the connection
情報の回答の1つの重要なグループは接続です。
22
22
RFC 772 September 1980
Mail Transfer Protocol
RFC772 1980年9月のメール転送プロトコル
greetings. Under normal circumstances, a receiver will send a 220
reply, "awaiting input", 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 and a 220
reply when ready. The sender will then know not to hang up if
there is a delay.
挨拶。 通常の状況下で、接続が終了しているとき、「入力を待っ」て、受信機は220回答を送るでしょう。 どんなコマンドも送る前に、送付者はこのあいさつメッセージを待つべきです。 受信機がすぐ入力を受け入れることができないなら、すぐに120「予想どおりの遅延」回答を送るべきです、そして、準備ができているとき、220は返答します。 そして、送付者は、遅れがあればハングアップしないのを知るでしょう。
Note: all the greeting type replies have the official name of
the server host as the first word following the reply code.
以下に注意してください。 すべての挨拶タイプ回答には、回答コードに従って、最初の単語としてサーバー・ホストの正式名称があります。
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
コマンド回答系列
In this section, the command-reply sequence is presented. Each
command is listed with its possible replies; command groups are
listed together. Preliminary replies are listed first (with
their succeeding replies indented under them), then positive
and negative completion, and finally intermediary replies with
the remaining commands from the sequence following. The 421
reply (service not available, closing control connection) may
be given at any point if the MTP-receiver knows it must shut
down. This listing forms the basis for the state diagrams,
which will be presented separately.
このセクションでは、コマンド回答系列は提示されます。 各コマンドは可能な回答で記載されています。 指揮機関は一緒に記載されています。 そして、予備の回答は、記載された1番目(彼らの続く回答がそれらの下で字下がりにされている)と、積極的で否定的な完成と、最終的に系列からの残っているコマンドが続いている仲介者回答です。 MTP-受信機が、それが停止しなければならないのを知っているなら、任意な点で421回答(どんな利用可能で、終わりのコントロール接続にもサービスを提供しない)を与えるかもしれません。 このリストは州のダイヤグラムの基礎を形成します。(ダイヤグラムは別々に提示されるでしょう)。
CONNECTION ESTABLISHMENT
120
220
220
421
MAIL ACTION COMMANDS
MAIL
151, 152
354
250
451, 552
354
250
451, 552
450, 550, 452, 553
500, 501, 502, 421
コネクション確立120 220 220 421メール動作はメール151、152 354 250 451、552 354 250 451、552 450、550、452、553 500、501、502、421を命令します。
23
23
September 1980 RFC 772 Mail Transfer Protocol
1980年9月のRFC772メール転送プロトコル
MRSQ
200, 215
500, 501, 502, 421
MRCP
151, 152
200
200
450, 550, 452, 553
500, 501, 502, 503, 421
QUIT
221
INFORMATIONAL COMMANDS
HELP
211, 214
500, 501, 502, 421
MISCELLANEOUS COMMANDS
NOOP
200
500 421
MRSQ200、215 500、501、502、421MRCP151、152 200 200 450、550、452、553 500、501、502、503、421が助け211、214 500、501、502、421その他が命令する221の情報のコマンドをやめる、NOOP200 500 421
STATE DIAGRAMS
州のダイヤグラム
Here we present 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を使用します。
24
24
RFC 772 September 1980
Mail Transfer Protocol
RFC772 1980年9月のメール転送プロトコル
We first present the diagram that represents the most 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.
ヘルプ、MRCP(MRSQ、NOOP)はやめます。
25
25
September 1980 RFC 772 Mail Transfer Protocol
1980年9月のRFC772メール転送プロトコル
A more complex diagram models the MAIL command:
より複雑なダイヤグラムはメールコマンドをモデル化します:
---- 1
| |
+---+ cmd -->+---+ 2 +---+
| B |---------->| W |---------->| E |
+---+ +---+ -->+---+
| | |
3 | | 4,5 |
-------------- ------ |
| | | +---+
| ------------->| S |
| | 1,3 | | +---+
| 2| --------
| | | |
V | | |
+---+ text +---+ 4,5 ----->+---+
| |---------->| W |---------->| F |
+---+ +---+ +---+
---- 1 | | +---+cmd-->+---+ 2 +---+ | B|、-、-、-、-、-、-、-、-、--、>| W|、-、-、-、-、-、-、-、-、--、>| E| +---+ +---+-->+---+ | | | 3 | | 4,5 | -------------- ------ | | | | +---+ | ------------->| S| | | 1,3 | | +---+ | 2| -------- | | | | V| | | +---+ テキスト+---+ 4,5 ----->+---+ | |、-、-、-、-、-、-、-、-、--、>| W|、-、-、-、-、-、-、-、-、--、>| F| +---+ +---+ +---+
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. (The last line must consist of only a single
period.)
ここの「テキスト」が最終ラインを送るまで予想された応答なしで送付者から受信機に送られた一連の線であることに注意してください。 (最終ラインはただ一つの期間だけから成らなければなりません。)
26
26
RFC 772 September 1980
Mail Transfer Protocol
RFC772 1980年9月のメール転送プロトコル
Finally we present a generalized diagram that could be used to model the command and reply interchange:
最終的に私たちはコマンドと回答置き換えをモデル化するのに使用できた一般化されたダイヤグラムを提示します:
------------------------------------
| |
Begin | |
| V |
| +---+ cmd +---+ 2 +---+ |
-->| |------->| |---------->| | |
| | | W | | S |-----|
-->| | -->| |----- | | |
| +---+ | +---+ 4,5 | +---+ |
| | | | | | |
| | | 1| |3 | +---+ |
| | | | | | | | |
| | ---- | ---->| F |-----
| | | | |
| | | +---+
-------------------
|
|
V
End
------------------------------------ | | 始まってください。| | | V| | +---+ cmd+---+ 2 +---+ | -->| |、-、-、-、-、-、--、>| |、-、-、-、-、-、-、-、-、--、>|、|、|、|、|、| W| | S|-----| -->|、| -->| |----- | | | | +---+ | +---+ 4,5 | +---+ | | | | | | | | | | | 1| |3 | +---+ | | | | | | | | | | | | ---- | ---->| F|----- | | | | | | | | +---+ ------------------- | | V終わり
27
27
September 1980 RFC 772 Mail Transfer Protocol
1980年9月のRFC772メール転送プロトコル
CONNECTION ESTABLISHMENT
コネクション確立
The MTP control connection is established via TCP/NCP between the receiver process port/socket L and the sender process port/socket U. This protocol is assigned the service port/socket 57 (71 octal), that is L=57.
MTPコントロール接続は受信機過程ポート/ソケットLと送付者過程ポート/ソケットU.の間のTCP/NCPで確立されます。サービスポート/ソケット57(71 8進)、すなわち、L=57はThisプロトコルに割り当てられます。
28
28
RFC 772 September 1980
Mail Transfer Protocol
RFC772 1980年9月のメール転送プロトコル
APPENDIX A
付録A
Example of MRSQ R (Recipients-first)
MRSQ Rに関する例(最初に受取人)
This is an example of how MRSQ R is used. First the sender must establish that the receiver in fact implements MRSQ.
これはMRSQ Rがどう使用されているかに関する例です。 まず最初に、送付者は、事実上、受信機が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
S: MRCP TO:<Raboof@Y> <CRLF>
R: 553 No such user here
S: MRCP TO:<Raboof@Y 、gt;、lt;、CRLF>R: ここのそのような553人のユーザでない
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 forwarded to "fubar@Z" through host "X". Now the message text is furnished, by giving a MAIL command with no "TO" argument.
"Raboof"の失敗はメールの格納のときにホスト「X」を通して"Foo"、「バー」またはメールを" fubar@Z "に転送するために効き目がないことに注意してください。 現在、“TO"議論なしでメールコマンドを与えることによって、メッセージ・テキストを提供します。
S: MAIL FROM:<waldo@A><CRLF>
R: 354 Type mail, ended by <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 forwarded to "fubar@Z".
現在、メールテキストを"Foo"と「バー」に送って、" fubar@Z "に転送しました。
29
29
September 1980 RFC 772 Mail Transfer Protocol
1980年9月のRFC772メール転送プロトコル
APPENDIX B
付録B
Example of MRSQ T (Text-first)
MRSQ Tに関する例(最初にテキスト)
Using the same message as the previous example to 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: 501 Sorry, I really can't do that
S: MRSQ R<CRLF>R: 501 すみません、私は本当にそれができません。
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 "TO" argument.
現在計画「T」を選択します、そして、“TO"議論なしでメールコマンドを与えることによって、メッセージ・テキストを送ります。
S: MAIL FROM:<WALDO@A><CRLF>
R: 354 Type mail, ended by <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: 553 No such user here
S: MRCP TO:<Raboof@Y 、gt;、lt;、CRLF>R: ここのそのような553人のユーザでない
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: 200 OK
S: MRCP TO:<@Y 、@X、 fubar@Z 、gt;、<CRLF>R: 200 OK
30
30
RFC 772 September 1980
Mail Transfer Protocol
RFC772 1980年9月のメール転送プロトコル
The text has now been sent to "Foo" and "bar" at host "Y" and will be forwarded 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.
事実上、計画を変更しないで、状態をリセットします。
31
31
一覧
スポンサーリンク
