rfc821 (1 of 8)
ron at brl-adm.UUCP
ron at brl-adm.UUCP
Mon May 19 14:00:09 AEST 1986
RFC 821
SIMPLE MAIL TRANSFER PROTOCOL
Jonathan B. Postel
August 1982
Information Sciences Institute
University of Southern California
4676 Admiralty Way
Marina del Rey, California 90291
(213) 822-1511
RFC 821 August 1982
Simple Mail Transfer Protocol
TABLE OF CONTENTS
1. INTRODUCTION .................................................. 1
2. THE SMTP MODEL ................................................ 2
3. THE SMTP PROCEDURE ............................................ 4
3.1. Mail ..................................................... 4
3.2. Forwarding ............................................... 7
3.3. Verifying and Expanding .................................. 8
3.4. Sending and Mailing ..................................... 11
3.5. Opening and Closing ..................................... 13
3.6. Relaying ................................................ 14
3.7. Domains ................................................. 17
3.8. Changing Roles .......................................... 18
4. THE SMTP SPECIFICATIONS ...................................... 19
4.1. SMTP Commands ........................................... 19
4.1.1. Command Semantics ..................................... 19
4.1.2. Command Syntax ........................................ 27
4.2. SMTP Replies ............................................ 34
4.2.1. Reply Codes by Function Group ......................... 35
4.2.2. Reply Codes in Numeric Order .......................... 36
4.3. Sequencing of Commands and Replies ...................... 37
4.4. State Diagrams .......................................... 39
4.5. Details ................................................. 41
4.5.1. Minimum Implementation ................................ 41
4.5.2. Transparency .......................................... 41
4.5.3. Sizes ................................................. 42
APPENDIX A: TCP ................................................. 44
APPENDIX B: NCP ................................................. 45
APPENDIX C: NITS ................................................ 46
APPENDIX D: X.25 ................................................ 47
APPENDIX E: Theory of Reply Codes ............................... 48
APPENDIX F: Scenarios ........................................... 51
GLOSSARY ......................................................... 64
REFERENCES ....................................................... 67
Network Working Group J. Postel
Request for Comments: DRAFT ISI
Replaces: RFC 788, 780, 772 August 1982
SIMPLE MAIL TRANSFER PROTOCOL
1. INTRODUCTION
The objective of Simple Mail Transfer Protocol (SMTP) is to transfer
mail reliably and efficiently.
SMTP is independent of the particular transmission subsystem and
requires only a reliable ordered data stream channel. Appendices A,
B, C, and D describe the use of SMTP with various transport services.
A Glossary provides the definitions of terms as used in this
document.
An important feature of SMTP is its capability to relay mail across
transport service environments. A transport service provides an
interprocess communication environment (IPCE). An IPCE may cover one
network, several networks, or a subset of a network. It is important
to realize that transport systems (or IPCEs) are not one-to-one with
networks. A process can communicate directly with another process
through any mutually known IPCE. Mail is an application or use of
interprocess communication. Mail can be communicated between
processes in different IPCEs by relaying through a process connected
to two (or more) IPCEs. More specifically, mail can be relayed
between hosts on different transport systems by a host on both
transport systems.
Postel [Page 1]
August 1982 RFC 821
Simple Mail Transfer Protocol
2. THE SMTP MODEL
The SMTP design is based on the following model of communication: as
the result of a user mail request, the sender-SMTP establishes a
two-way transmission channel to a receiver-SMTP. The receiver-SMTP
may be either the ultimate destination or an intermediate. SMTP
commands are generated by the sender-SMTP and sent to the
receiver-SMTP. SMTP replies are sent from the receiver-SMTP to the
sender-SMTP in response to the commands.
Once the transmission channel is established, the SMTP-sender sends a
MAIL command indicating the sender of the mail. If the SMTP-receiver
can accept mail it responds with an OK reply. The SMTP-sender then
sends a RCPT command identifying a recipient of the mail. If the
SMTP-receiver can accept mail for that recipient it responds with an
OK reply; if not, it responds with a reply rejecting that recipient
(but not the whole mail transaction). The SMTP-sender and
SMTP-receiver may negotiate several recipients. When the recipients
have been negotiated the SMTP-sender sends the mail data, terminating
with a special sequence. If the SMTP-receiver successfully processes
the mail data it responds with an OK reply. The dialog is purposely
lock-step, one-at-a-time.
-------------------------------------------------------------
+----------+ +----------+
+------+ | | | |
| User |<-->| | SMTP | |
+------+ | Sender- |Commands/Replies| Receiver-|
+------+ | SMTP |<-------------->| SMTP | +------+
| File |<-->| | and Mail | |<-->| File |
|System| | | | | |System|
+------+ +----------+ +----------+ +------+
Sender-SMTP Receiver-SMTP
Model for SMTP Use
Figure 1
-------------------------------------------------------------
The SMTP provides mechanisms for the transmission of mail; directly
from the sending user's host to the receiving user's host when the
[Page 2] Postel
RFC 821 August 1982
Simple Mail Transfer Protocol
two host are connected to the same transport service, or via one or
more relay SMTP-servers when the source and destination hosts are not
connected to the same transport service.
To be able to provide the relay capability the SMTP-server must be
supplied with the name of the ultimate destination host as well as
the destination mailbox name.
The argument to the MAIL command is a reverse-path, which specifies
who the mail is from. The argument to the RCPT command is a
forward-path, which specifies who the mail is to. The forward-path
is a source route, while the reverse-path is a return route (which
may be used to return a message to the sender when an error occurs
with a relayed message).
When the same message is sent to multiple recipients the SMTP
encourages the transmission of only one copy of the data for all the
recipients at the same destination host.
The mail commands and replies have a rigid syntax. Replies also have
a numeric code. In the following, examples appear which use actual
commands and replies. The complete lists of commands and replies
appears in Section 4 on specifications.
Commands and replies are not case sensitive. That is, a command or
reply word may be upper case, lower case, or any mixture of upper and
lower case. Note that this is not true of mailbox user names. For
some hosts the user name is case sensitive, and SMTP implementations
must take case to preserve the case of user names as they appear in
mailbox arguments. Host names are not case sensitive.
Commands and replies are composed of characters from the ASCII
character set [1]. When the transport service provides an 8-bit byte
(octet) transmission channel, each 7-bit character is transmitted
right justified in an octet with the high order bit cleared to zero.
When specifying the general form of a command or reply, an argument
(or special symbol) will be denoted by a meta-linguistic variable (or
constant), for example, "<string>" or "<reverse-path>". Here the
angle brackets indicate these are meta-linguistic variables.
However, some arguments use the angle brackets literally. For
example, an actual reverse-path is enclosed in angle brackets, i.e.,
"<John.Smith at USC-ISI.ARPA>" is an instance of <reverse-path> (the
angle brackets are actually transmitted in the command or reply).
Postel [Page 3]
August 1982 RFC 821
Simple Mail Transfer Protocol
3. THE SMTP PROCEDURES
This section presents the procedures used in SMTP in several parts.
First comes the basic mail procedure defined as a mail transaction.
Following this are descriptions of forwarding mail, verifying mailbox
names and expanding mailing lists, sending to terminals instead of or
in combination with mailboxes, and the opening and closing exchanges.
At the end of this section are comments on relaying, a note on mail
domains, and a discussion of changing roles. Throughout this section
are examples of partial command and reply sequences, several complete
scenarios are presented in Appendix F.
3.1. MAIL
There are three steps to SMTP mail transactions. The transaction
is started with a MAIL command which gives the sender
identification. A series of one or more RCPT commands follows
giving the receiver information. Then a DATA command gives the
mail data. And finally, the end of mail data indicator confirms
the transaction.
The first step in the procedure is the MAIL command. The
<reverse-path> contains the source mailbox.
MAIL <SP> FROM:<reverse-path> <CRLF>
This command tells the SMTP-receiver that a new mail
transaction is starting and to reset all its state tables and
buffers, including any recipients or mail data. It gives the
reverse-path which can be used to report errors. If accepted,
the receiver-SMTP returns a 250 OK reply.
The <reverse-path> can contain more than just a mailbox. The
<reverse-path> is a reverse source routing list of hosts and
source mailbox. The first host in the <reverse-path> should be
the host sending this command.
The second step in the procedure is the RCPT command.
RCPT <SP> TO:<forward-path> <CRLF>
This command gives a forward-path identifying one recipient.
If accepted, the receiver-SMTP returns a 250 OK reply, and
stores the forward-path. If the recipient is unknown the
receiver-SMTP returns a 550 Failure reply. This second step of
the procedure can be repeated any number of times.
[Page 4] Postel
RFC 821 August 1982
Simple Mail Transfer Protocol
The <forward-path> can contain more than just a mailbox. The
<forward-path> is a source routing list of hosts and the
destination mailbox. The first host in the <forward-path>
should be the host receiving this command.
The third step in the procedure is the DATA command.
DATA <CRLF>
If accepted, the receiver-SMTP returns a 354 Intermediate reply
and considers all succeeding lines to be the message text.
When the end of text is received and stored the SMTP-receiver
sends a 250 OK reply.
Since the mail data is sent on the transmission channel the end
of the mail data must be indicated so that the command and
reply dialog can be resumed. SMTP indicates the end of the
mail data by sending a line containing only a period. A
transparency procedure is used to prevent this from interfering
with the user's text (see Section 4.5.2).
Please note that the mail data includes the memo header
items such as Date, Subject, To, Cc, From [2].
The end of mail data indicator also confirms the mail
transaction and tells the receiver-SMTP to now process the
stored recipients and mail data. If accepted, the
receiver-SMTP returns a 250 OK reply. The DATA command should
fail only if the mail transaction was incomplete (for example,
no recipients), or if resources are not available.
The above procedure is an example of a mail transaction. These
commands must be used only in the order discussed above.
Example 1 (below) illustrates the use of these commands in a mail
transaction.
Postel [Page 5]
August 1982 RFC 821
Simple Mail Transfer Protocol
-------------------------------------------------------------
Example of the SMTP Procedure
This SMTP example shows mail sent by Smith at host Alpha.ARPA,
to Jones, Green, and Brown at host Beta.ARPA. Here we assume
that host Alpha contacts host Beta directly.
S: MAIL FROM:<Smith at Alpha.ARPA>
R: 250 OK
S: RCPT TO:<Jones at Beta.ARPA>
R: 250 OK
S: RCPT TO:<Green at Beta.ARPA>
R: 550 No such user here
S: RCPT TO:<Brown at Beta.ARPA>
R: 250 OK
S: DATA
R: 354 Start mail input; end with <CRLF>.<CRLF>
S: Blah blah blah...
S: ...etc. etc. etc.
S: <CRLF>.<CRLF>
R: 250 OK
The mail has now been accepted for Jones and Brown. Green did
not have a mailbox at host Beta.
Example 1
-------------------------------------------------------------
[Page 6] Postel
More information about the Mod.sources.doc
mailing list