rfc821.txt

smtp proxy source code!

                                                                        

   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

                             [phone]



                                                                        
RFC 821                                                      August 1982
                                           Simple Mail Transfer Protocol



                           TABLE OF CONTENTS

   1.  INTRODUCTION .................................................. 1

   2.  THE SMTP MODEL ................................................ 2

   3.  THE SMTP PROCEDURE ............................................ 4

      3.1.  Mail ..................................................... 4
      3.2.  Forwarding ............................................... 7
      3.3.  Verifying and Expanding .................................. 8
      3.4.  Sending and Mailing ..................................... 11
      3.5.  Opening and Closing ..................................... 13
      3.6.  Relaying ................................................ 14
      3.7.  Domains ................................................. 17
      3.8.  Changing Roles .......................................... 18

   4.  THE SMTP SPECIFICATIONS ...................................... 19

      4.1.  SMTP Commands ........................................... 19
      4.1.1.  Command Semantics ..................................... 19
      4.1.2.  Command Syntax ........................................ 27
      4.2.  SMTP Replies ............................................ 34
      4.2.1.  Reply Codes by Function Group ......................... 35
      4.2.2.  Reply Codes in Numeric Order .......................... 36
      4.3.  Sequencing of Commands and Replies ...................... 37
      4.4.  State Diagrams .......................................... 39
      4.5.  Details ................................................. 41
      4.5.1.  Minimum Implementation ................................ 41
      4.5.2.  Transparency .......................................... 41
      4.5.3.  Sizes ................................................. 42

   APPENDIX A:  TCP ................................................. 44
   APPENDIX B:  NCP ................................................. 45
   APPENDIX C:  NITS ................................................ 46
   APPENDIX D:  X.25 ................................................ 47
   APPENDIX E:  Theory of Reply Codes ............................... 48
   APPENDIX F:  Scenarios ........................................... 51

   GLOSSARY ......................................................... 64

   REFERENCES ....................................................... 67




Network Working Group                                          J. Postel
Request for Comments: DRAFT                                          ISI
Replaces: RFC 788, 780, 772                                  August 1982

                     SIMPLE MAIL TRANSFER PROTOCOL


1.  INTRODUCTION

   The objective of Simple Mail Transfer Protocol (SMTP) is to transfer
   mail reliably and efficiently.

   SMTP is independent of the particular transmission subsystem and
   requires only a reliable ordered data stream channel.  Appendices A,
   B, C, and D describe the use of SMTP with various transport services.
   A Glossary provides the definitions of terms as used in this
   document.

   An important feature of SMTP is its capability to relay mail across
   transport service environments.  A transport service provides an
   interprocess communication environment (IPCE).  An IPCE may cover one
   network, several networks, or a subset of a network.  It is important
   to realize that transport systems (or IPCEs) are not one-to-one with
   networks.  A process can communicate directly with another process
   through any mutually known IPCE.  Mail is an application or use of
   interprocess communication.  Mail can be communicated between
   processes in different IPCEs by relaying through a process connected
   to two (or more) IPCEs.  More specifically, mail can be relayed
   between hosts on different transport systems by a host on both
   transport systems.
























Postel                                                          [Page 1]


                                                                        
August 1982                                                      RFC 821
Simple Mail Transfer Protocol                                           



2.  THE SMTP MODEL

   The SMTP design is based on the following model of communication:  as
   the result of a user mail request, the sender-SMTP establishes a
   two-way transmission channel to a receiver-SMTP.  The receiver-SMTP
   may be either the ultimate destination or an intermediate.  SMTP
   commands are generated by the sender-SMTP and sent to the
   receiver-SMTP.  SMTP replies are sent from the receiver-SMTP to the
   sender-SMTP in response to the commands.

   Once the transmission channel is established, the SMTP-sender sends a
   MAIL command indicating the sender of the mail.  If the SMTP-receiver
   can accept mail it responds with an OK reply.  The SMTP-sender then
   sends a RCPT command identifying a recipient of the mail.  If the
   SMTP-receiver can accept mail for that recipient it responds with an
   OK reply; if not, it responds with a reply rejecting that recipient
   (but not the whole mail transaction).  The SMTP-sender and
   SMTP-receiver may negotiate several recipients.  When the recipients
   have been negotiated the SMTP-sender sends the mail data, terminating
   with a special sequence.  If the SMTP-receiver successfully processes
   the mail data it responds with an OK reply.  The dialog is purposely
   lock-step, one-at-a-time.

     -------------------------------------------------------------

   
               +----------+                +----------+
   +------+    |          |                |          |
   | User |<-->|          |      SMTP      |          |
   +------+    |  Sender- |Commands/Replies| Receiver-|
   +------+    |   SMTP   |<-------------->|    SMTP  |    +------+
   | File |<-->|          |    and Mail    |          |<-->| File |
   |System|    |          |                |          |    |System|
   +------+    +----------+                +----------+    +------+
   

                Sender-SMTP                Receiver-SMTP

                           Model for SMTP Use

                                Figure 1

     -------------------------------------------------------------

   The SMTP provides mechanisms for the transmission of mail; directly
   from the sending user's host to the receiving user's host when the



