mirror of
https://github.com/rn10950/RetroZilla.git
synced 2024-11-12 19:00:11 +01:00
3702 lines
106 KiB
HTML
3702 lines
106 KiB
HTML
|
<script>
|
|||
|
document["balah"].src = eval("balah" + "on.src");
|
|||
|
</script>
|
|||
|
<P>
|
|||
|
RFC788
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
SIMPLE MAIL TRANSFER PROTOCOL
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Jonathan B. Postel
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
November 1981
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Information Sciences Institute
|
|||
|
University of Southern California
|
|||
|
4676 Admiralty Way
|
|||
|
Marina del Rey, California 90291
|
|||
|
|
|||
|
(213) 822-1511
|
|||
|
|
|||
|
|
|||
|
RFC 788 November 1981
|
|||
|
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 ..................................... 10
|
|||
|
3.5. Opening and Closing ..................................... 12
|
|||
|
3.6. Relaying ................................................ 13
|
|||
|
3.7. Domains ................................................. 15
|
|||
|
|
|||
|
4. THE SMTP SPECIFICATIONS ...................................... 16
|
|||
|
|
|||
|
4.1. SMTP Commands ........................................... 16
|
|||
|
4.1.1. Command Semantics ..................................... 16
|
|||
|
4.1.2. Command Syntax ........................................ 23
|
|||
|
4.2. SMTP Replies ............................................ 28
|
|||
|
4.2.1. Reply Codes by Function Group ......................... 29
|
|||
|
4.2.2. Reply Codes in Numeric Order .......................... 30
|
|||
|
4.3. Sequencing of Commands and Replies ...................... 31
|
|||
|
4.4. State Diagrams .......................................... 33
|
|||
|
4.5. Details ................................................. 35
|
|||
|
4.5.1. Minimum Implementation ................................ 35
|
|||
|
4.5.2. Transparency .......................................... 35
|
|||
|
4.5.3. Sizes ................................................. 36
|
|||
|
|
|||
|
APPENDIX A: TCP ................................................. 38
|
|||
|
APPENDIX B: NCP ................................................. 39
|
|||
|
APPENDIX C: NITS ................................................ 40
|
|||
|
APPENDIX D: X.25 ................................................ 41
|
|||
|
APPENDIX E: Theory of Reply Codes ............................... 42
|
|||
|
APPENDIX F: Scenarios ........................................... 45
|
|||
|
|
|||
|
GLOSSARY ......................................................... 58
|
|||
|
|
|||
|
REFERENCES ....................................................... 61
|
|||
|
|
|||
|
|
|||
|
Network Working Group J. Postel
|
|||
|
Request for Comments: 788 ISI
|
|||
|
Replaces: RFC 780, 772 November 1981
|
|||
|
|
|||
|
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]
|
|||
|
|
|||
|
|
|||
|
|
|||
|
November 1981 RFC 788
|
|||
|
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
|
|||
|
full-duplex 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 788 November 1981
|
|||
|
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]. Each 7-bit character is transmitted right
|
|||
|
justified in an 8-bit byte (or 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 a meta-linguistic variables.
|
|||
|
However, some arguments use the angle brackets literally. For
|
|||
|
example, an actual reverse-path is enclosed in angle brackets, i.e.,
|
|||
|
"<Smith@ISIA>" is an instance of <reverse-path> (the angle brackets
|
|||
|
are actually transmitted in the command or reply).
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Postel [Page 3]
|
|||
|
|
|||
|
|
|||
|
|
|||
|
November 1981 RFC 788
|
|||
|
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, and a note on
|
|||
|
mail domains. 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 a SMTP mail transaction. The transaction
|
|||
|
is started with a MAIL command which gives the sender
|
|||
|
identification. A series of one or more RCPT commands follow
|
|||
|
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 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 788 November 1981
|
|||
|
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
|
|||
|
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 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 SMTP 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]
|
|||
|
|
|||
|
|
|||
|
|
|||
|
November 1981 RFC 788
|
|||
|
Simple Mail Transfer Protocol
|
|||
|
|
|||
|
|
|||
|
|
|||
|
-------------------------------------------------------------
|
|||
|
|
|||
|
Example of the SMTP Procedure
|
|||
|
|
|||
|
This SMTP example shows mail sent by Smith at host Alpha, to
|
|||
|
Jones, Green, and Brown at host Beta. Here we assume that host
|
|||
|
Alpha contacts host Beta directly.
|
|||
|
|
|||
|
S: MAIL FROM:<Smith@Alpha>
|
|||
|
R: 250 OK
|
|||
|
|
|||
|
S: RCPT TO:<Jones@Beta>
|
|||
|
R: 250 OK
|
|||
|
|
|||
|
S: RCPT TO:<Green@Beta>
|
|||
|
R: 550 No such user here
|
|||
|
|
|||
|
S: RCPT TO:<Brown@Beta>
|
|||
|
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
|
|||
|
|
|||
|
|
|||
|
|
|||
|
RFC 788 November 1981
|
|||
|
Simple Mail Transfer Protocol
|
|||
|
|
|||
|
|
|||
|
|
|||
|
3.2. FORWARDING
|
|||
|
|
|||
|
There are some cases where the destination information in the
|
|||
|
<forward-path> is incorrect, but the receiver-SMTP knows the
|
|||
|
correct destination. In such cases, one the following replies
|
|||
|
should be used to allow the sender to contact the correct
|
|||
|
destination.
|
|||
|
|
|||
|
251 User not local; will forward to <forward-path>
|
|||
|
|
|||
|
This reply indicates that the receiver-SMTP knows the user's
|
|||
|
mailbox is on another host and indicates the correct
|
|||
|
forward-path to use in the future. Note that either the
|
|||
|
host or user or both may be different. The receiver takes
|
|||
|
responsibility for delivering the message.
|
|||
|
|
|||
|
551 User not local; please try <forward-path>
|
|||
|
|
|||
|
This reply indicates that the receiver-SMTP knows the user's
|
|||
|
mailbox is on another host and indicates the correct
|
|||
|
forward-path to use. Note that either the host or user or
|
|||
|
both may be different. The receiver refuses to accept mail
|
|||
|
for this user, and the sender must either redirect the mail
|
|||
|
according to the information provided or return an error
|
|||
|
response to the originating user.
|
|||
|
|
|||
|
Example 2 illustrates the use of these responses.
|
|||
|
|
|||
|
-------------------------------------------------------------
|
|||
|
|
|||
|
Example of Forwarding
|
|||
|
|
|||
|
Either
|
|||
|
|
|||
|
S: RCPT TO:<Postel@ISI>
|
|||
|
R: 251 User not local; will forward to <Postel@ISIF>
|
|||
|
|
|||
|
Or
|
|||
|
|
|||
|
S: RCPT TO:<Paul@ISIB>
|
|||
|
R: 551 User not local; please try <Mockapetris@ISIF>
|
|||
|
|
|||
|
Example 2
|
|||
|
|
|||
|
-------------------------------------------------------------
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Postel [Page 7]
|
|||
|
|
|||
|
|
|||
|
|
|||
|
November 1981 RFC 788
|
|||
|
Simple Mail Transfer Protocol
|
|||
|
|
|||
|
|
|||
|
|
|||
|
3.3. VERIFYING AND EXPANDING
|
|||
|
|
|||
|
SMTP provides as additional features, commands to verify a user
|
|||
|
name or expand a mailing list. This is done with the VRFY and
|
|||
|
EXPN commands, which have a character string arguments. For the
|
|||
|
VRFY command, the string is a user name, and the the response may
|
|||
|
include the full name of the user and must include the mailbox of
|
|||
|
the user. For the EXPN command, the string identifies a mailing
|
|||
|
list, and the multiline response may include the full name of the
|
|||
|
users and must give the mailboxes on the mailing list.
|
|||
|
|
|||
|
The case of verifying a user name is straightforward as shown in
|
|||
|
example 3.
|
|||
|
|
|||
|
-------------------------------------------------------------
|
|||
|
|
|||
|
Example of Verifying a User Name
|
|||
|
|
|||
|
Either
|
|||
|
|
|||
|
S: VRFY Postel
|
|||
|
R: 250 Jon Postel <Postel@ISIF>
|
|||
|
|
|||
|
Or
|
|||
|
|
|||
|
S: VRFY Jones
|
|||
|
R: 550 String does not match anything.
|
|||
|
|
|||
|
Example 3
|
|||
|
|
|||
|
-------------------------------------------------------------
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
[Page 8] Postel
|
|||
|
|
|||
|
|
|||
|
|
|||
|
RFC 788 November 1981
|
|||
|
Simple Mail Transfer Protocol
|
|||
|
|
|||
|
|
|||
|
|
|||
|
The case of expanding a mailbox list requires a multiline reply as
|
|||
|
shown in example 4.
|
|||
|
|
|||
|
-------------------------------------------------------------
|
|||
|
|
|||
|
Example of Expanding a Mailing List
|
|||
|
|
|||
|
Either
|
|||
|
|
|||
|
S: EXPN Example-People
|
|||
|
R: 250-Jon Postel <Postel@ISIF>
|
|||
|
R: 250-Fred Fonebone <Fonebone@ISIQ>
|
|||
|
R: 250-Sam Q. Smith <SQSmith@ISIQ>
|
|||
|
R: 250-Quincy Smith <@ISIF,Q-Smith@ISI-VAXA>
|
|||
|
R: 250-<joe@foo-unix>
|
|||
|
R: 250 <xyz@bar-unix>
|
|||
|
|
|||
|
Or
|
|||
|
|
|||
|
S: EXPN Executive-Washroom-List
|
|||
|
R: 550 Access Denied to You.
|
|||
|
|
|||
|
Example 4
|
|||
|
|
|||
|
-------------------------------------------------------------
|
|||
|
|
|||
|
The character string arguments of the VRFY and EXPN commands
|
|||
|
cannot be further restricted due to the variety of implementations
|
|||
|
of the user name and mailbox list concepts. On some systems it
|
|||
|
may be appropriate for the argument of the EXPN command to be a
|
|||
|
file name for a file containing a mailing list, but again there is
|
|||
|
a variety of file naming conventions in the internet.
|
|||
|
|
|||
|
The VRFY and EXPN commands are not included in the minimum
|
|||
|
implementation (Section 4.5.1), and are not required to work
|
|||
|
across relays when they are implemented.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Postel [Page 9]
|
|||
|
|
|||
|
|
|||
|
|
|||
|
November 1981 RFC 788
|
|||
|
Simple Mail Transfer Protocol
|
|||
|
|
|||
|
|
|||
|
|
|||
|
3.4. SENDING AND MAILING
|
|||
|
|
|||
|
The main purpose of SMTP is to deliver messages to user's
|
|||
|
mailboxes. A very similar service provided by some hosts is to
|
|||
|
deliver messages to user's terminals (provided the user is active
|
|||
|
on the host). The delivery to the user's mailbox is called
|
|||
|
"mailing", the delivery to the user's terminal is called
|
|||
|
"sending". Because in many hosts the implementation of sending is
|
|||
|
nearly identical to the implementation of mailing these two
|
|||
|
functions are combined in SMTP. However the sending commands are
|
|||
|
not included in the required minimum implementation
|
|||
|
(Section 4.5.1). User's should have the ability to control the
|
|||
|
writing of messages on their terminals. Most hosts permit the
|
|||
|
user's to accept or refuse such messages.
|
|||
|
|
|||
|
The following three command are defined to support the sending
|
|||
|
options, these are used in the mail transaction instead of the
|
|||
|
MAIL command and inform the receiver-SMTP of the special semantics
|
|||
|
of this transaction:
|
|||
|
|
|||
|
SEND <SP> FROM:<reverse-path> <CRLF>
|
|||
|
|
|||
|
The SEND command requires that the mail data be delivered to
|
|||
|
the user's terminal. If the user is not active (or not
|
|||
|
accepting terminal messages) on the host a 450 reply may
|
|||
|
returned to a RCPT command. The mail transaction is
|
|||
|
successful if the message is delivered the terminal.
|
|||
|
|
|||
|
SOML <SP> FROM:<reverse-path> <CRLF>
|
|||
|
|
|||
|
The Send Or MaiL command requires that the mail data be
|
|||
|
delivered to the user's terminal if the user is active (and
|
|||
|
accepting terminal messages) on the host. If the user is
|
|||
|
not active (or not accepting terminal messages) then the
|
|||
|
mail data is entered into the user's mailbox. The mail
|
|||
|
transaction is successful if the message is delivered either
|
|||
|
to the terminal or the mailbox.
|
|||
|
|
|||
|
SAML <SP> FROM:<reverse-path> <CRLF>
|
|||
|
|
|||
|
The Send And MaiL command requires that the mail data be
|
|||
|
delivered to the user's terminal if the user is active (and
|
|||
|
accepting terminal messages) on the host. In any case the
|
|||
|
mail data is entered into the user's mailbox. The mail
|
|||
|
transaction is successful if the message is delivered the
|
|||
|
mailbox.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
[Page 10] Postel
|
|||
|
|
|||
|
|
|||
|
|
|||
|
RFC 788 November 1981
|
|||
|
Simple Mail Transfer Protocol
|
|||
|
|
|||
|
|
|||
|
|
|||
|
The same reply codes that are used for the MAIL commands are used
|
|||
|
for these commands.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Postel [Page 11]
|
|||
|
|
|||
|
|
|||
|
|
|||
|
November 1981 RFC 788
|
|||
|
Simple Mail Transfer Protocol
|
|||
|
|
|||
|
|
|||
|
|
|||
|
3.5. OPENING AND CLOSING
|
|||
|
|
|||
|
At the time the transmission channel is opened there is an
|
|||
|
exchange to ensure that the hosts are communicating with the hosts
|
|||
|
they think they are.
|
|||
|
|
|||
|
The following two commands are used in transmission channel
|
|||
|
opening and closing:
|
|||
|
|
|||
|
HELO <SP> <host> <CRLF>
|
|||
|
|
|||
|
QUIT <CRLF>
|
|||
|
|
|||
|
In the HELO command the host sending the command identifies
|
|||
|
itself; the command may be interpreted as saying "Hello, i am
|
|||
|
<host>".
|
|||
|
|
|||
|
-------------------------------------------------------------
|
|||
|
|
|||
|
Example of Connection Opening
|
|||
|
|
|||
|
R: 220 BBN-UNIX Simple Mail Transfer Service Ready
|
|||
|
S: HELO USC-ISIF
|
|||
|
R: 250 BBN-UNIX
|
|||
|
|
|||
|
Example 5
|
|||
|
|
|||
|
-------------------------------------------------------------
|
|||
|
|
|||
|
-------------------------------------------------------------
|
|||
|
|
|||
|
Example of Connection Closing
|
|||
|
|
|||
|
S: QUIT
|
|||
|
R: 221 BBN-UNIX Service closing transmission channel
|
|||
|
|
|||
|
Example 6
|
|||
|
|
|||
|
-------------------------------------------------------------
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
[Page 12] Postel
|
|||
|
|
|||
|
|
|||
|
|
|||
|
RFC 788 November 1981
|
|||
|
Simple Mail Transfer Protocol
|
|||
|
|
|||
|
|
|||
|
|
|||
|
3.6. RELAYING
|
|||
|
|
|||
|
The forward-path may be a source route of the form
|
|||
|
"@ONE,@TWO,JOE@THREE", where ONE, TWO, and THREE are hosts. This
|
|||
|
form is used to emphasize the distinction between an address and a
|
|||
|
route. The mailbox is an absolute address, and the route is
|
|||
|
information about how to get there. The two concepts should not
|
|||
|
be confused.
|
|||
|
|
|||
|
The elements of the forward-path are moved to the reverse-path as
|
|||
|
the message is relayed from one server-SMTP to another. The
|
|||
|
reverse-path is a reverse source route, (i.e., a source route from
|
|||
|
the current location of the message to the originator of the
|
|||
|
message). When a server-SMTP deletes its identifier from the
|
|||
|
forward-path and inserts it into the reverse-path, it must use the
|
|||
|
name it is known by in the environment it is sending into, not the
|
|||
|
environment the mail came from, in case the server-SMTP is known
|
|||
|
by different names in different environments.
|
|||
|
|
|||
|
Using source routing the receiver-SMTP receives mail to be relayed
|
|||
|
to another server-SMTP The receiver-SMTP may accept or reject the
|
|||
|
task of relaying the mail in the same way it accepts or rejects
|
|||
|
mail for a local user. The receiver-SMTP transforms the command
|
|||
|
arguments by moving its own identifier from the forward-path to
|
|||
|
the beginning of the reverse-path. The receiver-SMTP then becomes
|
|||
|
a sender-SMTP, establishes a transmission channel to the next SMTP
|
|||
|
in the forward-path, and sends it the mail.
|
|||
|
|
|||
|
The first host in the reverse-path should be the host sending the
|
|||
|
SMTP commands, and the first host in the forward-path should be
|
|||
|
the host receiving the SMTP commands.
|
|||
|
|
|||
|
Notice that the forward-path and reverse-path appear in the SMTP
|
|||
|
commands and replies, but not necessarily in the message. That
|
|||
|
is, there is no need for these paths and especially this syntax to
|
|||
|
appear in the "To:" , "From:", "CC:", etc. fields of the message
|
|||
|
header.
|
|||
|
|
|||
|
If a server-SMTP has accepted the task of relaying the mail and
|
|||
|
later finds that the forward-path is incorrect or that the mail
|
|||
|
cannot be delivered for whatever reason, then it must construct an
|
|||
|
"undeliverable mail" notification message and send it to the
|
|||
|
originator of the undeliverable mail (as indicated by the
|
|||
|
reverse-path).
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Postel [Page 13]
|
|||
|
|
|||
|
|
|||
|
|
|||
|
November 1981 RFC 788
|
|||
|
Simple Mail Transfer Protocol
|
|||
|
|
|||
|
|
|||
|
|
|||
|
This notification message must be from the server-SMTP at this
|
|||
|
host. Of course, server-SMTPs should not send notification
|
|||
|
messages about problems with notification messages. One way to
|
|||
|
prevent loops in error reporting is to specify a null reverse-path
|
|||
|
in the MAIL command of a notification message. When such a
|
|||
|
message is relayed it is permissible to leave the reverse-path
|
|||
|
null. A MAIL command with a null reverse-path appears as follows:
|
|||
|
|
|||
|
MAIL FROM:<>
|
|||
|
|
|||
|
An undeliverable mail notification message is shown in example 7.
|
|||
|
This notification is in response to a message originated by JOE at
|
|||
|
HOSTW and sent via HOSTX to HOSTY with instructions to relay it on
|
|||
|
to HOSTZ. What we see in the example is the transaction between
|
|||
|
HOSTY and HOSTX, which is the first step in the return of the
|
|||
|
notification message.
|
|||
|
|
|||
|
-------------------------------------------------------------
|
|||
|
|
|||
|
Example Undeliverable Mail Notification Message
|
|||
|
|
|||
|
S: MAIL FROM:<>
|
|||
|
R: 250 ok
|
|||
|
S: RCPT TO:<@HOSTX,JOE@HOSTW>
|
|||
|
R: 250 ok
|
|||
|
S: DATA
|
|||
|
R: 354 send the mail data, end with .
|
|||
|
S: Date: 23 Oct 81
|
|||
|
S: Sender: SMTP@HOSTY
|
|||
|
S: Subject: Mail System Problem
|
|||
|
S:
|
|||
|
S: Sorry JOE, your message to SAM@HOSTZ lost.
|
|||
|
S: HOSTZ said this:
|
|||
|
S: "550 No Such User"
|
|||
|
S: .
|
|||
|
R: 250 ok
|
|||
|
|
|||
|
Example 7
|
|||
|
|
|||
|
-------------------------------------------------------------
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
[Page 14] Postel
|
|||
|
|
|||
|
|
|||
|
|
|||
|
RFC 788 November 1981
|
|||
|
Simple Mail Transfer Protocol
|
|||
|
|
|||
|
|
|||
|
|
|||
|
3.7. DOMAINS
|
|||
|
|
|||
|
At some not too distant future time it might be necessary to
|
|||
|
expand the mailbox format to include a region or name domain
|
|||
|
identifier. There is quite a bit of discussion on this at
|
|||
|
present, and is likely that SMTP will be revised in the future to
|
|||
|
take into account naming domains.
|
|||
|
|
|||
|
The examples in this document do not show mail domains.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Postel [Page 15]
|
|||
|
|
|||
|
|
|||
|
|
|||
|
November 1981 RFC 788
|
|||
|
Simple Mail Transfer Protocol
|
|||
|
|
|||
|
|
|||
|
|
|||
|
4. THE SMTP SPECIFICATIONS
|
|||
|
|
|||
|
4.1. SMTP COMMANDS
|
|||
|
|
|||
|
4.1.1. COMMAND SEMANTICS
|
|||
|
|
|||
|
The SMTP commands define the mail transfer or the mail system
|
|||
|
function requested by the user. SMTP commands are character
|
|||
|
strings terminated by <CRLF>. The command codes themselves are
|
|||
|
alphabetic characters terminated by <SP> if parameters follow
|
|||
|
and <CRLF> otherwise. The syntax of mailboxes must conform to
|
|||
|
receiver site conventions. The SMTP commands are discussed
|
|||
|
below. The SMTP replies are discussed in the Section 4.2.
|
|||
|
|
|||
|
A mail transaction involves several data objects which are
|
|||
|
communicated as arguments to different commands. The
|
|||
|
reverse-path is the argument of the MAIL command, the
|
|||
|
forward-path is the argument of the RCPT command, and the mail
|
|||
|
data is the argument of the DATA command. These arguments or
|
|||
|
data objects must be transmitted and held pending the
|
|||
|
confirmation communicated by the end of mail data indication
|
|||
|
which finalizes the transaction. The model for this is that
|
|||
|
distinct buffers are provided to hold the types of data
|
|||
|
objects, that is, there is a reverse-path buffer, a
|
|||
|
forward-path buffer, and a mail data buffer. Specific commands
|
|||
|
cause information to be appended to a specific buffer, or cause
|
|||
|
one or more buffers to be cleared.
|
|||
|
|
|||
|
HELLO (HELO)
|
|||
|
|
|||
|
This command is used to identify the sender-SMTP to the
|
|||
|
receiver-SMTP. The argument field contains the host name of
|
|||
|
the sender-SMTP.
|
|||
|
|
|||
|
The receiver-SMTP identifies itself to the sender-SMTP in
|
|||
|
the connection greeting reply, and in the response to this
|
|||
|
command.
|
|||
|
|
|||
|
MAIL (MAIL)
|
|||
|
|
|||
|
This command is used to initiate a mail transaction in which
|
|||
|
the mail data is delivered to one or more mailboxes. The
|
|||
|
argument field contains a reverse-path.
|
|||
|
|
|||
|
The reverse-path consists of an optional list of hosts and
|
|||
|
the sender mailbox. When the list of hosts is present, it
|
|||
|
|
|||
|
|
|||
|
|
|||
|
[Page 16] Postel
|
|||
|
|
|||
|
|
|||
|
|
|||
|
RFC 788 November 1981
|
|||
|
Simple Mail Transfer Protocol
|
|||
|
|
|||
|
|
|||
|
|
|||
|
is a "reverse" source route and indicates that the mail was
|
|||
|
relayed through each host on the list (the first host in the
|
|||
|
list was the most recent relay). This list is used as a
|
|||
|
source route to return non-delivery notices to the sender.
|
|||
|
As each relay host adds itself to the beginning of the list,
|
|||
|
it must use its name as known in the IPCE to which it is
|
|||
|
relaying the mail rather than the IPCE from which the mail
|
|||
|
came (if they are different). In some types of error
|
|||
|
reporting messages (for example, undeliverable mail
|
|||
|
notifications) the reverse-path may be null (see Example 7).
|
|||
|
|
|||
|
This command clears the reverse-path buffer, the
|
|||
|
forward-path buffer, and the mail data buffer; and inserts
|
|||
|
the reverse-path information from this command into the
|
|||
|
reverse-path buffer.
|
|||
|
|
|||
|
RECIPIENT (RCPT)
|
|||
|
|
|||
|
This command is used to identify an individual recipient of
|
|||
|
the mail data; multiple recipients are specified by multiple
|
|||
|
use of this command.
|
|||
|
|
|||
|
The forward-path consists of an optional list of hosts and a
|
|||
|
required destination mailbox. When the list of hosts is
|
|||
|
present, it is a source route and indicates that the mail
|
|||
|
must be relayed to the next host on the list. If the
|
|||
|
receiver-SMTP is does not implement the relay function it
|
|||
|
may user the same reply it would for an unknown local user
|
|||
|
(550).
|
|||
|
|
|||
|
When mail is relayed, the relay host must remove itself from
|
|||
|
the beginning forward-path and put itself at the beginning
|
|||
|
of the reverse-path. When mail reaches its ultimate
|
|||
|
destination (the forward-path contains only a destination
|
|||
|
mailbox), the receiver-SMTP inserts it into the destination
|
|||
|
mailbox in accordance with its host mail conventions.
|
|||
|
|
|||
|
For example, mail received at relay host A with arguments
|
|||
|
|
|||
|
FROM:<X@Y>
|
|||
|
TO:<@A,@B,C@D>
|
|||
|
|
|||
|
will be relayed on to host B with arguments
|
|||
|
|
|||
|
FROM:<@A,X@Y>
|
|||
|
TO:<@B,C@D>.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Postel [Page 17]
|
|||
|
|
|||
|
|
|||
|
|
|||
|
November 1981 RFC 788
|
|||
|
Simple Mail Transfer Protocol
|
|||
|
|
|||
|
|
|||
|
|
|||
|
This command causes its forward-path argument to be appended
|
|||
|
to the forward-path buffer.
|
|||
|
|
|||
|
DATA (DATA)
|
|||
|
|
|||
|
The receiver treats the lines following the command as mail
|
|||
|
data from the sender. This command causes the mail data
|
|||
|
from this command to be appended to the mail data buffer.
|
|||
|
The mail data may contain any of the 128 ASCII character
|
|||
|
codes.
|
|||
|
|
|||
|
The mail data is terminated by a line containing only a
|
|||
|
period, that is the character sequence "<CRLF>.<CRLF>" (see
|
|||
|
Section 4.5.2 on Transparency). This is the end of mail
|
|||
|
data indication.
|
|||
|
|
|||
|
The end of mail data indication requires that the receiver
|
|||
|
must now process the stored mail transaction information.
|
|||
|
This processing consumes the information in the reverse-path
|
|||
|
buffer, the forward-path buffer, and the mail data buffer,
|
|||
|
and on the completion of this command these buffers are
|
|||
|
cleared. If the processing is successful the receiver must
|
|||
|
send an OK reply. If the processing fails completely the
|
|||
|
receiver must send a failure reply.
|
|||
|
|
|||
|
When the receiver-SMTP accepts a message either for relaying
|
|||
|
or for final delivery it inserts at the beginning of the
|
|||
|
mail data a time stamp line. The time stamp line indicates
|
|||
|
the identity of the host that sent the message, and the
|
|||
|
identity of the host that received the message (and is
|
|||
|
inserting this time stamp), and the date and time the
|
|||
|
message was received. Relayed messages will have multiple
|
|||
|
time stamp lines.
|
|||
|
|
|||
|
When the receiver-SMTP makes the "final delivery" of a
|
|||
|
message it inserts at the beginning of the mail data a
|
|||
|
return path line. The return path line preserves the
|
|||
|
information in the <reverse-path> from the MAIL command.
|
|||
|
Here, final delivery means the message leaves the SMTP
|
|||
|
world. Normally, this would mean it has been delivered to
|
|||
|
the destination user, but in some cases it may be further
|
|||
|
processed and transmitted by another mail system.
|
|||
|
|
|||
|
The preceding two paragraphs imply that the final mail data
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
[Page 18] Postel
|
|||
|
|
|||
|
|
|||
|
|
|||
|
RFC 788 November 1981
|
|||
|
Simple Mail Transfer Protocol
|
|||
|
|
|||
|
|
|||
|
|
|||
|
will begin with a return path line, followed by one or more
|
|||
|
time stamp lines. These lines will be followed by the mail
|
|||
|
data header and body [2]. For example:
|
|||
|
|
|||
|
Return-Path: <@GHI,@DEF,@ABC,JOE@ABC>
|
|||
|
Mail-From: GHI received by JKL at 27-Oct-81 15:27:39-PST
|
|||
|
Mail-From: DEF received by GHI at 27-Oct-81 15:15:13-PST
|
|||
|
Mail-From: ABC received by DEF at 27-Oct-81 15:01:59-PST
|
|||
|
Date: 27-Oct-81 15:01:01-PST
|
|||
|
From: JOE@ABC
|
|||
|
Subject: Improved Mailing System Installed
|
|||
|
To: SAM@JKL
|
|||
|
|
|||
|
This is to inform you that ...
|
|||
|
|
|||
|
Special mention is needed of the response and further action
|
|||
|
required when the processing following the end of mail data
|
|||
|
indication is partially successful. This could arise if
|
|||
|
after accepting several recipients and the mail data, the
|
|||
|
receiver-SMTP finds that the mail data can be successfully
|
|||
|
delivered to some of the recipients, but it cannot be to
|
|||
|
others (for example, due to mailbox space allocation
|
|||
|
problems). In such a situation, the response to the DATA
|
|||
|
command must be an OK reply. But, the receiver-SMTP must
|
|||
|
compose and send an "undeliverable mail" notification
|
|||
|
message to the originator of the message. Either a single
|
|||
|
notification which lists all of the recipients that failed
|
|||
|
to get the message, or separate notification messages must
|
|||
|
be sent for each failed recipient (see Example 7). All
|
|||
|
undeliverable mail notification messages are sent using the
|
|||
|
MAIL command (even if they result from processing a SEND,
|
|||
|
SOML, or SAML command).
|
|||
|
|
|||
|
SEND (SEND)
|
|||
|
|
|||
|
This command is used to initiate a mail transaction in which
|
|||
|
the mail data is delivered to one or more terminals. The
|
|||
|
argument field contains a reverse-path. This command is
|
|||
|
successful if the message is delivered to the terminal.
|
|||
|
|
|||
|
The reverse-path consists of an optional list of hosts and
|
|||
|
the sender mailbox. When the list of hosts is present, it
|
|||
|
is a "reverse" source route and indicates that the mail was
|
|||
|
relayed through each host on the list (the first host in the
|
|||
|
list was the most recent relay). This list is used as a
|
|||
|
source route to return non-delivery notices to the sender.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Postel [Page 19]
|
|||
|
|
|||
|
|
|||
|
|
|||
|
November 1981 RFC 788
|
|||
|
Simple Mail Transfer Protocol
|
|||
|
|
|||
|
|
|||
|
|
|||
|
As each relay host adds itself to the beginning of the list,
|
|||
|
it must use its name as known in the IPCE to which it is
|
|||
|
relaying the mail rather than the IPCE from which the mail
|
|||
|
came (if they are different).
|
|||
|
|
|||
|
This command clears the reverse-path buffer, the
|
|||
|
forward-path buffer, and the mail data buffer; and inserts
|
|||
|
the reverse-path information from this command into the
|
|||
|
reverse-path buffer.
|
|||
|
|
|||
|
SEND OR MAIL (SOML)
|
|||
|
|
|||
|
This command is used to initiate a mail transaction in which
|
|||
|
the mail data is delivered to one or more terminals or
|
|||
|
mailboxes. For each recipient the mail data is delivered to
|
|||
|
the recipient's terminal if the recipient is active on the
|
|||
|
host (and accepting terminal messages), otherwise to the
|
|||
|
recipient's mailbox. The argument field contains a
|
|||
|
reverse-path. This command is successful if the message is
|
|||
|
delivered to the terminal or the mailbox.
|
|||
|
|
|||
|
The reverse-path consists of an optional list of hosts and
|
|||
|
the sender mailbox. When the list of hosts is present, it
|
|||
|
is a "reverse" source route and indicates that the mail was
|
|||
|
relayed through each host on the list (the first host in the
|
|||
|
list was the most recent relay). This list is used as a
|
|||
|
source route to return non-delivery notices to the sender.
|
|||
|
As each relay host adds itself to the beginning of the list,
|
|||
|
it must use its name as known in the IPCE to which it is
|
|||
|
relaying the mail rather than the IPCE from which the mail
|
|||
|
came (if they are different).
|
|||
|
|
|||
|
This command clears the reverse-path buffer, the
|
|||
|
forward-path buffer, and the mail data buffer; and inserts
|
|||
|
the reverse-path information from this command into the
|
|||
|
reverse-path buffer.
|
|||
|
|
|||
|
SEND AND MAIL (SAML)
|
|||
|
|
|||
|
This command is used to initiate a mail transaction in which
|
|||
|
the mail data is delivered to one or more terminals and
|
|||
|
mailboxes. For each recipient the mail data is delivered to
|
|||
|
the recipient's terminal if the recipient is active on the
|
|||
|
host (and accepting terminal messages), and for all
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
[Page 20] Postel
|
|||
|
|
|||
|
|
|||
|
|
|||
|
RFC 788 November 1981
|
|||
|
Simple Mail Transfer Protocol
|
|||
|
|
|||
|
|
|||
|
|
|||
|
recipients to the recipient's mailbox. The argument field
|
|||
|
contains a reverse-path. This command is successful if the
|
|||
|
message is delivered to the mailbox.
|
|||
|
|
|||
|
The reverse-path consists of an optional list of hosts and
|
|||
|
the sender mailbox. When the list of hosts is present, it
|
|||
|
is a "reverse" source route and indicates that the mail was
|
|||
|
relayed through each host on the list (the first host in the
|
|||
|
list was the most recent relay). This list is used as a
|
|||
|
source route to return non-delivery notices to the sender.
|
|||
|
As each relay host adds itself to the beginning of the list,
|
|||
|
it must use its name as known in the IPCE to which it is
|
|||
|
relaying the mail rather than the IPCE from which the mail
|
|||
|
came (if they are different).
|
|||
|
|
|||
|
This command clears the reverse-path buffer, the
|
|||
|
forward-path buffer, and the mail data buffer; and inserts
|
|||
|
the reverse-path information from this command into the
|
|||
|
reverse-path buffer.
|
|||
|
|
|||
|
RESET (RSET)
|
|||
|
|
|||
|
This command specifies that the current mail transaction is
|
|||
|
to be aborted. Any stored sender, recipients, and mail data
|
|||
|
must be discarded, and all buffers and state tables cleared.
|
|||
|
The receiver must send an OK reply.
|
|||
|
|
|||
|
VERIFY (VRFY)
|
|||
|
|
|||
|
This command asks the receiver to confirm that the argument
|
|||
|
identifies a user. If it is a user name, the full name of
|
|||
|
the user (if known) and the fully specified mailbox are
|
|||
|
returned.
|
|||
|
|
|||
|
This command has no effect on any of the reverse-path
|
|||
|
buffer, the forward-path buffer, or the mail data buffer.
|
|||
|
|
|||
|
EXPAND (EXPN)
|
|||
|
|
|||
|
This command asks the receiver to confirm that the argument
|
|||
|
identifies a mailing list, and if so, to return the
|
|||
|
membership of that list. The full name of the users (if
|
|||
|
known) and the fully specified mailboxes are returned in a
|
|||
|
multiline reply.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Postel [Page 21]
|
|||
|
|
|||
|
|
|||
|
|
|||
|
November 1981 RFC 788
|
|||
|
Simple Mail Transfer Protocol
|
|||
|
|
|||
|
|
|||
|
|
|||
|
This command has no effect on any of the reverse-path
|
|||
|
buffer, the forward-path buffer, or the mail data buffer.
|
|||
|
|
|||
|
HELP (HELP)
|
|||
|
|
|||
|
This command causes the receiver to send helpful information
|
|||
|
to the sender of the HELP command. The command may take an
|
|||
|
argument (e.g., any command name) and return more specific
|
|||
|
information as a response.
|
|||
|
|
|||
|
This command has no effect on any of the reverse-path
|
|||
|
buffer, the forward-path buffer, or the mail data buffer.
|
|||
|
|
|||
|
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.
|
|||
|
|
|||
|
This command has no effect on any of the reverse-path
|
|||
|
buffer, the forward-path buffer, or the mail data buffer.
|
|||
|
|
|||
|
QUIT (QUIT)
|
|||
|
|
|||
|
This command specifies that the receiver must send an OK
|
|||
|
reply, and then close the transmission channel.
|
|||
|
|
|||
|
The receiver should not close the transmission channel until
|
|||
|
it receives and replies to a QUIT command (even if there was
|
|||
|
an error). The sender should not close the transmission
|
|||
|
channel until it send a QUIT command and receives the reply
|
|||
|
(even if there was an error response to a previous command).
|
|||
|
If the connection is closed prematurely the receiver should
|
|||
|
act as if a RSET command had been received (canceling any
|
|||
|
pending transaction, but not undoing any previously
|
|||
|
completed transaction), the sender should act as if the
|
|||
|
command or transaction in progress had received a temporary
|
|||
|
error (4xx).
|
|||
|
|
|||
|
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.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
[Page 22] Postel
|
|||
|
|
|||
|
|
|||
|
|
|||
|
RFC 788 November 1981
|
|||
|
Simple Mail Transfer Protocol
|
|||
|
|
|||
|
|
|||
|
|
|||
|
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.
|
|||
|
|
|||
|
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".
|
|||
|
|
|||
|
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.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Postel [Page 23]
|
|||
|
|
|||
|
|
|||
|
|
|||
|
November 1981 RFC 788
|
|||
|
Simple Mail Transfer Protocol
|
|||
|
|
|||
|
|
|||
|
|
|||
|
The following are the SMTP commands:
|
|||
|
|
|||
|
HELO <SP> <host> <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>
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
[Page 24] Postel
|
|||
|
|
|||
|
|
|||
|
|
|||
|
RFC 788 November 1981
|
|||
|
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> ::= "<" ["@" <host> "," ...] <mailbox> ">"
|
|||
|
|
|||
|
<host> ::= <a> <string> | "#" <number> | "[" <dotnum> "]"
|
|||
|
|
|||
|
<mailbox> ::= <user> "@" <host>
|
|||
|
|
|||
|
<user> ::= <string>
|
|||
|
|
|||
|
<string> ::= <char> | <char> <string>
|
|||
|
|
|||
|
<char> ::= <c> | '\' <c> | '\' <s>
|
|||
|
|
|||
|
<dotnum> ::= <snum> "." <snum> "." <snum> "." <snum>
|
|||
|
|
|||
|
<number> ::= <d> | <d> <number>
|
|||
|
|
|||
|
<snum> ::= 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 except
|
|||
|
<specials>
|
|||
|
|
|||
|
<d> ::= any one of the ten digits 0 through 9
|
|||
|
|
|||
|
<s> ::= any one of <specials>
|
|||
|
|
|||
|
<specials> ::= '<', '>', '(', ')', '\', ',', ';', ':', '@',
|
|||
|
'"', and the control characters (ASCII codes 0 through 37
|
|||
|
octal inclusive and 177 octal)
|
|||
|
|
|||
|
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.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Postel [Page 25]
|
|||
|
|
|||
|
|
|||
|
|
|||
|
November 1981 RFC 788
|
|||
|
Simple Mail Transfer Protocol
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Hosts are generally known by names which are translated to
|
|||
|
addresses in each host. 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.
|
|||
|
|
|||
|
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> ::= "Mail-From:" <SP> <stamp> <CRLF>
|
|||
|
|
|||
|
<stamp> ::= [<ptcl>] <from-host> <this-host> <daytime>
|
|||
|
|
|||
|
<ptcl> ::= <protocol> <SP> "host" <SP>
|
|||
|
|
|||
|
<from-host> ::= <host> <SP>
|
|||
|
|
|||
|
<this-host> ::= "received by" <SP> <host> <SP>
|
|||
|
|
|||
|
<protocol> ::= "TCP" | "NCP" | "NITS" | "X25" | "INTERNET" |
|
|||
|
"ARPANET"
|
|||
|
|
|||
|
Note: INTERNET = TCP, ARPANET = NCP, and if the <ptcl> is
|
|||
|
not present INTERNET is assumed.
|
|||
|
|
|||
|
<daytime> ::= "at" <SP> <date> <SP> <time>
|
|||
|
|
|||
|
<date> ::= <dd> "-" <mon> "-" <yy>
|
|||
|
|
|||
|
<time> ::= <hh> ":" <mm> ":" <ss> "-" <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 01 to 99.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
[Page 26] Postel
|
|||
|
|
|||
|
|
|||
|
|
|||
|
RFC 788 November 1981
|
|||
|
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> ::= a time zone designator (as in [2]) or "UT" for
|
|||
|
Universal Time (the default).
|
|||
|
|
|||
|
Return Path Example:
|
|||
|
|
|||
|
Return-Path: <@CHARLIE,@BAKER,JOE@ABLE>
|
|||
|
|
|||
|
Mail From Example:
|
|||
|
|
|||
|
Mail-From: ABC received by XYZ at 22-OCT-81 09:23:59-PDT
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Postel [Page 27]
|
|||
|
|
|||
|
|
|||
|
|
|||
|
November 1981 RFC 788
|
|||
|
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, so there are likely to be varying texts
|
|||
|
for each reply code. A discussion of the theory of reply codes is
|
|||
|
given in the 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 command are expected to result in multiline replies in
|
|||
|
normal circumstances, however multiline replies are allowed for
|
|||
|
any command.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
[Page 28] Postel
|
|||
|
|
|||
|
|
|||
|
|
|||
|
RFC 788 November 1981
|
|||
|
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 <host> Service ready
|
|||
|
221 <host> Service closing transmission channel
|
|||
|
421 <host> 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 29]
|
|||
|
|
|||
|
|
|||
|
|
|||
|
November 1981 RFC 788
|
|||
|
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 <host> Service ready
|
|||
|
221 <host> 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 <host> 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 30] Postel
|
|||
|
|
|||
|
|
|||
|
|
|||
|
RFC 788 November 1981
|
|||
|
Simple Mail Transfer Protocol
|
|||
|
|
|||
|
|
|||
|
|
|||
|
4.3. SEQUENCING OF COMMANDS AND REPLIES
|
|||
|
|
|||
|
The communication between the sender and receiver is intended to
|
|||
|
be an alternating dialogue, controlled by the sender. As such,
|
|||
|
the sender issues a command and the receiver responds with a
|
|||
|
reply. The sender must wait for this response before sending
|
|||
|
further commands.
|
|||
|
|
|||
|
One important reply is the connection greeting. Normally, a
|
|||
|
receiver will send a 220 "Awaiting input" reply when the
|
|||
|
connection is completed. The sender should wait for this greeting
|
|||
|
message before sending any commands.
|
|||
|
|
|||
|
Note: all the greeting type replies have the official name of
|
|||
|
the server host as the first word following the reply code.
|
|||
|
|
|||
|
For example,
|
|||
|
|
|||
|
220 <SP> USC-ISIF <SP> Service ready <CRLF>
|
|||
|
|
|||
|
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
|
|||
|
|
|||
|
Each command is listed with its possible replies. The prefixes
|
|||
|
used before the possible replies are "P" for preliminary (not
|
|||
|
used in SMTP), "I" for intermediate, "S" for success, "F" for
|
|||
|
failure, and "E" for error. The 421 reply (service not
|
|||
|
available, closing transmission channel) may be given to any
|
|||
|
command if the SMTP-receiver knows it must shut down. This
|
|||
|
listing forms the basis for the State Diagrams in Section 4.4.
|
|||
|
|
|||
|
CONNECTION ESTABLISHMENT
|
|||
|
S: 220
|
|||
|
F: 421
|
|||
|
HELO
|
|||
|
S: 250
|
|||
|
E: 500, 501, 504, 421
|
|||
|
MAIL
|
|||
|
S: 250
|
|||
|
F: 552, 451, 452
|
|||
|
E: 500, 501, 421
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Postel [Page 31]
|
|||
|
|
|||
|
|
|||
|
|
|||
|
November 1981 RFC 788
|
|||
|
Simple Mail Transfer Protocol
|
|||
|
|
|||
|
|
|||
|
|
|||
|
RCPT
|
|||
|
S: 250, 251
|
|||
|
F: 550, 551, 552, 553, 450, 451, 452
|
|||
|
E: 500, 501, 421
|
|||
|
DATA
|
|||
|
I: 354 -> data -> S: 250
|
|||
|
F: 552, 554, 451, 452
|
|||
|
F: 451, 554
|
|||
|
E: 500, 501, 421
|
|||
|
RSET
|
|||
|
S: 250
|
|||
|
E: 500, 501, 504, 421
|
|||
|
SEND
|
|||
|
S: 250
|
|||
|
F: 552, 451, 452
|
|||
|
E: 500, 501, 502, 421
|
|||
|
SOML
|
|||
|
S: 250
|
|||
|
F: 552, 451, 452
|
|||
|
E: 500, 501, 502, 421
|
|||
|
SAML
|
|||
|
S: 250
|
|||
|
F: 552, 451, 452
|
|||
|
E: 500, 501, 502, 421
|
|||
|
VRFY
|
|||
|
S: 250
|
|||
|
F: 550
|
|||
|
E: 500, 501, 502, 504, 421
|
|||
|
EXPN
|
|||
|
S: 250
|
|||
|
F: 550
|
|||
|
E: 500, 501, 502, 504, 421
|
|||
|
HELP
|
|||
|
S: 211, 214
|
|||
|
E: 500, 501, 502, 504, 421
|
|||
|
NOOP
|
|||
|
S: 250
|
|||
|
E: 500, 421
|
|||
|
QUIT
|
|||
|
S: 221
|
|||
|
E: 500
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
[Page 32] Postel
|
|||
|
|
|||
|
|
|||
|
|
|||
|
RFC 788 November 1981
|
|||
|
Simple Mail Transfer Protocol
|
|||
|
|
|||
|
|
|||
|
|
|||
|
4.4. STATE DIAGRAMS
|
|||
|
|
|||
|
Following are state diagrams for a simple-minded SMTP
|
|||
|
implementation. Only the first digit of the reply codes is used.
|
|||
|
There is one state diagram for each group of SMTP commands. 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".
|
|||
|
|
|||
|
First, the diagram that represents most of the SMTP commands:
|
|||
|
|
|||
|
|
|||
|
1,3 +---+
|
|||
|
----------->| E |
|
|||
|
| +---+
|
|||
|
|
|
|||
|
+---+ cmd +---+ 2 +---+
|
|||
|
| B |---------->| W |---------->| S |
|
|||
|
+---+ +---+ +---+
|
|||
|
|
|
|||
|
| 4,5 +---+
|
|||
|
----------->| F |
|
|||
|
+---+
|
|||
|
|
|||
|
|
|||
|
This diagram models the commands:
|
|||
|
|
|||
|
HELO, MAIL, RCPT, RSET, SEND, SOML, SAML, VRFY, EXPN, HELP,
|
|||
|
NOOP, QUIT.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Postel [Page 33]
|
|||
|
|
|||
|
|
|||
|
|
|||
|
November 1981 RFC 788
|
|||
|
Simple Mail Transfer Protocol
|
|||
|
|
|||
|
|
|||
|
|
|||
|
A more complex diagram models the DATA command:
|
|||
|
|
|||
|
|
|||
|
+---+ DATA +---+ 1,2 +---+
|
|||
|
| B |---------->| W |-------------------->| E |
|
|||
|
+---+ +---+ ------------>+---+
|
|||
|
3| |4,5 |
|
|||
|
| | |
|
|||
|
-------------- ----- |
|
|||
|
| | | +---+
|
|||
|
| ---------- -------->| S |
|
|||
|
| | | | +---+
|
|||
|
| | ------------
|
|||
|
| | | |
|
|||
|
V 1,3| |2 |
|
|||
|
+---+ data +---+ --------------->+---+
|
|||
|
| |---------->| W | | F |
|
|||
|
+---+ +---+-------------------->+---+
|
|||
|
4,5
|
|||
|
|
|||
|
|
|||
|
Note that the "data" here is a series of lines sent from the
|
|||
|
sender to the receiver with no response expected until the last
|
|||
|
line is sent.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
[Page 34] Postel
|
|||
|
|
|||
|
|
|||
|
|
|||
|
RFC 788 November 1981
|
|||
|
Simple Mail Transfer Protocol
|
|||
|
|
|||
|
|
|||
|
|
|||
|
4.5. DETAILS
|
|||
|
|
|||
|
4.5.1. MINIMUM IMPLEMENTATION
|
|||
|
|
|||
|
In order to make SMTP workable, the following minimum
|
|||
|
implementation is required for all receivers:
|
|||
|
|
|||
|
COMMANDS -- HELO
|
|||
|
MAIL
|
|||
|
RCPT
|
|||
|
DATA
|
|||
|
RSET
|
|||
|
NOOP
|
|||
|
QUIT
|
|||
|
|
|||
|
4.5.2. TRANSPARENCY
|
|||
|
|
|||
|
Without some provision for data transparency the character
|
|||
|
sequence "<CRLF>.<CRLF>" ends the the mail text and cannot be
|
|||
|
sent by the user. In general, users are not aware of such
|
|||
|
"forbidden" sequences. To allow all user composed text to be
|
|||
|
transmitted transparently the following procedures are used.
|
|||
|
|
|||
|
1. Before sending a line of mail text the sender-SMTP checks
|
|||
|
the first character of the line. If it is a period, one
|
|||
|
additional period is inserted at the beginning of the line.
|
|||
|
|
|||
|
2. When a line of mail text is received by the receiver-SMTP
|
|||
|
it checks the the line. If the line is composed of a single
|
|||
|
period it is the end of mail. If the first character is a
|
|||
|
period and there are other characters on the line, the first
|
|||
|
character is deleted.
|
|||
|
|
|||
|
The mail data may contain any of the 128 ASCII characters. All
|
|||
|
characters are to be delivered to the recipients mailbox
|
|||
|
including format effectors and other control characters. The
|
|||
|
7-bit ASCII codes are transmitted right justified in 8-bit
|
|||
|
bytes (octets) with the high order bits cleared to zero.
|
|||
|
|
|||
|
In some systems it may be necessary to transform the data as
|
|||
|
it is received and stored. This may be necessary for hosts
|
|||
|
that use a different character set than ASCII as their local
|
|||
|
character set, or that store data in records rather than
|
|||
|
strings. If such transforms are necessary, they must be
|
|||
|
reversible -- especially if such transforms are applied to
|
|||
|
mail being relayed.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Postel [Page 35]
|
|||
|
|
|||
|
|
|||
|
|
|||
|
November 1981 RFC 788
|
|||
|
Simple Mail Transfer Protocol
|
|||
|
|
|||
|
|
|||
|
|
|||
|
4.5.3. SIZES
|
|||
|
|
|||
|
There are several objects that have required minimum maximum
|
|||
|
sizes. That is every implementation must be able to receive
|
|||
|
objects of at least these sizes, but must not send objects
|
|||
|
larger than these sizes.
|
|||
|
|
|||
|
|
|||
|
****************************************************
|
|||
|
* *
|
|||
|
* TO THE MAXIMUM EXTENT POSSIBLE, IMPLEMENTATION *
|
|||
|
* TECHNIQUES WHICH IMPOSE NO LIMITS ON THE LENGTH *
|
|||
|
* OF THESE OBJECTS SHOULD BE USED. *
|
|||
|
* *
|
|||
|
****************************************************
|
|||
|
|
|||
|
user
|
|||
|
|
|||
|
The maximum total length of a user name is 64 characters.
|
|||
|
|
|||
|
host
|
|||
|
|
|||
|
The maximum total length of a host name or number is 40
|
|||
|
characters.
|
|||
|
|
|||
|
path
|
|||
|
|
|||
|
The maximum total length of a reverse-path or
|
|||
|
forward-path is 256 characters (including the punctuation
|
|||
|
and element separators).
|
|||
|
|
|||
|
command line
|
|||
|
|
|||
|
The maximum total length of a command line including the
|
|||
|
command word and the <CRLF> is 512 characters.
|
|||
|
|
|||
|
reply line
|
|||
|
|
|||
|
The maximum total length of a reply line including the
|
|||
|
reply code and the <CRLF> is 512 characters.
|
|||
|
|
|||
|
text line
|
|||
|
|
|||
|
The maximum total length of a text line including the
|
|||
|
<CRLF> is 1000 characters (but not counting the leading
|
|||
|
dot duplicated for transparency).
|
|||
|
|
|||
|
|
|||
|
|
|||
|
[Page 36] Postel
|
|||
|
|
|||
|
|
|||
|
|
|||
|
RFC 788 November 1981
|
|||
|
Simple Mail Transfer Protocol
|
|||
|
|
|||
|
|
|||
|
|
|||
|
recipients buffer
|
|||
|
|
|||
|
The maximum total number of recipients that must be
|
|||
|
buffered is 100 recipients.
|
|||
|
|
|||
|
|
|||
|
****************************************************
|
|||
|
* *
|
|||
|
* TO THE MAXIMUM EXTENT POSSIBLE, IMPLEMENTATION *
|
|||
|
* TECHNIQUES WHICH IMPOSE NO LIMITS ON THE LENGTH *
|
|||
|
* OF THESE OBJECTS SHOULD BE USED. *
|
|||
|
* *
|
|||
|
****************************************************
|
|||
|
|
|||
|
Errors due to exceeding these limits may be reported by using
|
|||
|
the reply codes, for example:
|
|||
|
|
|||
|
500 Line too long.
|
|||
|
|
|||
|
501 Path too long
|
|||
|
|
|||
|
552 Too many recipients.
|
|||
|
|
|||
|
552 Too much mail data.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Postel [Page 37]
|
|||
|
|
|||
|
|
|||
|
|
|||
|
November 1981 RFC 788
|
|||
|
Simple Mail Transfer Protocol
|
|||
|
|
|||
|
|
|||
|
|
|||
|
APPENDIX A
|
|||
|
|
|||
|
TCP Transport service
|
|||
|
|
|||
|
The Transmission Control Protocol [3] is used in the ARPA
|
|||
|
Internet, and in any network following the US DoD standards for
|
|||
|
internetwork protocols.
|
|||
|
|
|||
|
Connection Establishment
|
|||
|
|
|||
|
The SMTP transmission channel is a TCP connection established
|
|||
|
between the sender process port U and the receiver process port
|
|||
|
L. This single full duplex connection is used as the
|
|||
|
transmission channel. This protocol is assigned the service
|
|||
|
port 25 (31 octal), that is L=25.
|
|||
|
|
|||
|
Data Transfer
|
|||
|
|
|||
|
The TCP connection supports the transmission of 8-bit bytes.
|
|||
|
The SMTP data is 7-bit ASCII characters. Each character is
|
|||
|
transmitted as a 8-bit byte with the high-order bit cleared to
|
|||
|
zero.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
[Page 38] Postel
|
|||
|
|
|||
|
|
|||
|
|
|||
|
RFC 788 November 1981
|
|||
|
Simple Mail Transfer Protocol
|
|||
|
|
|||
|
|
|||
|
|
|||
|
APPENDIX B
|
|||
|
|
|||
|
NCP Transport service
|
|||
|
|
|||
|
The ARPANET Host-to-Host Protocol [4] (implemented by the Network
|
|||
|
Control Program) may be used in the ARPANET.
|
|||
|
|
|||
|
Connection Establishment
|
|||
|
|
|||
|
The SMTP transmission channel is established via NCP between
|
|||
|
the the sender process socket U and receiver process socket L.
|
|||
|
The Initial Connection Protocol [5] is followed resulting in a
|
|||
|
pair of simplex connections. This pair of connections is used
|
|||
|
as the transmission channel. This protocol is assigned the
|
|||
|
contact socket 25 (31 octal), that is L=25.
|
|||
|
|
|||
|
Data Transfer
|
|||
|
|
|||
|
The NCP data connections are established in 8-bit byte mode.
|
|||
|
The SMTP data is 7-bit ASCII characters. Each character is
|
|||
|
transmitted as a 8-bit byte with the high-order bit cleared to
|
|||
|
zero.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Postel [Page 39]
|
|||
|
|
|||
|
|
|||
|
|
|||
|
November 1981 RFC 788
|
|||
|
Simple Mail Transfer Protocol
|
|||
|
|
|||
|
|
|||
|
|
|||
|
APPENDIX C
|
|||
|
|
|||
|
NITS
|
|||
|
|
|||
|
The Network Independent Transport Service [6] may be used.
|
|||
|
|
|||
|
Connection Establishment
|
|||
|
|
|||
|
The SMTP transmission channel is established via NITS between
|
|||
|
the sender process and receiver process. The sender process
|
|||
|
executes the CONNECT primitive, and the waiting receiver
|
|||
|
process executes the ACCEPT primitive.
|
|||
|
|
|||
|
Data Transfer
|
|||
|
|
|||
|
The NITS connection supports the transmission of 8-bit bytes.
|
|||
|
The SMTP data is 7-bit ASCII characters. Each character is
|
|||
|
transmitted as a 8-bit byte with the high-order bit cleared to
|
|||
|
zero.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
[Page 40] Postel
|
|||
|
|
|||
|
|
|||
|
|
|||
|
RFC 788 November 1981
|
|||
|
Simple Mail Transfer Protocol
|
|||
|
|
|||
|
|
|||
|
|
|||
|
APPENDIX D
|
|||
|
|
|||
|
X.25 Transport service
|
|||
|
|
|||
|
It may be possible to use the X.25 service [7] as provided by the
|
|||
|
Public Data Networks directly, but there are indications that it
|
|||
|
is too error prone to qualify as a reliable channel. It is
|
|||
|
suggested that a reliable end-to-end protocol such as TCP be used
|
|||
|
on top of X.25 connections.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Postel [Page 41]
|
|||
|
|
|||
|
|
|||
|
|
|||
|
November 1981 RFC 788
|
|||
|
Simple Mail Transfer Protocol
|
|||
|
|
|||
|
|
|||
|
|
|||
|
APPENDIX E
|
|||
|
|
|||
|
Theory of Reply Codes
|
|||
|
|
|||
|
The three digits of the reply each have a special significance.
|
|||
|
The first digit denotes whether the response is good, bad or
|
|||
|
incomplete. An unsophisticated sender-SMTP will be able to
|
|||
|
determine its next action (proceed as planned, redo, retrench,
|
|||
|
etc.) by simply examining this first digit. A sender-SMTP 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 command has been accepted, but the requested action
|
|||
|
is being held in abeyance, pending confirmation of the
|
|||
|
information in this reply. The sender-SMTP should send
|
|||
|
another command specifying whether to continue or abort
|
|||
|
the action.
|
|||
|
|
|||
|
[Note: SMTP does not have any commands that allow this
|
|||
|
type of reply, and so does not have the continue or
|
|||
|
abort commands.]
|
|||
|
|
|||
|
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-SMTP 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
|
|||
|
|
|||
|
|
|||
|
|
|||
|
[Page 42] Postel
|
|||
|
|
|||
|
|
|||
|
|
|||
|
RFC 788 November 1981
|
|||
|
Simple Mail Transfer Protocol
|
|||
|
|
|||
|
|
|||
|
|
|||
|
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- SMTPs) must
|
|||
|
agree on the interpretation. Each reply in this category
|
|||
|
might have a different time value, but the sender-SMTP 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
|
|||
|
and 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-SMTP 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-SMTP 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 the account status).
|
|||
|
|
|||
|
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
|
|||
|
transmission channel.
|
|||
|
|
|||
|
x3z Unspecified as yet.
|
|||
|
|
|||
|
x4z Unspecified as yet.
|
|||
|
|
|||
|
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
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Postel [Page 43]
|
|||
|
|
|||
|
|
|||
|
|
|||
|
November 1981 RFC 788
|
|||
|
Simple Mail Transfer Protocol
|
|||
|
|
|||
|
|
|||
|
|
|||
|
illustrates 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.
|
|||
|
|
|||
|
For example, a command such as NOOP whose successful execution
|
|||
|
does not offer the sender-SMTP any new information will return
|
|||
|
a 250 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.
|
|||
|
|
|||
|
The reply text may be longer than a single line; in these cases
|
|||
|
the complete text must be marked so the sender-SMTP knows when it
|
|||
|
can stop reading the reply. This requires a special format to
|
|||
|
indicate a multiple line reply.
|
|||
|
|
|||
|
The format for multi-line replies requires that every line,
|
|||
|
except the last, begin with the reply code, followed
|
|||
|
immediately by a hyphen, "-" (also known as minus), followed by
|
|||
|
text. The last line will begin with the reply code, followed
|
|||
|
immediately by <SP>, optionally some text, and <CRLF>.
|
|||
|
|
|||
|
For example:
|
|||
|
123-First line
|
|||
|
123-Second line
|
|||
|
123-234 text beginning with numbers
|
|||
|
123 The last line
|
|||
|
|
|||
|
The sender-SMTP then simply needs to search for the reply code
|
|||
|
followed by <SP> at the beginning of a line, and ignore all
|
|||
|
preceding lines.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
[Page 44] Postel
|
|||
|
|
|||
|
|
|||
|
|
|||
|
RFC 788 November 1981
|
|||
|
Simple Mail Transfer Protocol
|
|||
|
|
|||
|
|
|||
|
|
|||
|
APPENDIX F
|
|||
|
|
|||
|
Scenarios
|
|||
|
|
|||
|
This section presents complete scenarios of several types of SMTP
|
|||
|
sessions.
|
|||
|
|
|||
|
A Typical SMTP Transaction Scenario
|
|||
|
|
|||
|
This SMTP example shows mail sent by Smith at host USC-ISIF, to
|
|||
|
Jones, Green, and Brown at host BBN-UNIX. Here we assume that
|
|||
|
host USC-ISIF contacts host BBN-UNIX directly. The mail is
|
|||
|
accepted for Jones and Brown. Green does not have a mailbox at
|
|||
|
host BBN-UNIX.
|
|||
|
|
|||
|
-------------------------------------------------------------
|
|||
|
|
|||
|
R: 220 BBN-UNIX Simple Mail Transfer Service Ready
|
|||
|
S: HELO USC-ISIF
|
|||
|
R: 250 BBN-UNIX
|
|||
|
|
|||
|
S: MAIL FROM:<Smith@USC-ISIF>
|
|||
|
R: 250 OK
|
|||
|
|
|||
|
S: RCPT TO:<Jones@BBN-UNIX>
|
|||
|
R: 250 OK
|
|||
|
|
|||
|
S: RCPT TO:<Green@BBN-UNIX>
|
|||
|
R: 550 No such user here
|
|||
|
|
|||
|
S: RCPT TO:<Brown@BBN-UNIX>
|
|||
|
R: 250 OK
|
|||
|
|
|||
|
S: DATA
|
|||
|
R: 354 Start mail input; end with <CRLF>.<CRLF>
|
|||
|
S: Blah blah blah...
|
|||
|
S: ...etc. etc. etc.
|
|||
|
S: .
|
|||
|
R: 250 OK
|
|||
|
|
|||
|
S: QUIT
|
|||
|
R: 221 BBN-UNIX Service closing transmission channel
|
|||
|
|
|||
|
Scenario 1
|
|||
|
|
|||
|
-------------------------------------------------------------
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Postel [Page 45]
|
|||
|
|
|||
|
|
|||
|
|
|||
|
November 1981 RFC 788
|
|||
|
Simple Mail Transfer Protocol
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Aborted SMTP Transaction Scenario
|
|||
|
|
|||
|
-------------------------------------------------------------
|
|||
|
|
|||
|
R: 220 MIT-Multics Simple Mail Transfer Service Ready
|
|||
|
S: HELO ISI-VAXA
|
|||
|
R: 250 MIT-Multics
|
|||
|
|
|||
|
S: MAIL FROM:<Smith@ISI-VAXA>
|
|||
|
R: 250 OK
|
|||
|
|
|||
|
S: RCPT TO:<Jones@MIT-Multics>
|
|||
|
R: 250 OK
|
|||
|
|
|||
|
S: RCPT TO:<Green@MIT-Multics>
|
|||
|
R: 550 No such user here
|
|||
|
|
|||
|
S: RSET
|
|||
|
R: 250 OK
|
|||
|
|
|||
|
S: QUIT
|
|||
|
R: 221 MIT-Multics Service closing transmission channel
|
|||
|
|
|||
|
Scenario 2
|
|||
|
|
|||
|
-------------------------------------------------------------
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
[Page 46] Postel
|
|||
|
|
|||
|
|
|||
|
|
|||
|
RFC 788 November 1981
|
|||
|
Simple Mail Transfer Protocol
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Relayed Mail Scenario
|
|||
|
|
|||
|
-------------------------------------------------------------
|
|||
|
|
|||
|
Step 1 -- Source Host to Relay Host
|
|||
|
|
|||
|
R: 220 USC-ISIE Simple Mail Transfer Service Ready
|
|||
|
S: HELO MIT-AI
|
|||
|
R: 250 USC-ISIE
|
|||
|
|
|||
|
S: MAIL FROM:<JQP@MIT-AI>
|
|||
|
R: 250 OK
|
|||
|
|
|||
|
S: RCPT TO:<@ISIE,Jones@BBN-VAX>
|
|||
|
R: 250 OK
|
|||
|
|
|||
|
S: DATA
|
|||
|
R: 354 Start mail input; end with <CRLF>.<CRLF>
|
|||
|
S: Date: 2-Nov-81 22:33:44
|
|||
|
S: From: John Q. Public <JQP at MIT-AI>
|
|||
|
S: Subject: The Next Meeting of the Board
|
|||
|
S: To: Jones at BBN-Vax
|
|||
|
S:
|
|||
|
S: Bill:
|
|||
|
S: The next meeting of the board of directors will be
|
|||
|
S: on Tuesday.
|
|||
|
S: John.
|
|||
|
S: .
|
|||
|
R: 250 OK
|
|||
|
|
|||
|
S: QUIT
|
|||
|
R: 221 USC-ISIE Service closing transmission channel
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Postel [Page 47]
|
|||
|
|
|||
|
|
|||
|
|
|||
|
November 1981 RFC 788
|
|||
|
Simple Mail Transfer Protocol
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Step 2 -- Relay Host to Destination Host
|
|||
|
|
|||
|
R: 220 BBN-VAX Simple Mail Transfer Service Ready
|
|||
|
S: HELO USC-ISIE
|
|||
|
R: 250 BBN-VAX
|
|||
|
|
|||
|
S: MAIL FROM:<@ISIE,JQP@MIT-AI>
|
|||
|
R: 250 OK
|
|||
|
|
|||
|
S: RCPT TO:<Jones@BBN-VAX>
|
|||
|
R: 250 OK
|
|||
|
|
|||
|
S: DATA
|
|||
|
R: 354 Start mail input; end with <CRLF>.<CRLF>
|
|||
|
S: Mail-From: NCP host MIT-AI received by USC-ISIE at
|
|||
|
2-Nov-81 22:40:10
|
|||
|
S: Date: 2-Nov-81 22:33:44
|
|||
|
S: From: John Q. Public <JQP at MIT-AI>
|
|||
|
S: Subject: The Next Meeting of the Board
|
|||
|
S: To: Jones at BBN-Vax
|
|||
|
S:
|
|||
|
S: Bill:
|
|||
|
S: The next meeting of the board of directors will be
|
|||
|
S: on Tuesday.
|
|||
|
S: John.
|
|||
|
S: .
|
|||
|
R: 250 OK
|
|||
|
|
|||
|
S: QUIT
|
|||
|
R: 221 USC-ISIE Service closing transmission channel
|
|||
|
|
|||
|
Scenario 3
|
|||
|
|
|||
|
-------------------------------------------------------------
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
[Page 48] Postel
|
|||
|
|
|||
|
|
|||
|
|
|||
|
RFC 788 November 1981
|
|||
|
Simple Mail Transfer Protocol
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Verifying and Sending Scenario
|
|||
|
|
|||
|
-------------------------------------------------------------
|
|||
|
|
|||
|
R: 220 SU-SCORE Simple Mail Transfer Service Ready
|
|||
|
S: HELO MIT-MC
|
|||
|
R: 250 SU-SCORE
|
|||
|
|
|||
|
S: VRFY Crispin
|
|||
|
R: 250 Mark Crispin <Admin.MRC@SU-SCORE>
|
|||
|
|
|||
|
S: SEND FROM:<EAK@MIT-MC>
|
|||
|
R: 250 OK
|
|||
|
|
|||
|
S: RCPT TO:<Admin.MRC@SU-SCORE>
|
|||
|
R: 250 OK
|
|||
|
|
|||
|
S: DATA
|
|||
|
R: 354 Start mail input; end with <CRLF>.<CRLF>
|
|||
|
S: Blah blah blah...
|
|||
|
S: ...etc. etc. etc.
|
|||
|
S: .
|
|||
|
R: 250 OK
|
|||
|
|
|||
|
S: QUIT
|
|||
|
R: 221 SU-SCORE Service closing transmission channel
|
|||
|
|
|||
|
Scenario 4
|
|||
|
|
|||
|
-------------------------------------------------------------
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Postel [Page 49]
|
|||
|
|
|||
|
|
|||
|
|
|||
|
November 1981 RFC 788
|
|||
|
Simple Mail Transfer Protocol
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Sending and Mailing Scenarios
|
|||
|
|
|||
|
First the user's name is verified, then an attempt is made to
|
|||
|
send to the user's terminal. When that fails, the messages is
|
|||
|
mailed to the user's mailbox.
|
|||
|
|
|||
|
-------------------------------------------------------------
|
|||
|
|
|||
|
R: 220 SU-SCORE Simple Mail Transfer Service Ready
|
|||
|
S: HELO MIT-MC
|
|||
|
R: 250 SU-SCORE
|
|||
|
|
|||
|
S: VRFY Crispin
|
|||
|
R: 250 Mark Crispin <Admin.MRC@SU-SCORE>
|
|||
|
|
|||
|
S: SEND FROM:<EAK@MIT-MC>
|
|||
|
R: 250 OK
|
|||
|
|
|||
|
S: RCPT TO:<Admin.MRC@SU-SCORE>
|
|||
|
R: 450 User not active now
|
|||
|
|
|||
|
S: RSET
|
|||
|
R: 250 OK
|
|||
|
|
|||
|
S: MAIL FROM:<EAK@MIT-MC>
|
|||
|
R: 250 OK
|
|||
|
|
|||
|
S: RCPT TO:<Admin.MRC@SU-SCORE>
|
|||
|
R: 250 OK
|
|||
|
|
|||
|
S: DATA
|
|||
|
R: 354 Start mail input; end with <CRLF>.<CRLF>
|
|||
|
S: Blah blah blah...
|
|||
|
S: ...etc. etc. etc.
|
|||
|
S: .
|
|||
|
R: 250 OK
|
|||
|
|
|||
|
S: QUIT
|
|||
|
R: 221 SU-SCORE Service closing transmission channel
|
|||
|
|
|||
|
Scenario 5
|
|||
|
|
|||
|
-------------------------------------------------------------
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
[Page 50] Postel
|
|||
|
|
|||
|
|
|||
|
|
|||
|
RFC 788 November 1981
|
|||
|
Simple Mail Transfer Protocol
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Doing the preceding scenario more efficiently.
|
|||
|
|
|||
|
-------------------------------------------------------------
|
|||
|
|
|||
|
R: 220 SU-SCORE Simple Mail Transfer Service Ready
|
|||
|
S: HELO MIT-MC
|
|||
|
R: 250 SU-SCORE
|
|||
|
|
|||
|
S: VRFY Crispin
|
|||
|
R: 250 Mark Crispin <Admin.MRC@SU-SCORE>
|
|||
|
|
|||
|
S: SOML FROM:<EAK@MIT-MC>
|
|||
|
R: 250 OK
|
|||
|
|
|||
|
S: RCPT TO:<Admin.MRC@SU-SCORE>
|
|||
|
R: 250 User not active now, so will do mail.
|
|||
|
|
|||
|
S: DATA
|
|||
|
R: 354 Start mail input; end with <CRLF>.<CRLF>
|
|||
|
S: Blah blah blah...
|
|||
|
S: ...etc. etc. etc.
|
|||
|
S: .
|
|||
|
R: 250 OK
|
|||
|
|
|||
|
S: QUIT
|
|||
|
R: 221 SU-SCORE Service closing transmission channel
|
|||
|
|
|||
|
Scenario 6
|
|||
|
|
|||
|
-------------------------------------------------------------
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Postel [Page 51]
|
|||
|
|
|||
|
|
|||
|
|
|||
|
November 1981 RFC 788
|
|||
|
Simple Mail Transfer Protocol
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Mailing List Scenario
|
|||
|
|
|||
|
First each of two mailing lists are expanded in separate sessions
|
|||
|
with different hosts. Then the message is sent to everyone that
|
|||
|
appeared on either list (but no duplicates) via a relay host.
|
|||
|
|
|||
|
-------------------------------------------------------------
|
|||
|
|
|||
|
Step 1 -- Expanding the First List
|
|||
|
|
|||
|
R: 220 MIT-AI Simple Mail Transfer Service Ready
|
|||
|
S: HELO SU-SCORE
|
|||
|
R: 250 MIT-AI
|
|||
|
|
|||
|
S: EXPN Example-People
|
|||
|
R: 250-<ABC@MIT-MC>
|
|||
|
R: 250-Fred Fonebone <Fonebone@ISIQ>
|
|||
|
R: 250-Xenon Y. Zither <XYZ@MIT-AI>
|
|||
|
R: 250-Quincy Smith <@ISIF,Q-Smith@ISI-VAXA>
|
|||
|
R: 250-<joe@foo-unix>
|
|||
|
R: 250 <xyz@bar-unix>
|
|||
|
|
|||
|
S: QUIT
|
|||
|
R: 221 MIT-AI Service closing transmission channel
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
[Page 52] Postel
|
|||
|
|
|||
|
|
|||
|
|
|||
|
RFC 788 November 1981
|
|||
|
Simple Mail Transfer Protocol
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Step 2 -- Expanding the Second List
|
|||
|
|
|||
|
R: 220 MIT-MC Simple Mail Transfer Service Ready
|
|||
|
S: HELO SU-SCORE
|
|||
|
R: 250 MIT-MC
|
|||
|
|
|||
|
S: EXPN Interested-Parties
|
|||
|
R: 250-Al Calico <ABC@MIT-MC>
|
|||
|
R: 250-<XYZ@MIT-AI>
|
|||
|
R: 250-Quincy Smith <@ISIF,Q-Smith@ISI-VAXA>
|
|||
|
R: 250-<fred@BBN-UNIX>
|
|||
|
R: 250 <xyz@bar-unix>
|
|||
|
|
|||
|
S: QUIT
|
|||
|
R: 221 MIT-MC Service closing transmission channel
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Postel [Page 53]
|
|||
|
|
|||
|
|
|||
|
|
|||
|
November 1981 RFC 788
|
|||
|
Simple Mail Transfer Protocol
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Step 3 -- Mailing to All via a Relay Host
|
|||
|
|
|||
|
R: 220 USC-ISIE Simple Mail Transfer Service Ready
|
|||
|
S: HELO SU-SCORE
|
|||
|
R: 250 USC-ISIE
|
|||
|
|
|||
|
S: MAIL FROM:<Account.Person@SU-SCORE>
|
|||
|
R: 250 OK
|
|||
|
S: RCPT TO:<@ISIE,ABC@MIT-MC>
|
|||
|
R: 250 OK
|
|||
|
S: RCPT TO:<@ISIE,Fonebone@ISIQ>
|
|||
|
R: 250 OK
|
|||
|
S: RCPT TO:<@ISIE,XYZ@MIT-AI>
|
|||
|
R: 250 OK
|
|||
|
S: RCPT TO:<@ISIE,@ISIF,Q-Smith@ISI-VAXA>
|
|||
|
R: 250 OK
|
|||
|
S: RCPT TO:<@ISIE,joe@FOO-UNIX>
|
|||
|
R: 250 OK
|
|||
|
S: RCPT TO:<@ISIE,xyz@BAR-UNIX>
|
|||
|
R: 250 OK
|
|||
|
S: RCPT TO:<@ISIE,fred@BBN-UNIX>
|
|||
|
R: 250 OK
|
|||
|
|
|||
|
S: DATA
|
|||
|
R: 354 Start mail input; end with <CRLF>.<CRLF>
|
|||
|
S: Blah blah blah...
|
|||
|
S: ...etc. etc. etc.
|
|||
|
S: .
|
|||
|
R: 250 OK
|
|||
|
|
|||
|
S: QUIT
|
|||
|
R: 221 USC-ISIE Service closing transmission channel
|
|||
|
|
|||
|
Scenario 7
|
|||
|
|
|||
|
-------------------------------------------------------------
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
[Page 54] Postel
|
|||
|
|
|||
|
|
|||
|
|
|||
|
RFC 788 November 1981
|
|||
|
Simple Mail Transfer Protocol
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Forwarding Scenarios
|
|||
|
|
|||
|
-------------------------------------------------------------
|
|||
|
|
|||
|
R: 220 USC-ISIF Simple Mail Transfer Service Ready
|
|||
|
S: HELO LBL-UNIX
|
|||
|
R: 250 USC-ISIF
|
|||
|
|
|||
|
S: MAIL FROM:<mo@LBL-UNIX>
|
|||
|
R: 250 OK
|
|||
|
|
|||
|
S: RCPT TO:<fred@USC-ISIF>
|
|||
|
R: 251 User not local; will forward to <Jones@USC-ISIA>
|
|||
|
|
|||
|
S: DATA
|
|||
|
R: 354 Start mail input; end with <CRLF>.<CRLF>
|
|||
|
S: Blah blah blah...
|
|||
|
S: ...etc. etc. etc.
|
|||
|
S: .
|
|||
|
R: 250 OK
|
|||
|
|
|||
|
S: QUIT
|
|||
|
R: 221 USC-ISIF Service closing transmission channel
|
|||
|
|
|||
|
Scenario 8
|
|||
|
|
|||
|
-------------------------------------------------------------
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Postel [Page 55]
|
|||
|
|
|||
|
|
|||
|
|
|||
|
November 1981 RFC 788
|
|||
|
Simple Mail Transfer Protocol
|
|||
|
|
|||
|
|
|||
|
|
|||
|
-------------------------------------------------------------
|
|||
|
|
|||
|
Step 1 -- Trying the Mailbox at the First Host
|
|||
|
|
|||
|
R: 220 USC-ISIF Simple Mail Transfer Service Ready
|
|||
|
S: HELO LBL-UNIX
|
|||
|
R: 250 USC-ISIF
|
|||
|
|
|||
|
S: MAIL FROM:<mo@LBL-UNIX>
|
|||
|
R: 250 OK
|
|||
|
|
|||
|
S: RCPT TO:<fred@USC-ISIF>
|
|||
|
R: 251 User not local; will forward to <Jones@USC-ISIA>
|
|||
|
|
|||
|
S: RSET
|
|||
|
R: 250 OK
|
|||
|
|
|||
|
S: QUIT
|
|||
|
R: 221 USC-ISIF Service closing transmission channel
|
|||
|
|
|||
|
Step 2 -- Delivering the Mail at the Second Host
|
|||
|
|
|||
|
R: 220 USC-ISIA Simple Mail Transfer Service Ready
|
|||
|
S: HELO LBL-UNIX
|
|||
|
R: 250 USC-ISIA
|
|||
|
|
|||
|
S: MAIL FROM:<mo@LBL-UNIX>
|
|||
|
R: 250 OK
|
|||
|
|
|||
|
S: RCPT TO:<Jones@USC-ISIA>
|
|||
|
R: OK
|
|||
|
|
|||
|
S: DATA
|
|||
|
R: 354 Start mail input; end with <CRLF>.<CRLF>
|
|||
|
S: Blah blah blah...
|
|||
|
S: ...etc. etc. etc.
|
|||
|
S: .
|
|||
|
R: 250 OK
|
|||
|
|
|||
|
S: QUIT
|
|||
|
R: 221 USC-ISIA Service closing transmission channel
|
|||
|
|
|||
|
Scenario 9
|
|||
|
|
|||
|
-------------------------------------------------------------
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
[Page 56] Postel
|
|||
|
|
|||
|
|
|||
|
|
|||
|
RFC 788 November 1981
|
|||
|
Simple Mail Transfer Protocol
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Too Many Recipients Scenario
|
|||
|
|
|||
|
-------------------------------------------------------------
|
|||
|
|
|||
|
R: 220 BERKELEY Simple Mail Transfer Service Ready
|
|||
|
S: HELO USC-ISIF
|
|||
|
R: 250 BERKELEY
|
|||
|
|
|||
|
S: MAIL FROM:<Postel@USC-ISIF>
|
|||
|
R: 250 OK
|
|||
|
|
|||
|
S: RCPT TO:<fabry@BERKELEY>
|
|||
|
R: 250 OK
|
|||
|
|
|||
|
S: RCPT TO:<eric@BERKELEY>
|
|||
|
R: 552 Recipient storage full, try again in another transaction
|
|||
|
|
|||
|
S: DATA
|
|||
|
R: 354 Start mail input; end with <CRLF>.<CRLF>
|
|||
|
S: Blah blah blah...
|
|||
|
S: ...etc. etc. etc.
|
|||
|
S: .
|
|||
|
R: 250 OK
|
|||
|
|
|||
|
S: MAIL FROM:<Postel@USC-ISIF>
|
|||
|
R: 250 OK
|
|||
|
|
|||
|
S: RCPT TO:<eric@BERKELEY>
|
|||
|
R: 250 OK
|
|||
|
|
|||
|
S: DATA
|
|||
|
R: 354 Start mail input; end with <CRLF>.<CRLF>
|
|||
|
S: Blah blah blah...
|
|||
|
S: ...etc. etc. etc.
|
|||
|
S: .
|
|||
|
R: 250 OK
|
|||
|
|
|||
|
S: QUIT
|
|||
|
R: 221 BERKELEY Service closing transmission channel
|
|||
|
|
|||
|
Scenario 10
|
|||
|
|
|||
|
-------------------------------------------------------------
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Postel [Page 57]
|
|||
|
|
|||
|
|
|||
|
|
|||
|
November 1981 RFC 788
|
|||
|
Simple Mail Transfer Protocol
|
|||
|
|
|||
|
|
|||
|
|
|||
|
GLOSSARY
|
|||
|
|
|||
|
ASCII
|
|||
|
|
|||
|
American Standard Code for Information Interchange [1].
|
|||
|
|
|||
|
command
|
|||
|
|
|||
|
A request for a mail service action sent by the sender-SMTP to the
|
|||
|
receiver-SMTP.
|
|||
|
|
|||
|
end of mail data indication
|
|||
|
|
|||
|
A special sequence of characters that indicates the end of the
|
|||
|
mail data. In particular, the five characters carriage return,
|
|||
|
line feed, period, carriage return, line feed, in that order.
|
|||
|
|
|||
|
host
|
|||
|
|
|||
|
A computer in the internetwork environment on which mailboxes or
|
|||
|
SMTP processes reside.
|
|||
|
|
|||
|
line
|
|||
|
|
|||
|
A line of text ending with a <CRLF>.
|
|||
|
|
|||
|
mail data
|
|||
|
|
|||
|
A sequence of ASCII characters of arbitrary length, which conforms
|
|||
|
to the standard set in the Standard for the Format of ARPA Network
|
|||
|
Text Messages (RFC 733 [2]).
|
|||
|
|
|||
|
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.
|
|||
|
|
|||
|
receiver-SMTP process
|
|||
|
|
|||
|
A process which transfers mail in cooperation with a sender-SMTP
|
|||
|
process. It waits for a connection to be established via the
|
|||
|
transport service. It receives SMTP commands from the
|
|||
|
sender-SMTP, sends replies, and performs the specified operations.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
[Page 58] Postel
|
|||
|
|
|||
|
|
|||
|
|
|||
|
RFC 788 November 1981
|
|||
|
Simple Mail Transfer Protocol
|
|||
|
|
|||
|
|
|||
|
|
|||
|
reply
|
|||
|
|
|||
|
A reply is an acknowledgment (positive or negative) sent from
|
|||
|
receiver to sender via the transmission channel in response to a
|
|||
|
SMTP 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.
|
|||
|
|
|||
|
sender-SMTP process
|
|||
|
|
|||
|
A process which transfers mail in cooperation with a receiver-SMTP
|
|||
|
process. A local language may be used in the user interface
|
|||
|
command/reply dialogue. The sender-SMTP initiates the transport
|
|||
|
service connection. It initiates SMTP commands, receives replies,
|
|||
|
and governs the transfer of mail.
|
|||
|
|
|||
|
session
|
|||
|
|
|||
|
The set of exchanges that occur while the transmission channel is
|
|||
|
open.
|
|||
|
|
|||
|
transaction
|
|||
|
|
|||
|
The set of exchanges required for one message to be transmitted
|
|||
|
for one or more recipients.
|
|||
|
|
|||
|
transmission channel
|
|||
|
|
|||
|
A full-duplex communication path between a sender-SMTP and a
|
|||
|
receiver-SMTP for the exchange of commands, replies, and mail
|
|||
|
text.
|
|||
|
|
|||
|
transport service
|
|||
|
|
|||
|
Any reliable stream-oriented data communication services. For
|
|||
|
example, NCP, TCP, NITS.
|
|||
|
|
|||
|
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.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Postel [Page 59]
|
|||
|
|
|||
|
|
|||
|
|
|||
|
November 1981 RFC 788
|
|||
|
Simple Mail Transfer Protocol
|
|||
|
|
|||
|
|
|||
|
|
|||
|
word
|
|||
|
|
|||
|
A sequence of printing characters.
|
|||
|
|
|||
|
<CRLF>
|
|||
|
|
|||
|
The characters carriage return and line feed (in that order).
|
|||
|
|
|||
|
<SP>
|
|||
|
|
|||
|
The space character.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
[Page 60] Postel
|
|||
|
|
|||
|
|
|||
|
|
|||
|
RFC 788 November 1981
|
|||
|
Simple Mail Transfer Protocol
|
|||
|
|
|||
|
|
|||
|
|
|||
|
REFERENCES
|
|||
|
|
|||
|
[1] ASCII
|
|||
|
|
|||
|
ASCII, "USA Code for Information Interchange", United States of
|
|||
|
America Standards Institute, X3.4, 1968. Also in: Feinler, E.
|
|||
|
and J. Postel, eds., "ARPANET Protocol Handbook", NIC 7104, for
|
|||
|
the Defense Communications Agency by SRI International, Menlo
|
|||
|
Park, California, Revised January 1978.
|
|||
|
|
|||
|
[2] RFC 733
|
|||
|
|
|||
|
Crocker, D., J. Vittal, K. Pogran, and D. Henderson, "Standard for
|
|||
|
the Format of ARPA Network Text Messages," RFC 733, NIC 41952,
|
|||
|
November 1977. Also in: Feinler, E. and J. Postel, eds.,
|
|||
|
"ARPANET Protocol Handbook", NIC 7104, for the Defense
|
|||
|
Communications Agency by SRI International, Menlo Park,
|
|||
|
California, Revised January 1978.
|
|||
|
|
|||
|
[3] TCP
|
|||
|
|
|||
|
Postel, J., ed., "Transmission Control Protocol - DARPA Internet
|
|||
|
Program Protocol Specification", RFC 793, USC/Information Sciences
|
|||
|
Institute, September 1981.
|
|||
|
|
|||
|
[4] NCP
|
|||
|
|
|||
|
McKenzie,A., "Host/Host Protocol for the ARPA Network", NIC 8246,
|
|||
|
January 1972. Also in: Feinler, E. and J. Postel, eds., "ARPANET
|
|||
|
Protocol Handbook", NIC 7104, for the Defense Communications
|
|||
|
Agency by SRI International, Menlo Park, California, Revised
|
|||
|
January 1978.
|
|||
|
|
|||
|
[5] Initial Connection Protocol
|
|||
|
|
|||
|
Postel, J., "Official Initial Connection Protocol", NIC 7101,
|
|||
|
11 June 1971. Also in: Feinler, E. and J. Postel, eds., "ARPANET
|
|||
|
Protocol Handbook", NIC 7104, for the Defense Communications
|
|||
|
Agency by SRI International, Menlo Park, California, Revised
|
|||
|
January 1978.
|
|||
|
|
|||
|
[6] NITS
|
|||
|
|
|||
|
PSS/SG3, "A Network Independent Transport Service", Study Group 3,
|
|||
|
The Post Office PSS Users Group, February 1980. Available from
|
|||
|
the DCPU, National Physical Laboratory, Teddington, UK.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Postel [Page 61]
|
|||
|
|
|||
|
|
|||
|
|
|||
|
November 1981 RFC 788
|
|||
|
Simple Mail Transfer Protocol
|
|||
|
|
|||
|
|
|||
|
|
|||
|
[7] X.25
|
|||
|
|
|||
|
CCITT, "Recommendation X.25 - Interface Between Data Terminal
|
|||
|
Equipment (DTE) and Data Circuit-terminating Equipment (DCE) for
|
|||
|
Terminals Operating in the Packet Mode on Public Data Networks,"
|
|||
|
CCITT Orange Book, Vol. VIII.2, International Telephone and
|
|||
|
Telegraph Consultative Committee, Geneva, 1976.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
[Page 62] Postel
|
|||
|
|