📄 rfc772.txt
字号:
x5z Mail system -- These replies indicate the status of the
receiver mail system vis-a-vis the requested transfer or
other mail system action.
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.
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.
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
13
September 1980 RFC 772
Mail Transfer Protocol
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
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]
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>
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>
14
RFC 772 September 1980
Mail Transfer Protocol
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
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>
<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.
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.
151 User not local; will forward to <user>@<host>
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.
15
September 1980 RFC 772
Mail Transfer Protocol
152 User Unknown; mail will be forwarded by the operator
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.
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.
SCHEME SELECTION: 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 [<SP> <scheme>] <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.
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
16
RFC 772 September 1980
Mail Transfer Protocol
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.
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:
215 <SP> <scheme> [<SP> <arbitrary text>] <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.
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.
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.
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.
17
September 1980 RFC 772
Mail Transfer Protocol
RECIPIENT SPECIFICATION: 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>
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
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.
SCHEME MECHANICS: MRSQ R (RECIPIENTS-FIRST)
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.
18
RFC 772 September 1980
Mail Transfer Protocol
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.
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.
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".
See the example in Appendix A for a mail transfer using MRSQ R.
SCHEME MECHANICS: MRSQ T (TEXT-FIRST)
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -