📄 rfc772.txt
字号:
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.
QUIT (QUIT)
This command specifies that the receiver must close the
control connection.
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.
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.
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:
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.
7
September 1980 RFC 772
Mail Transfer Protocol
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.
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.
The following are the MTP commands:
MAIL <SP> FROM:<sender> [<SP> TO:<path>] <CRLF>
MRSQ [<SP> <scheme>] <CRLF>
MRCP <SP> TO:<path> <CRLF>
HELP [<SP> <string>] <CRLF>
QUIT <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.
<sender> ::= "<" <mailbox> ">"
<path> ::= "<" ["@" <host> "," ...] <mailbox> ">"
<scheme> ::= "R" | "T" | "?"
<string> ::= <char> | <char><string>
<mailbox> ::= <user> "@" <host>
<host> ::= <string>
<user> ::= <string>
<char> ::= any of the 128 ASCII characters except <CR> and <LF>
8
RFC 772 September 1980
Mail Transfer Protocol
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.
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.
Old New
-+-+-+-+-+-----+---+--+---+--+-
...|M|A|I|L| ... |IAC|IP|IAC|DM|...
-+-+-+-+-+-----+---+--+---+--+-
9
September 1980 RFC 772
Mail Transfer Protocol
MTP REPLIES
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.
The details of the command-reply sequence are made explicit in the
section on State 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.
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.
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>.
10
RFC 772 September 1980
Mail Transfer Protocol
For example:
123-First line
Second line
234 A line beginning with numbers
123 The last line
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.
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.
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.
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.
There are five values for the first digit of the reply code:
1yz Positive Preliminary reply
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
11
September 1980 RFC 772
Mail Transfer Protocol
in violation of protocol. However, receiver-MTP processes
should queue any commands that arrive while a preceding
command is in progress.)
2yz Positive Completion reply
The requested action has been successfully completed. A new
request may be initiated.
3yz Positive Intermediate reply
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.
4yz Transient Negative Completion reply
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).
5yz Permanent Negative Completion reply
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.)
12
RFC 772 September 1980
Mail Transfer Protocol
The second digit encodes responses in specific categories:
x0z Syntax -- These replies refer to syntax errors,
syntactically correct commands that don't fit any
functional category, and unimplemented or superfluous
commands.
x1z Information -- These are replies to requests for
information, such as status or help.
x2z Connections -- These are replies referring to the control
connection.
x3z Unspecified as yet.
x4z Unspecified as yet.
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -