From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001
From: Thomas Voss <mail@thomasvoss.com>
Date: Wed, 27 Nov 2024 20:54:24 +0100
Subject: doc: Add RFC documents

---
 doc/rfc/rfc788.txt | 3697 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 3697 insertions(+)
 create mode 100644 doc/rfc/rfc788.txt

(limited to 'doc/rfc/rfc788.txt')

diff --git a/doc/rfc/rfc788.txt b/doc/rfc/rfc788.txt
new file mode 100644
index 0000000..b4b01fc
--- /dev/null
+++ b/doc/rfc/rfc788.txt
@@ -0,0 +1,3697 @@
+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
+
-- 
cgit v1.2.3