rfc821 (4 of 8)
ron at brl-adm.UUCP
ron at brl-adm.UUCP
Mon May 19 14:00:14 AEST 1986
RFC 821 August 1982
Simple Mail Transfer Protocol
There are restrictions on the order in which these command may
be used.
The first command in a session must be the HELO command.
The HELO command may be used later in a session as well. If
the HELO command argument is not acceptable a 501 failure
reply must be returned and the receiver-SMTP must stay in
the same state.
The NOOP, HELP, EXPN, and VRFY commands can be used at any
time during a session.
The MAIL, SEND, SOML, or SAML commands begin a mail
transaction. Once started a mail transaction consists of
one of the transaction beginning commands, one or more RCPT
commands, and a DATA command, in that order. A mail
transaction may be aborted by the RSET command. There may
be zero or more transactions in a session.
If the transaction beginning command argument is not
acceptable a 501 failure reply must be returned and the
receiver-SMTP must stay in the same state. If the commands
in a transaction are out of order a 503 failure reply must
be returned and the receiver-SMTP must stay in the same
state.
The last command in a session must be the QUIT command. The
QUIT command can not be used at any other time in a session.
4.1.2. COMMAND SYNTAX
The commands consist of a command code followed by an argument
field. 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 "TO" or "to" for the forward-path. Command codes and
the argument fields are separated by one or more spaces.
However, within the reverse-path and forward-path arguments
case is important. In particular, in some hosts the user
"smith" is different from the user "Smith".
Postel [Page 27]
August 1982 RFC 821
Simple Mail Transfer Protocol
The argument field consists of a variable length character
string ending with the character sequence <CRLF>. The receiver
is to take no action until this sequence is received.
Square brackets denote an optional argument field. If the
option is not taken, the appropriate default is implied.
[Page 28] Postel
RFC 821 August 1982
Simple Mail Transfer Protocol
The following are the SMTP commands:
HELO <SP> <domain> <CRLF>
MAIL <SP> FROM:<reverse-path> <CRLF>
RCPT <SP> TO:<forward-path> <CRLF>
DATA <CRLF>
RSET <CRLF>
SEND <SP> FROM:<reverse-path> <CRLF>
SOML <SP> FROM:<reverse-path> <CRLF>
SAML <SP> FROM:<reverse-path> <CRLF>
VRFY <SP> <string> <CRLF>
EXPN <SP> <string> <CRLF>
HELP [<SP> <string>] <CRLF>
NOOP <CRLF>
QUIT <CRLF>
TURN <CRLF>
Postel [Page 29]
August 1982 RFC 821
Simple Mail Transfer Protocol
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.
<reverse-path> ::= <path>
<forward-path> ::= <path>
<path> ::= "<" [ <a-d-l> ":" ] <mailbox> ">"
<a-d-l> ::= <at-domain> | <at-domain> "," <a-d-l>
<at-domain> ::= "@" <domain>
<domain> ::= <element> | <element> "." <domain>
<element> ::= <name> | "#" <number> | "[" <dotnum> "]"
<mailbox> ::= <local-part> "@" <domain>
<local-part> ::= <dot-string> | <quoted-string>
<name> ::= <a> <ldh-str> <let-dig>
<ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
<let-dig> ::= <a> | <d>
<let-dig-hyp> ::= <a> | <d> | "-"
<dot-string> ::= <string> | <string> "." <dot-string>
<string> ::= <char> | <char> <string>
<quoted-string> ::= """ <qtext> """
<qtext> ::= "\" <x> | "\" <x> <qtext> | <q> | <q> <qtext>
<char> ::= <c> | "\" <x>
<dotnum> ::= <snum> "." <snum> "." <snum> "." <snum>
<number> ::= <d> | <d> <number>
<CRLF> ::= <CR> <LF>
[Page 30] Postel
RFC 821 August 1982
Simple Mail Transfer Protocol
<CR> ::= the carriage return character (ASCII code 13)
<LF> ::= the line feed character (ASCII code 10)
<SP> ::= the space character (ASCII code 32)
<snum> ::= one, two, or three digits representing a decimal
integer value in the range 0 through 255
<a> ::= any one of the 52 alphabetic characters A through Z
in upper case and a through z in lower case
<c> ::= any one of the 128 ASCII characters, but not any
<special> or <SP>
<d> ::= any one of the ten digits 0 through 9
<q> ::= any one of the 128 ASCII characters except <CR>,
<LF>, quote ("), or backslash (\)
<x> ::= any one of the 128 ASCII characters (no exceptions)
<special> ::= "<" | ">" | "(" | ")" | "[" | "]" | "\" | "."
| "," | ";" | ":" | "@" """ | the control
characters (ASCII codes 0 through 31 inclusive and
127)
Note that the backslash, "\", is a quote character, which is
used to indicate that the next character is to be used
literally (instead of its normal interpretation). For example,
"Joe\,Smith" could be used to indicate a single nine character
user field with comma being the fourth character of the field.
Hosts are generally known by names which are translated to
addresses in each host. Note that the name elements of domains
are the official names -- no use of nicknames or aliases is
allowed.
Sometimes a host is not known to the translation function and
communication is blocked. To bypass this barrier two numeric
forms are also allowed for host "names". One form is a decimal
integer prefixed by a pound sign, "#", which indicates the
number is the address of the host. Another form is four small
decimal integers separated by dots and enclosed by brackets,
e.g., "[123.255.37.2]", which indicates a 32-bit ARPA Internet
Address in four 8-bit fields.
Postel [Page 31]
August 1982 RFC 821
Simple Mail Transfer Protocol
The time stamp line and the return path line are formally
defined as follows:
<return-path-line> ::= "Return-Path:" <SP><reverse-path><CRLF>
<time-stamp-line> ::= "Received:" <SP> <stamp> <CRLF>
<stamp> ::= <from-domain> <by-domain> <opt-info> ";"
<daytime>
<from-domain> ::= "FROM" <SP> <domain> <SP>
<by-domain> ::= "BY" <SP> <domain> <SP>
<opt-info> ::= [<via>] [<with>] [<id>] [<for>]
<via> ::= "VIA" <SP> <link> <SP>
<with> ::= "WITH" <SP> <protocol> <SP>
<id> ::= "ID" <SP> <string> <SP>
<for> ::= "FOR" <SP> <path> <SP>
<link> ::= The standard names for links are registered with
the Network Information Center.
<protocol> ::= The standard names for protocols are
registered with the Network Information Center.
<daytime> ::= <SP> <date> <SP> <time>
<date> ::= <dd> <SP> <mon> <SP> <yy>
<time> ::= <hh> ":" <mm> ":" <ss> <SP> <zone>
<dd> ::= the one or two decimal integer day of the month in
the range 1 to 31.
<mon> ::= "JAN" | "FEB" | "MAR" | "APR" | "MAY" | "JUN" |
"JUL" | "AUG" | "SEP" | "OCT" | "NOV" | "DEC"
<yy> ::= the two decimal integer year of the century in the
range 00 to 99.
[Page 32] Postel
RFC 821 August 1982
Simple Mail Transfer Protocol
<hh> ::= the two decimal integer hour of the day in the
range 00 to 24.
<mm> ::= the two decimal integer minute of the hour in the
range 00 to 59.
<ss> ::= the two decimal integer second of the minute in the
range 00 to 59.
<zone> ::= "UT" for Universal Time (the default) or other
time zone designator (as in [2]).
-------------------------------------------------------------
Return Path Example
Return-Path: <@CHARLIE.ARPA, at BAKER.ARPA:JOE at ABLE.ARPA>
Example 9
-------------------------------------------------------------
-------------------------------------------------------------
Time Stamp Line Example
Received: FROM ABC.ARPA BY XYZ.ARPA ; 22 OCT 81 09:23:59 PDT
Received: from ABC.ARPA by XYZ.ARPA via TELENET with X25
id M12345 for Smith at PDQ.ARPA ; 22 OCT 81 09:23:59 PDT
Example 10
-------------------------------------------------------------
Postel [Page 33]
August 1982 RFC 821
Simple Mail Transfer Protocol
4.2. SMTP REPLIES
Replies to SMTP commands are devised to ensure the synchronization
of requests and actions in the process of mail transfer, and to
guarantee that the sender-SMTP always knows the state of the
receiver-SMTP. Every command must generate exactly one reply.
The details of the command-reply sequence are made explicit in
Section 5.3 on Sequencing and Section 5.4 State Diagrams.
An SMTP 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-SMTP need not 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 and context dependent, so there are
likely to be varying texts for each reply code. A discussion of
the theory of reply codes is given in Appendix E. Formally, a
reply is defined to be the sequence: a three-digit code, <SP>,
one line of text, and <CRLF>, or a multiline reply (as defined in
Appendix E). Only the EXPN and HELP commands are expected to
result in multiline replies in normal circumstances, however
multiline replies are allowed for any command.
[Page 34] Postel
RFC 821 August 1982
Simple Mail Transfer Protocol
4.2.1. REPLY CODES BY FUNCTION GROUPS
500 Syntax error, command unrecognized
[This may include errors such as command line too long]
501 Syntax error in parameters or arguments
502 Command not implemented
503 Bad sequence of commands
504 Command parameter not implemented
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]
220 <domain> Service ready
221 <domain> Service closing transmission channel
421 <domain> Service not available,
closing transmission channel
[This may be a reply to any command if the service knows it
must shut down]
250 Requested mail action okay, completed
251 User not local; will forward to <forward-path>
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: error in processing
551 User not local; please try <forward-path>
452 Requested action not taken: insufficient system storage
552 Requested mail action aborted: exceeded storage allocation
553 Requested action not taken: mailbox name not allowed
[E.g., mailbox syntax incorrect]
354 Start mail input; end with <CRLF>.<CRLF>
554 Transaction failed
Postel [Page 35]
August 1982 RFC 821
Simple Mail Transfer Protocol
4.2.2. NUMERIC ORDER LIST OF REPLY CODES
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]
220 <domain> Service ready
221 <domain> Service closing transmission channel
250 Requested mail action okay, completed
251 User not local; will forward to <forward-path>
354 Start mail input; end with <CRLF>.<CRLF>
421 <domain> Service not available,
closing transmission channel
[This may be a reply to any command if the service knows it
must shut down]
450 Requested mail action not taken: mailbox unavailable
[E.g., mailbox busy]
451 Requested action aborted: local error in processing
452 Requested action not taken: insufficient system storage
500 Syntax error, command unrecognized
[This may include errors such as command line too long]
501 Syntax error in parameters or arguments
502 Command not implemented
503 Bad sequence of commands
504 Command parameter not implemented
550 Requested action not taken: mailbox unavailable
[E.g., mailbox not found, no access]
551 User not local; please try <forward-path>
552 Requested mail action aborted: exceeded storage allocation
553 Requested action not taken: mailbox name not allowed
[E.g., mailbox syntax incorrect]
554 Transaction failed
[Page 36] Postel
More information about the Mod.sources.doc
mailing list