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