[Page 2]                                                          Postel


                                                                        
RFC 821                                                      August 1982
                                           Simple Mail Transfer Protocol



   two host are connected to the same transport service, or via one or
   more relay SMTP-servers when the source and destination hosts are not
   connected to the same transport service.

   To be able to provide the relay capability the SMTP-server must be
   supplied with the name of the ultimate destination host as well as
   the destination mailbox name.

   The argument to the MAIL command is a reverse-path, which specifies
   who the mail is from.  The argument to the RCPT command is a
   forward-path, which specifies who the mail is to.  The forward-path
   is a source route, while the reverse-path is a return route (which
   may be used to return a message to the sender when an error occurs
   with a relayed message).

   When the same message is sent to multiple recipients the SMTP
   encourages the transmission of only one copy of the data for all the
   recipients at the same destination host.

   The mail commands and replies have a rigid syntax.  Replies also have
   a numeric code.  In the following, examples appear which use actual
   commands and replies.  The complete lists of commands and replies
   appears in Section 4 on specifications.

   Commands and replies are not case sensitive.  That is, a command or
   reply word may be upper case, lower case, or any mixture of upper and
   lower case.  Note that this is not true of mailbox user names.  For
   some hosts the user name is case sensitive, and SMTP implementations
   must take case to preserve the case of user names as they appear in
   mailbox arguments.  Host names are not case sensitive.

   Commands and replies are composed of characters from the ASCII
   character set [1].  When the transport service provides an 8-bit byte
   (octet) transmission channel, each 7-bit character is transmitted
   right justified in an octet with the high order bit cleared to zero.

   When specifying the general form of a command or reply, an argument
   (or special symbol) will be denoted by a meta-linguistic variable (or
   constant), for example, "<string>" or "<reverse-path>".  Here the
   angle brackets indicate these are meta-linguistic variables.
   However, some arguments use the angle brackets literally.  For
   example, an actual reverse-path is enclosed in angle brackets, i.e.,
   "<[e-mail]>" is an instance of <reverse-path> (the
   angle brackets are actually transmitted in the command or reply).





Postel                                                          [Page 3]


                                                                        
August 1982                                                      RFC 821
Simple Mail Transfer Protocol                                           



3.  THE SMTP PROCEDURES

   This section presents the procedures used in SMTP in several parts.
   First comes the basic mail procedure defined as a mail transaction.
   Following this are descriptions of forwarding mail, verifying mailbox
   names and expanding mailing lists, sending to terminals instead of or
   in combination with mailboxes, and the opening and closing exchanges.
   At the end of this section are comments on relaying, a note on mail
   domains, and a discussion of changing roles.  Throughout this section
   are examples of partial command and reply sequences, several complete
   scenarios are presented in Appendix F.

   3.1.  MAIL

      There are three steps to SMTP mail transactions.  The transaction
      is started with a MAIL command which gives the sender
      identification.  A series of one or more RCPT commands follows
      giving the receiver information.  Then a DATA command gives the
      mail data.  And finally, the end of mail data indicator confirms
      the transaction.

         The first step in the procedure is the MAIL command.  The
         <reverse-path> contains the source mailbox.

            MAIL <SP> FROM:<reverse-path> <CRLF>

         This command tells the SMTP-receiver that a new mail
         transaction is starting and to reset all its state tables and
         buffers, including any recipients or mail data.  It gives the
         reverse-path which can be used to report errors.  If accepted,
         the receiver-SMTP returns a 250 OK reply.

         The <reverse-path> can contain more than just a mailbox.  The
         <reverse-path> is a reverse source routing list of hosts and
         source mailbox.  The first host in the <reverse-path> should be
         the host sending this command.

         The second step in the procedure is the RCPT command.

            RCPT <SP> TO:<forward-path> <CRLF>

         This command gives a forward-path identifying one recipient.
         If accepted, the receiver-SMTP returns a 250 OK reply, and
         stores the forward-path.  If the recipient is unknown the
         receiver-SMTP returns a 550 Failure reply.  This second step of
         the procedure can be repeated any number of times.



[Page 4]                                                          Postel


                                                                        
RFC 821                                                      August 1982
                                           Simple Mail Transfer Protocol



         The <forward-path> can contain more than just a mailbox.  The
         <forward-path> is a source routing list of hosts and the
         destination mailbox.  The first host in the <forward-path>
         should be the host receiving this command.

         The third step in the procedure is the DATA command.

            DATA <CRLF>

         If accepted, the receiver-SMTP returns a 354 Intermediate reply
         and considers all succeeding lines to be the message text.
         When the end of text is received and stored the SMTP-receiver
         sends a 250 OK reply.

         Since the mail data is sent on the transmission channel the end
         of the mail data must be indicated so that the command and
         reply dialog can be resumed.  SMTP indicates the end of the
         mail data by sending a line containing only a period.  A
         transparency procedure is used to prevent this from interfering
         with the user's text (see Section 4.5.2).

            Please note that the mail data includes the memo header
            items such as Date, Subject, To, Cc, From [2].

         The end of mail data indicator also confirms the mail
         transaction and tells the receiver-SMTP to now process the
         stored recipients and mail data.  If accepted, the
         receiver-SMTP returns a 250 OK reply.  The DATA command should
         fail only if the mail transaction was incomplete (for example,
         no recipients), or if resources are not available.

      The above procedure is an example of a mail transaction.  These
      commands must be used only in the order discussed above.
      Example 1 (below) illustrates the use of these commands in a mail
      transaction.