dmc

dynamic mail client
git clone git://git.suckless.org/dmc
Log | Files | Refs | README | LICENSE

smtp-rfc821.txt (115883B)


      1 
      2                      SIMPLE MAIL TRANSFER PROTOCOL
      3 
      4                            Jonathan B. Postel
      5 
      6                               August 1982
      7 
      8                      Information Sciences Institute
      9                    University of Southern California
     10                            4676 Admiralty Way
     11                    Marina del Rey, California  90291
     12 
     13                              (213) 822-1511
     14 
     15                                                              August 1982
     16                                            Simple Mail Transfer Protocol
     17 
     18                            TABLE OF CONTENTS
     19 
     20    1.  INTRODUCTION .................................................. 1
     21 
     22    2.  THE SMTP MODEL ................................................ 2
     23 
     24    3.  THE SMTP PROCEDURE ............................................ 4
     25 
     26       3.1.  Mail ..................................................... 4
     27       3.2.  Forwarding ............................................... 7
     28       3.3.  Verifying and Expanding .................................. 8
     29       3.4.  Sending and Mailing ..................................... 11
     30       3.5.  Opening and Closing ..................................... 13
     31       3.6.  Relaying ................................................ 14
     32       3.7.  Domains ................................................. 17
     33       3.8.  Changing Roles .......................................... 18
     34 
     35    4.  THE SMTP SPECIFICATIONS ...................................... 19
     36 
     37       4.1.  SMTP Commands ........................................... 19
     38       4.1.1.  Command Semantics ..................................... 19
     39       4.1.2.  Command Syntax ........................................ 27
     40       4.2.  SMTP Replies ............................................ 34
     41       4.2.1.  Reply Codes by Function Group ......................... 35
     42       4.2.2.  Reply Codes in Numeric Order .......................... 36
     43       4.3.  Sequencing of Commands and Replies ...................... 37
     44       4.4.  State Diagrams .......................................... 39
     45       4.5.  Details ................................................. 41
     46       4.5.1.  Minimum Implementation ................................ 41
     47       4.5.2.  Transparency .......................................... 41
     48       4.5.3.  Sizes ................................................. 42
     49 
     50    APPENDIX A:  TCP ................................................. 44
     51    APPENDIX B:  NCP ................................................. 45
     52    APPENDIX C:  NITS ................................................ 46
     53    APPENDIX D:  X.25 ................................................ 47
     54    APPENDIX E:  Theory of Reply Codes ............................... 48
     55    APPENDIX F:  Scenarios ........................................... 51
     56 
     57    GLOSSARY ......................................................... 64
     58 
     59    REFERENCES ....................................................... 67
     60 
     61 Network Working Group                                          J. Postel
     62 Request for Comments: DRAFT                                          ISI
     63 Replaces: _R_F_C_ _7_8_8, 780, 772                                  August 1982
     64 
     65                      SIMPLE MAIL TRANSFER PROTOCOL
     66 
     67 1.  INTRODUCTION
     68 
     69    The objective of Simple Mail Transfer Protocol (SMTP) is to transfer
     70    mail reliably and efficiently.
     71 
     72    SMTP is independent of the particular transmission subsystem and
     73    requires only a reliable ordered data stream channel.  Appendices A,
     74    B, C, and D describe the use of SMTP with various transport services.
     75    A Glossary provides the definitions of terms as used in this
     76    document.
     77 
     78    An important feature of SMTP is its capability to relay mail across
     79    transport service environments.  A transport service provides an
     80    interprocess communication environment (IPCE).  An IPCE may cover one
     81    network, several networks, or a subset of a network.  It is important
     82    to realize that transport systems (or IPCEs) are not one-to-one with
     83    networks.  A process can communicate directly with another process
     84    through any mutually known IPCE.  Mail is an application or use of
     85    interprocess communication.  Mail can be communicated between
     86    processes in different IPCEs by relaying through a process connected
     87    to two (or more) IPCEs.  More specifically, mail can be relayed
     88    between hosts on different transport systems by a host on both
     89    transport systems.
     90 
     91 August 1982                                                      _R_F_C_ _8_2_1
     92 Simple Mail Transfer Protocol
     93 
     94 2.  THE SMTP MODEL
     95 
     96    The SMTP design is based on the following model of communication:  as
     97    the result of a user mail request, the sender-SMTP establishes a
     98    two-way transmission channel to a receiver-SMTP.  The receiver-SMTP
     99    may be either the ultimate destination or an intermediate.  SMTP
    100    commands are generated by the sender-SMTP and sent to the
    101    receiver-SMTP.  SMTP replies are sent from the receiver-SMTP to the
    102    sender-SMTP in response to the commands.
    103 
    104    Once the transmission channel is established, the SMTP-sender sends a
    105    MAIL command indicating the sender of the mail.  If the SMTP-receiver
    106    can accept mail it responds with an OK reply.  The SMTP-sender then
    107    sends a RCPT command identifying a recipient of the mail.  If the
    108    SMTP-receiver can accept mail for that recipient it responds with an
    109    OK reply; if not, it responds with a reply rejecting that recipient
    110    (but not the whole mail transaction).  The SMTP-sender and
    111    SMTP-receiver may negotiate several recipients.  When the recipients
    112    have been negotiated the SMTP-sender sends the mail data, terminating
    113    with a special sequence.  If the SMTP-receiver successfully processes
    114    the mail data it responds with an OK reply.  The dialog is purposely
    115    lock-step, one-at-a-time.
    116 
    117      -------------------------------------------------------------
    118 
    119                +----------+                +----------+
    120    +------+    |          |                |          |
    121    | User |<-->|          |      SMTP      |          |
    122    +------+    |  Sender- |Commands/Replies| Receiver-|
    123    +------+    |   SMTP   |<-------------->|    SMTP  |    +------+
    124    | File |<-->|          |    and Mail    |          |<-->| File |
    125    |System|    |          |                |          |    |System|
    126    +------+    +----------+                +----------+    +------+
    127 
    128                 Sender-SMTP                Receiver-SMTP
    129 
    130                            Model for SMTP Use
    131 
    132                                 Figure 1
    133 
    134      -------------------------------------------------------------
    135 
    136    The SMTP provides mechanisms for the transmission of mail; directly
    137    from the sending user's host to the receiving user's host when the
    138 
    139 _R_F_C_ _8_2_1                                                      August 1982
    140                                            Simple Mail Transfer Protocol
    141 
    142    two host are connected to the same transport service, or via one or
    143    more relay SMTP-servers when the source and destination hosts are not
    144    connected to the same transport service.
    145 
    146    To be able to provide the relay capability the SMTP-server must be
    147    supplied with the name of the ultimate destination host as well as
    148    the destination mailbox name.
    149 
    150    The argument to the MAIL command is a reverse-path, which specifies
    151    who the mail is from.  The argument to the RCPT command is a
    152    forward-path, which specifies who the mail is to.  The forward-path
    153    is a source route, while the reverse-path is a return route (which
    154    may be used to return a message to the sender when an error occurs
    155    with a relayed message).
    156 
    157    When the same message is sent to multiple recipients the SMTP
    158    encourages the transmission of only one copy of the data for all the
    159    recipients at the same destination host.
    160 
    161    The mail commands and replies have a rigid syntax.  Replies also have
    162    a numeric code.  In the following, examples appear which use actual
    163    commands and replies.  The complete lists of commands and replies
    164    appears in Section 4 on specifications.
    165 
    166    Commands and replies are not case sensitive.  That is, a command or
    167    reply word may be upper case, lower case, or any mixture of upper and
    168    lower case.  Note that this is not true of mailbox user names.  For
    169    some hosts the user name is case sensitive, and SMTP implementations
    170    must take case to preserve the case of user names as they appear in
    171    mailbox arguments.  Host names are not case sensitive.
    172 
    173    Commands and replies are composed of characters from the ASCII
    174    character set [1].  When the transport service provides an 8-bit byte
    175    (octet) transmission channel, each 7-bit character is transmitted
    176    right justified in an octet with the high order bit cleared to zero.
    177 
    178    When specifying the general form of a command or reply, an argument
    179    (or special symbol) will be denoted by a meta-linguistic variable (or
    180    constant), for example, "<string>" or "<reverse-path>".  Here the
    181    angle brackets indicate these are meta-linguistic variables.
    182    However, some arguments use the angle brackets literally.  For
    183    example, an actual reverse-path is enclosed in angle brackets, i.e.,
    184    "<_J_o_h_n_._S_m_i_t_h_@_U_S_C_-_I_S_I_._A_R_P_A>" is an instance of <reverse-path> (the
    185    angle brackets are actually transmitted in the command or reply).
    186 
    187 August 1982                                                      _R_F_C_ _8_2_1
    188 Simple Mail Transfer Protocol
    189 
    190 3.  THE SMTP PROCEDURES
    191 
    192    This section presents the procedures used in SMTP in several parts.
    193    First comes the basic mail procedure defined as a mail transaction.
    194    Following this are descriptions of forwarding mail, verifying mailbox
    195    names and expanding mailing lists, sending to terminals instead of or
    196    in combination with mailboxes, and the opening and closing exchanges.
    197    At the end of this section are comments on relaying, a note on mail
    198    domains, and a discussion of changing roles.  Throughout this section
    199    are examples of partial command and reply sequences, several complete
    200    scenarios are presented in Appendix F.
    201 
    202    3.1.  MAIL
    203 
    204       There are three steps to SMTP mail transactions.  The transaction
    205       is started with a MAIL command which gives the sender
    206       identification.  A series of one or more RCPT commands follows
    207       giving the receiver information.  Then a DATA command gives the
    208       mail data.  And finally, the end of mail data indicator confirms
    209       the transaction.
    210 
    211          The first step in the procedure is the MAIL command.  The
    212          <reverse-path> contains the source mailbox.
    213 
    214             MAIL <SP> FROM:<reverse-path> <CRLF>
    215 
    216          This command tells the SMTP-receiver that a new mail
    217          transaction is starting and to reset all its state tables and
    218          buffers, including any recipients or mail data.  It gives the
    219          reverse-path which can be used to report errors.  If accepted,
    220          the receiver-SMTP returns a 250 OK reply.
    221 
    222          The <reverse-path> can contain more than just a mailbox.  The
    223          <reverse-path> is a reverse source routing list of hosts and
    224          source mailbox.  The first host in the <reverse-path> should be
    225          the host sending this command.
    226 
    227          The second step in the procedure is the RCPT command.
    228 
    229             RCPT <SP> TO:<forward-path> <CRLF>
    230 
    231          This command gives a forward-path identifying one recipient.
    232          If accepted, the receiver-SMTP returns a 250 OK reply, and
    233          stores the forward-path.  If the recipient is unknown the
    234          receiver-SMTP returns a 550 Failure reply.  This second step of
    235          the procedure can be repeated any number of times.
    236 
    237 _R_F_C_ _8_2_1                                                      August 1982
    238                                            Simple Mail Transfer Protocol
    239 
    240          The <forward-path> can contain more than just a mailbox.  The
    241          <forward-path> is a source routing list of hosts and the
    242          destination mailbox.  The first host in the <forward-path>
    243          should be the host receiving this command.
    244 
    245          The third step in the procedure is the DATA command.
    246 
    247             DATA <CRLF>
    248 
    249          If accepted, the receiver-SMTP returns a 354 Intermediate reply
    250          and considers all succeeding lines to be the message text.
    251          When the end of text is received and stored the SMTP-receiver
    252          sends a 250 OK reply.
    253 
    254          Since the mail data is sent on the transmission channel the end
    255          of the mail data must be indicated so that the command and
    256          reply dialog can be resumed.  SMTP indicates the end of the
    257          mail data by sending a line containing only a period.  A
    258          transparency procedure is used to prevent this from interfering
    259          with the user's text (see Section 4.5.2).
    260 
    261             Please note that the mail data includes the memo header
    262             items such as Date, Subject, To, Cc, From [2].
    263 
    264          The end of mail data indicator also confirms the mail
    265          transaction and tells the receiver-SMTP to now process the
    266          stored recipients and mail data.  If accepted, the
    267          receiver-SMTP returns a 250 OK reply.  The DATA command should
    268          fail only if the mail transaction was incomplete (for example,
    269          no recipients), or if resources are not available.
    270 
    271       The above procedure is an example of a mail transaction.  These
    272       commands must be used only in the order discussed above.
    273       Example 1 (below) illustrates the use of these commands in a mail
    274       transaction.
    275 
    276 August 1982                                                      _R_F_C_ _8_2_1
    277 Simple Mail Transfer Protocol
    278 
    279       -------------------------------------------------------------
    280 
    281                      Example of the SMTP Procedure
    282 
    283          This SMTP example shows mail sent by Smith at host Alpha.ARPA,
    284          to Jones, Green, and Brown at host Beta.ARPA.  Here we assume
    285          that host Alpha contacts host Beta directly.
    286 
    287             S: MAIL FROM:<_S_m_i_t_h_@_A_l_p_h_a_._A_R_P_A>
    288             R: 250 OK
    289 
    290             S: RCPT TO:<_J_o_n_e_s_@_B_e_t_a_._A_R_P_A>
    291             R: 250 OK
    292 
    293             S: RCPT TO:<_G_r_e_e_n_@_B_e_t_a_._A_R_P_A>
    294             R: 550 No such user here
    295 
    296             S: RCPT TO:<_B_r_o_w_n_@_B_e_t_a_._A_R_P_A>
    297             R: 250 OK
    298 
    299             S: DATA
    300             R: 354 Start mail input; end with <CRLF>.<CRLF>
    301             S: Blah blah blah...
    302             S: ...etc. etc. etc.
    303             S: <CRLF>.<CRLF>
    304             R: 250 OK
    305 
    306          The mail has now been accepted for Jones and Brown.  Green did
    307          not have a mailbox at host Beta.
    308 
    309                                Example 1
    310 
    311       -------------------------------------------------------------
    312 
    313 _R_F_C_ _8_2_1                                                      August 1982
    314                                            Simple Mail Transfer Protocol
    315 
    316    3.2.  FORWARDING
    317 
    318       There are some cases where the destination information in the
    319       <forward-path> is incorrect, but the receiver-SMTP knows the
    320       correct destination.  In such cases, one of the following replies
    321       should be used to allow the sender to contact the correct
    322       destination.
    323 
    324          251 User not local; will forward to <forward-path>
    325 
    326             This reply indicates that the receiver-SMTP knows the user's
    327             mailbox is on another host and indicates the correct
    328             forward-path to use in the future.  Note that either the
    329             host or user or both may be different.  The receiver takes
    330             responsibility for delivering the message.
    331 
    332          551 User not local; please try <forward-path>
    333 
    334             This reply indicates that the receiver-SMTP knows the user's
    335             mailbox is on another host and indicates the correct
    336             forward-path to use.  Note that either the host or user or
    337             both may be different.  The receiver refuses to accept mail
    338             for this user, and the sender must either redirect the mail
    339             according to the information provided or return an error
    340             response to the originating user.
    341 
    342       Example 2 illustrates the use of these responses.
    343 
    344       -------------------------------------------------------------
    345 
    346                          Example of Forwarding
    347 
    348       Either
    349 
    350       S: RCPT TO:<_P_o_s_t_e_l_@_U_S_C_-_I_S_I_._A_R_P_A>
    351       R: 251 User not local; will forward to <_P_o_s_t_e_l_@_U_S_C_-_I_S_I_F_._A_R_P_A>
    352 
    353       Or
    354 
    355       S: RCPT TO:<_P_a_u_l_@_U_S_C_-_I_S_I_B_._A_R_P_A>
    356       R: 551 User not local; please try <_M_o_c_k_a_p_e_t_r_i_s_@_U_S_C_-_I_S_I_F_._A_R_P_A>
    357 
    358                                Example 2
    359 
    360       -------------------------------------------------------------
    361 
    362 August 1982                                                      _R_F_C_ _8_2_1
    363 Simple Mail Transfer Protocol
    364 
    365    3.3.  VERIFYING AND EXPANDING
    366 
    367       SMTP provides as additional features, commands to verify a user
    368       name or expand a mailing list.  This is done with the VRFY and
    369       EXPN commands, which have character string arguments.  For the
    370       VRFY command, the string is a user name, and the response may
    371       include the full name of the user and must include the mailbox of
    372       the user.  For the EXPN command, the string identifies a mailing
    373       list, and the multiline response may include the full name of the
    374       users and must give the mailboxes on the mailing list.
    375 
    376       "User name" is a fuzzy term and used purposely.  If a host
    377       implements the VRFY or EXPN commands then at least local mailboxes
    378       must be recognized as "user names".  If a host chooses to
    379       recognize other strings as "user names" that is allowed.
    380 
    381       In some hosts the distinction between a mailing list and an alias
    382       for a single mailbox is a bit fuzzy, since a common data structure
    383       may hold both types of entries, and it is possible to have mailing
    384       lists of one mailbox.  If a request is made to verify a mailing
    385       list a positive response can be given if on receipt of a message
    386       so addressed it will be delivered to everyone on the list,
    387       otherwise an error should be reported (e.g., "550 That is a
    388       mailing list, not a user").  If a request is made to expand a user
    389       name a positive response can be formed by returning a list
    390       containing one name, or an error can be reported (e.g., "550 That
    391       is a user name, not a mailing list").
    392 
    393       In the case of a multiline reply (normal for EXPN) exactly one
    394       mailbox is to be specified on each line of the reply.  In the case
    395       of an ambiguous request, for example, "VRFY Smith", where there
    396       are two Smith's the response must be "553 User ambiguous".
    397 
    398       The case of verifying a user name is straightforward as shown in
    399       example 3.
    400 
    401 _R_F_C_ _8_2_1                                                      August 1982
    402                                            Simple Mail Transfer Protocol
    403 
    404       -------------------------------------------------------------
    405 
    406                     Example of Verifying a User Name
    407 
    408          Either
    409 
    410             S: VRFY Smith
    411             R: 250 Fred Smith <_S_m_i_t_h_@_U_S_C_-_I_S_I_F_._A_R_P_A>
    412 
    413          Or
    414 
    415             S: VRFY Smith
    416             R: 251 User not local; will forward to <_S_m_i_t_h_@_U_S_C_-_I_S_I_Q_._A_R_P_A>
    417 
    418          Or
    419 
    420             S: VRFY Jones
    421             R: 550 String does not match anything.
    422 
    423          Or
    424 
    425             S: VRFY Jones
    426             R: 551 User not local; please try <_J_o_n_e_s_@_U_S_C_-_I_S_I_Q_._A_R_P_A>
    427 
    428          Or
    429 
    430             S: VRFY Gourzenkyinplatz
    431             R: 553 User ambiguous.
    432 
    433                                Example 3
    434 
    435       -------------------------------------------------------------
    436 
    437 August 1982                                                      _R_F_C_ _8_2_1
    438 Simple Mail Transfer Protocol
    439 
    440       The case of expanding a mailbox list requires a multiline reply as
    441       shown in example 4.
    442 
    443       -------------------------------------------------------------
    444 
    445                   Example of Expanding a Mailing List
    446 
    447          Either
    448 
    449             S: EXPN Example-People
    450             R: 250-Jon Postel <_P_o_s_t_e_l_@_U_S_C_-_I_S_I_F_._A_R_P_A>
    451             R: 250-Fred Fonebone <_F_o_n_e_b_o_n_e_@_U_S_C_-_I_S_I_Q_._A_R_P_A>
    452             R: 250-Sam Q. Smith <_S_Q_S_m_i_t_h_@_U_S_C_-_I_S_I_Q_._A_R_P_A>
    453             R: 250-Quincy Smith <@USC-ISIF.ARPA:_Q_-_S_m_i_t_h_@_I_S_I_-_V_A_X_A_._A_R_P_A>
    454             R: 250-<_j_o_e_@_f_o_o_-_u_n_i_x_._A_R_P_A>
    455             R: 250 <_x_y_z_@_b_a_r_-_u_n_i_x_._A_R_P_A>
    456 
    457          Or
    458 
    459             S: EXPN Executive-Washroom-List
    460             R: 550 Access Denied to You.
    461 
    462                                Example 4
    463 
    464       -------------------------------------------------------------
    465 
    466       The character string arguments of the VRFY and EXPN commands
    467       cannot be further restricted due to the variety of implementations
    468       of the user name and mailbox list concepts.  On some systems it
    469       may be appropriate for the argument of the EXPN command to be a
    470       file name for a file containing a mailing list, but again there is
    471       a variety of file naming conventions in the Internet.
    472 
    473       The VRFY and EXPN commands are not included in the minimum
    474       implementation (Section 4.5.1), and are not required to work
    475       across relays when they are implemented.
    476 
    477 _R_F_C_ _8_2_1                                                      August 1982
    478                                            Simple Mail Transfer Protocol
    479 
    480    3.4.  SENDING AND MAILING
    481 
    482       The main purpose of SMTP is to deliver messages to user's
    483       mailboxes.  A very similar service provided by some hosts is to
    484       deliver messages to user's terminals (provided the user is active
    485       on the host).  The delivery to the user's mailbox is called
    486       "mailing", the delivery to the user's terminal is called
    487       "sending".  Because in many hosts the implementation of sending is
    488       nearly identical to the implementation of mailing these two
    489       functions are combined in SMTP.  However the sending commands are
    490       not included in the required minimum implementation
    491       (Section 4.5.1).  Users should have the ability to control the
    492       writing of messages on their terminals.  Most hosts permit the
    493       users to accept or refuse such messages.
    494 
    495       The following three command are defined to support the sending
    496       options.  These are used in the mail transaction instead of the
    497       MAIL command and inform the receiver-SMTP of the special semantics
    498       of this transaction:
    499 
    500          SEND <SP> FROM:<reverse-path> <CRLF>
    501 
    502             The SEND command requires that the mail data be delivered to
    503             the user's terminal.  If the user is not active (or not
    504             accepting terminal messages) on the host a 450 reply may
    505             returned to a RCPT command.  The mail transaction is
    506             successful if the message is delivered the terminal.
    507 
    508          SOML <SP> FROM:<reverse-path> <CRLF>
    509 
    510             The Send Or MaiL command requires that the mail data be
    511             delivered to the user's terminal if the user is active (and
    512             accepting terminal messages) on the host.  If the user is
    513             not active (or not accepting terminal messages) then the
    514             mail data is entered into the user's mailbox.  The mail
    515             transaction is successful if the message is delivered either
    516             to the terminal or the mailbox.
    517 
    518          SAML <SP> FROM:<reverse-path> <CRLF>
    519 
    520             The Send And MaiL command requires that the mail data be
    521             delivered to the user's terminal if the user is active (and
    522             accepting terminal messages) on the host.  In any case the
    523             mail data is entered into the user's mailbox.  The mail
    524             transaction is successful if the message is delivered the
    525             mailbox.
    526 
    527 August 1982                                                      _R_F_C_ _8_2_1
    528 Simple Mail Transfer Protocol
    529 
    530       The same reply codes that are used for the MAIL commands are used
    531       for these commands.
    532 
    533 _R_F_C_ _8_2_1                                                      August 1982
    534                                            Simple Mail Transfer Protocol
    535 
    536    3.5.  OPENING AND CLOSING
    537 
    538       At the time the transmission channel is opened there is an
    539       exchange to ensure that the hosts are communicating with the hosts
    540       they think they are.
    541 
    542       The following two commands are used in transmission channel
    543       opening and closing:
    544 
    545          HELO <SP> <domain> <CRLF>
    546 
    547          QUIT <CRLF>
    548 
    549       In the HELO command the host sending the command identifies
    550       itself; the command may be interpreted as saying "Hello, I am
    551       <domain>".
    552 
    553       -------------------------------------------------------------
    554 
    555                      Example of Connection Opening
    556 
    557          R: 220 BBN-UNIX.ARPA Simple Mail Transfer Service Ready
    558          S: HELO USC-ISIF.ARPA
    559          R: 250 BBN-UNIX.ARPA
    560 
    561                                Example 5
    562 
    563       -------------------------------------------------------------
    564 
    565       -------------------------------------------------------------
    566 
    567                      Example of Connection Closing
    568 
    569          S: QUIT
    570          R: 221 BBN-UNIX.ARPA Service closing transmission channel
    571 
    572                                Example 6
    573 
    574       -------------------------------------------------------------
    575 
    576 August 1982                                                      _R_F_C_ _8_2_1
    577 Simple Mail Transfer Protocol
    578 
    579    3.6.  RELAYING
    580 
    581       The forward-path may be a source route of the form
    582       "@ONE,@TWO:JOE@THREE", where ONE, TWO, and THREE are hosts.  This
    583       form is used to emphasize the distinction between an address and a
    584       route.  The mailbox is an absolute address, and the route is
    585       information about how to get there.  The two concepts should not
    586       be confused.
    587 
    588       Conceptually the elements of the forward-path are moved to the
    589       reverse-path as the message is relayed from one server-SMTP to
    590       another.  The reverse-path is a reverse source route, (i.e., a
    591       source route from the current location of the message to the
    592       originator of the message).  When a server-SMTP deletes its
    593       identifier from the forward-path and inserts it into the
    594       reverse-path, it must use the name it is known by in the
    595       environment it is sending into, not the environment the mail came
    596       from, in case the server-SMTP is known by different names in
    597       different environments.
    598 
    599       If when the message arrives at an SMTP the first element of the
    600       forward-path is not the identifier of that SMTP the element is not
    601       deleted from the forward-path and is used to determine the next
    602       SMTP to send the message to.  In any case, the SMTP adds its own
    603       identifier to the reverse-path.
    604 
    605       Using source routing the receiver-SMTP receives mail to be relayed
    606       to another server-SMTP  The receiver-SMTP may accept or reject the
    607       task of relaying the mail in the same way it accepts or rejects
    608       mail for a local user.  The receiver-SMTP transforms the command
    609       arguments by moving its own identifier from the forward-path to
    610       the beginning of the reverse-path.  The receiver-SMTP then becomes
    611       a sender-SMTP, establishes a transmission channel to the next SMTP
    612       in the forward-path, and sends it the mail.
    613 
    614       The first host in the reverse-path should be the host sending the
    615       SMTP commands, and the first host in the forward-path should be
    616       the host receiving the SMTP commands.
    617 
    618       Notice that the forward-path and reverse-path appear in the SMTP
    619       commands and replies, but not necessarily in the message.  That
    620       is, there is no need for these paths and especially this syntax to
    621       appear in the "To:" , "From:", "CC:", etc. fields of the message
    622       header.
    623 
    624       If a server-SMTP has accepted the task of relaying the mail and
    625 
    626 _R_F_C_ _8_2_1                                                      August 1982
    627                                            Simple Mail Transfer Protocol
    628 
    629       later finds that the forward-path is incorrect or that the mail
    630       cannot be delivered for whatever reason, then it must construct an
    631       "undeliverable mail" notification message and send it to the
    632       originator of the undeliverable mail (as indicated by the
    633       reverse-path).
    634 
    635       This notification message must be from the server-SMTP at this
    636       host.  Of course, server-SMTPs should not send notification
    637       messages about problems with notification messages.  One way to
    638       prevent loops in error reporting is to specify a null reverse-path
    639       in the MAIL command of a notification message.  When such a
    640       message is relayed it is permissible to leave the reverse-path
    641       null.  A MAIL command with a null reverse-path appears as follows:
    642 
    643          MAIL FROM:<>
    644 
    645       An undeliverable mail notification message is shown in example 7.
    646       This notification is in response to a message originated by JOE at
    647       HOSTW and sent via HOSTX to HOSTY with instructions to relay it on
    648       to HOSTZ.  What we see in the example is the transaction between
    649       HOSTY and HOSTX, which is the first step in the return of the
    650       notification message.
    651 
    652 August 1982                                                      _R_F_C_ _8_2_1
    653 Simple Mail Transfer Protocol
    654 
    655       -------------------------------------------------------------
    656 
    657             Example Undeliverable Mail Notification Message
    658 
    659          S: MAIL FROM:<>
    660          R: 250 ok
    661          S: RCPT TO:<@HOSTX.ARPA:_J_O_E_@_H_O_S_T_W_._A_R_P_A>
    662          R: 250 ok
    663          S: DATA
    664          R: 354 send the mail data, end with .
    665          S: Date: 23 Oct 81 11:22:33
    666          S: From: _S_M_T_P_@_H_O_S_T_Y_._A_R_P_A
    667          S: To: _J_O_E_@_H_O_S_T_W_._A_R_P_A
    668          S: Subject: Mail System Problem
    669          S:
    670          S:   Sorry JOE, your message to _S_A_M_@_H_O_S_T_Z_._A_R_P_A lost.
    671          S:   HOSTZ.ARPA said this:
    672          S:    "550 No Such User"
    673          S: .
    674          R: 250 ok
    675 
    676                                Example 7
    677 
    678       -------------------------------------------------------------
    679 
    680 _R_F_C_ _8_2_1                                                      August 1982
    681                                            Simple Mail Transfer Protocol
    682 
    683    3.7.  DOMAINS
    684 
    685       Domains are a recently introduced concept in the ARPA Internet
    686       mail system.  The use of domains changes the address space from a
    687       flat global space of simple character string host names to a
    688       hierarchically structured rooted tree of global addresses.  The
    689       host name is replaced by a domain and host designator which is a
    690       sequence of domain element strings separated by periods with the
    691       understanding that the domain elements are ordered from the most
    692       specific to the most general.
    693 
    694       For example, "USC-ISIF.ARPA", "Fred.Cambridge.UK", and
    695       "PC7.LCS.MIT.ARPA" might be host-and-domain identifiers.
    696 
    697       Whenever domain names are used in SMTP only the official names are
    698       used, the use of nicknames or aliases is not allowed.
    699 
    700 August 1982                                                      _R_F_C_ _8_2_1
    701 Simple Mail Transfer Protocol
    702 
    703    3.8.  CHANGING ROLES
    704 
    705       The TURN command may be used to reverse the roles of the two
    706       programs communicating over the transmission channel.
    707 
    708       If program-A is currently the sender-SMTP and it sends the TURN
    709       command and receives an ok reply (250) then program-A becomes the
    710       receiver-SMTP.
    711 
    712       If program-B is currently the receiver-SMTP and it receives the
    713       TURN command and sends an ok reply (250) then program-B becomes
    714       the sender-SMTP.
    715 
    716       To refuse to change roles the receiver sends the 502 reply.
    717 
    718       Please note that this command is optional.  It would not normally
    719       be used in situations where the transmission channel is TCP.
    720       However, when the cost of establishing the transmission channel is
    721       high, this command may be quite useful.  For example, this command
    722       may be useful in supporting be mail exchange using the public
    723       switched telephone system as a transmission channel, especially if
    724       some hosts poll other hosts for mail exchanges.
    725 
    726 _R_F_C_ _8_2_1                                                      August 1982
    727                                            Simple Mail Transfer Protocol
    728 
    729 4.  THE SMTP SPECIFICATIONS
    730 
    731    4.1.  SMTP COMMANDS
    732 
    733       4.1.1.  COMMAND SEMANTICS
    734 
    735          The SMTP commands define the mail transfer or the mail system
    736          function requested by the user.  SMTP commands are character
    737          strings terminated by <CRLF>.  The command codes themselves are
    738          alphabetic characters terminated by <SP> if parameters follow
    739          and <CRLF> otherwise.  The syntax of mailboxes must conform to
    740          receiver site conventions.  The SMTP commands are discussed
    741          below.  The SMTP replies are discussed in the Section 4.2.
    742 
    743          A mail transaction involves several data objects which are
    744          communicated as arguments to different commands.  The
    745          reverse-path is the argument of the MAIL command, the
    746          forward-path is the argument of the RCPT command, and the mail
    747          data is the argument of the DATA command.  These arguments or
    748          data objects must be transmitted and held pending the
    749          confirmation communicated by the end of mail data indication
    750          which finalizes the transaction.  The model for this is that
    751          distinct buffers are provided to hold the types of data
    752          objects, that is, there is a reverse-path buffer, a
    753          forward-path buffer, and a mail data buffer.  Specific commands
    754          cause information to be appended to a specific buffer, or cause
    755          one or more buffers to be cleared.
    756 
    757          HELLO (HELO)
    758 
    759             This command is used to identify the sender-SMTP to the
    760             receiver-SMTP.  The argument field contains the host name of
    761             the sender-SMTP.
    762 
    763             The receiver-SMTP identifies itself to the sender-SMTP in
    764             the connection greeting reply, and in the response to this
    765             command.
    766 
    767             This command and an OK reply to it confirm that both the
    768             sender-SMTP and the receiver-SMTP are in the initial state,
    769             that is, there is no transaction in progress and all state
    770             tables and buffers are cleared.
    771 
    772 August 1982                                                      _R_F_C_ _8_2_1
    773 Simple Mail Transfer Protocol
    774 
    775          MAIL (MAIL)
    776 
    777             This command is used to initiate a mail transaction in which
    778             the mail data is delivered to one or more mailboxes.  The
    779             argument field contains a reverse-path.
    780 
    781             The reverse-path consists of an optional list of hosts and
    782             the sender mailbox.  When the list of hosts is present, it
    783             is a "reverse" source route and indicates that the mail was
    784             relayed through each host on the list (the first host in the
    785             list was the most recent relay).  This list is used as a
    786             source route to return non-delivery notices to the sender.
    787             As each relay host adds itself to the beginning of the list,
    788             it must use its name as known in the IPCE to which it is
    789             relaying the mail rather than the IPCE from which the mail
    790             came (if they are different).  In some types of error
    791             reporting messages (for example, undeliverable mail
    792             notifications) the reverse-path may be null (see Example 7).
    793 
    794             This command clears the reverse-path buffer, the
    795             forward-path buffer, and the mail data buffer; and inserts
    796             the reverse-path information from this command into the
    797             reverse-path buffer.
    798 
    799          RECIPIENT (RCPT)
    800 
    801             This command is used to identify an individual recipient of
    802             the mail data; multiple recipients are specified by multiple
    803             use of this command.
    804 
    805             The forward-path consists of an optional list of hosts and a
    806             required destination mailbox.  When the list of hosts is
    807             present, it is a source route and indicates that the mail
    808             must be relayed to the next host on the list.  If the
    809             receiver-SMTP does not implement the relay function it may
    810             user the same reply it would for an unknown local user
    811             (550).
    812 
    813             When mail is relayed, the relay host must remove itself from
    814             the beginning forward-path and put itself at the beginning
    815             of the reverse-path.  When mail reaches its ultimate
    816             destination (the forward-path contains only a destination
    817             mailbox), the receiver-SMTP inserts it into the destination
    818             mailbox in accordance with its host mail conventions.
    819 
    820 _R_F_C_ _8_2_1                                                      August 1982
    821                                            Simple Mail Transfer Protocol
    822 
    823                For example, mail received at relay host A with arguments
    824 
    825                   FROM:<_U_S_E_R_X_@_H_O_S_T_Y_._A_R_P_A>
    826                   TO:<@HOSTA.ARPA,@HOSTB.ARPA:_U_S_E_R_C_@_H_O_S_T_D_._A_R_P_A>
    827 
    828                will be relayed on to host B with arguments
    829 
    830                   FROM:<@HOSTA.ARPA:_U_S_E_R_X_@_H_O_S_T_Y_._A_R_P_A>
    831                   TO:<@HOSTB.ARPA:_U_S_E_R_C_@_H_O_S_T_D_._A_R_P_A>.
    832 
    833             This command causes its forward-path argument to be appended
    834             to the forward-path buffer.
    835 
    836          DATA (DATA)
    837 
    838             The receiver treats the lines following the command as mail
    839             data from the sender.  This command causes the mail data
    840             from this command to be appended to the mail data buffer.
    841             The mail data may contain any of the 128 ASCII character
    842             codes.
    843 
    844             The mail data is terminated by a line containing only a
    845             period, that is the character sequence "<CRLF>.<CRLF>" (see
    846             Section 4.5.2 on Transparency).  This is the end of mail
    847             data indication.
    848 
    849             The end of mail data indication requires that the receiver
    850             must now process the stored mail transaction information.
    851             This processing consumes the information in the reverse-path
    852             buffer, the forward-path buffer, and the mail data buffer,
    853             and on the completion of this command these buffers are
    854             cleared.  If the processing is successful the receiver must
    855             send an OK reply.  If the processing fails completely the
    856             receiver must send a failure reply.
    857 
    858             When the receiver-SMTP accepts a message either for relaying
    859             or for final delivery it inserts at the beginning of the
    860             mail data a time stamp line.  The time stamp line indicates
    861             the identity of the host that sent the message, and the
    862             identity of the host that received the message (and is
    863             inserting this time stamp), and the date and time the
    864             message was received.  Relayed messages will have multiple
    865             time stamp lines.
    866 
    867             When the receiver-SMTP makes the "final delivery" of a
    868             message it inserts at the beginning of the mail data a
    869 
    870 August 1982                                                      _R_F_C_ _8_2_1
    871 Simple Mail Transfer Protocol
    872 
    873             return path line.  The return path line preserves the
    874             information in the <reverse-path> from the MAIL command.
    875             Here, final delivery means the message leaves the SMTP
    876             world.  Normally, this would mean it has been delivered to
    877             the destination user, but in some cases it may be further
    878             processed and transmitted by another mail system.
    879 
    880                It is possible for the mailbox in the return path be
    881                different from the actual sender's mailbox, for example,
    882                if error responses are to be delivered a special error
    883                handling mailbox rather than the message senders.
    884 
    885             The preceding two paragraphs imply that the final mail data
    886             will begin with a  return path line, followed by one or more
    887             time stamp lines.  These lines will be followed by the mail
    888             data header and body [2].  See Example 8.
    889 
    890             Special mention is needed of the response and further action
    891             required when the processing following the end of mail data
    892             indication is partially successful.  This could arise if
    893             after accepting several recipients and the mail data, the
    894             receiver-SMTP finds that the mail data can be successfully
    895             delivered to some of the recipients, but it cannot be to
    896             others (for example, due to mailbox space allocation
    897             problems).  In such a situation, the response to the DATA
    898             command must be an OK reply.  But, the receiver-SMTP must
    899             compose and send an "undeliverable mail" notification
    900             message to the originator of the message.  Either a single
    901             notification which lists all of the recipients that failed
    902             to get the message, or separate notification messages must
    903             be sent for each failed recipient (see Example 7).  All
    904             undeliverable mail notification messages are sent using the
    905             MAIL command (even if they result from processing a SEND,
    906             SOML, or SAML command).
    907 
    908 _R_F_C_ _8_2_1                                                      August 1982
    909                                            Simple Mail Transfer Protocol
    910 
    911      -------------------------------------------------------------
    912 
    913             Example of Return Path and Received Time Stamps
    914 
    915       Return-Path: <@GHI.ARPA,@DEF.ARPA,@ABC.ARPA:_J_O_E_@_A_B_C_._A_R_P_A>
    916       Received: from GHI.ARPA by JKL.ARPA ; 27 Oct 81 15:27:39 PST
    917       Received: from DEF.ARPA by GHI.ARPA ; 27 Oct 81 15:15:13 PST
    918       Received: from ABC.ARPA by DEF.ARPA ; 27 Oct 81 15:01:59 PST
    919       Date: 27 Oct 81 15:01:01 PST
    920       From: _J_O_E_@_A_B_C_._A_R_P_A
    921       Subject: Improved Mailing System Installed
    922       To: _S_A_M_@_J_K_L_._A_R_P_A
    923 
    924       This is to inform you that ...
    925 
    926                                Example 8
    927 
    928      -------------------------------------------------------------
    929 
    930          SEND (SEND)
    931 
    932             This command is used to initiate a mail transaction in which
    933             the mail data is delivered to one or more terminals.  The
    934             argument field contains a reverse-path.  This command is
    935             successful if the message is delivered to a terminal.
    936 
    937             The reverse-path consists of an optional list of hosts and
    938             the sender mailbox.  When the list of hosts is present, it
    939             is a "reverse" source route and indicates that the mail was
    940             relayed through each host on the list (the first host in the
    941             list was the most recent relay).  This list is used as a
    942             source route to return non-delivery notices to the sender.
    943             As each relay host adds itself to the beginning of the list,
    944             it must use its name as known in the IPCE to which it is
    945             relaying the mail rather than the IPCE from which the mail
    946             came (if they are different).
    947 
    948             This command clears the reverse-path buffer, the
    949             forward-path buffer, and the mail data buffer; and inserts
    950             the reverse-path information from this command into the
    951             reverse-path buffer.
    952 
    953          SEND OR MAIL (SOML)
    954 
    955             This command is used to initiate a mail transaction in which
    956             the mail data is delivered to one or more terminals or
    957 
    958 August 1982                                                      _R_F_C_ _8_2_1
    959 Simple Mail Transfer Protocol
    960 
    961             mailboxes. For each recipient the mail data is delivered to
    962             the recipient's terminal if the recipient is active on the
    963             host (and accepting terminal messages), otherwise to the
    964             recipient's mailbox.  The argument field contains a
    965             reverse-path.  This command is successful if the message is
    966             delivered to a terminal or the mailbox.
    967 
    968             The reverse-path consists of an optional list of hosts and
    969             the sender mailbox.  When the list of hosts is present, it
    970             is a "reverse" source route and indicates that the mail was
    971             relayed through each host on the list (the first host in the
    972             list was the most recent relay).  This list is used as a
    973             source route to return non-delivery notices to the sender.
    974             As each relay host adds itself to the beginning of the list,
    975             it must use its name as known in the IPCE to which it is
    976             relaying the mail rather than the IPCE from which the mail
    977             came (if they are different).
    978 
    979             This command clears the reverse-path buffer, the
    980             forward-path buffer, and the mail data buffer; and inserts
    981             the reverse-path information from this command into the
    982             reverse-path buffer.
    983 
    984          SEND AND MAIL (SAML)
    985 
    986             This command is used to initiate a mail transaction in which
    987             the mail data is delivered to one or more terminals and
    988             mailboxes. For each recipient the mail data is delivered to
    989             the recipient's terminal if the recipient is active on the
    990             host (and accepting terminal messages), and for all
    991             recipients to the recipient's mailbox.  The argument field
    992             contains a reverse-path.  This command is successful if the
    993             message is delivered to the mailbox.
    994 
    995             The reverse-path consists of an optional list of hosts and
    996             the sender mailbox.  When the list of hosts is present, it
    997             is a "reverse" source route and indicates that the mail was
    998             relayed through each host on the list (the first host in the
    999             list was the most recent relay).  This list is used as a
   1000             source route to return non-delivery notices to the sender.
   1001             As each relay host adds itself to the beginning of the list,
   1002             it must use its name as known in the IPCE to which it is
   1003             relaying the mail rather than the IPCE from which the mail
   1004             came (if they are different).
   1005 
   1006             This command clears the reverse-path buffer, the
   1007 
   1008 _R_F_C_ _8_2_1                                                      August 1982
   1009                                            Simple Mail Transfer Protocol
   1010 
   1011             forward-path buffer, and the mail data buffer; and inserts
   1012             the reverse-path information from this command into the
   1013             reverse-path buffer.
   1014 
   1015          RESET (RSET)
   1016 
   1017             This command specifies that the current mail transaction is
   1018             to be aborted.  Any stored sender, recipients, and mail data
   1019             must be discarded, and all buffers and state tables cleared.
   1020             The receiver must send an OK reply.
   1021 
   1022          VERIFY (VRFY)
   1023 
   1024             This command asks the receiver to confirm that the argument
   1025             identifies a user.  If it is a user name, the full name of
   1026             the user (if known) and the fully specified mailbox are
   1027             returned.
   1028 
   1029             This command has no effect on any of the reverse-path
   1030             buffer, the forward-path buffer, or the mail data buffer.
   1031 
   1032          EXPAND (EXPN)
   1033 
   1034             This command asks the receiver to confirm that the argument
   1035             identifies a mailing list, and if so, to return the
   1036             membership of that list.  The full name of the users (if
   1037             known) and the fully specified mailboxes are returned in a
   1038             multiline reply.
   1039 
   1040             This command has no effect on any of the reverse-path
   1041             buffer, the forward-path buffer, or the mail data buffer.
   1042 
   1043          HELP (HELP)
   1044 
   1045             This command causes the receiver to send helpful information
   1046             to the sender of the HELP command.  The command may take an
   1047             argument (e.g., any command name) and return more specific
   1048             information as a response.
   1049 
   1050             This command has no effect on any of the reverse-path
   1051             buffer, the forward-path buffer, or the mail data buffer.
   1052 
   1053 August 1982                                                      _R_F_C_ _8_2_1
   1054 Simple Mail Transfer Protocol
   1055 
   1056          NOOP (NOOP)
   1057 
   1058             This command does not affect any parameters or previously
   1059             entered commands.  It specifies no action other than that
   1060             the receiver send an OK reply.
   1061 
   1062             This command has no effect on any of the reverse-path
   1063             buffer, the forward-path buffer, or the mail data buffer.
   1064 
   1065          QUIT (QUIT)
   1066 
   1067             This command specifies that the receiver must send an OK
   1068             reply, and then close the transmission channel.
   1069 
   1070             The receiver should not close the transmission channel until
   1071             it receives and replies to a QUIT command (even if there was
   1072             an error).  The sender should not close the transmission
   1073             channel until it send a QUIT command and receives the reply
   1074             (even if there was an error response to a previous command).
   1075             If the connection is closed prematurely the receiver should
   1076             act as if a RSET command had been received (canceling any
   1077             pending transaction, but not undoing any previously
   1078             completed transaction), the sender should act as if the
   1079             command or transaction in progress had received a temporary
   1080             error (4xx).
   1081 
   1082          TURN (TURN)
   1083 
   1084             This command specifies that the receiver must either (1)
   1085             send an OK reply and then take on the role of the
   1086             sender-SMTP, or (2) send a refusal reply and retain the role
   1087             of the receiver-SMTP.
   1088 
   1089             If program-A is currently the sender-SMTP and it sends the
   1090             TURN command and receives an OK reply (250) then program-A
   1091             becomes the receiver-SMTP.  Program-A is then in the initial
   1092             state as if the transmission channel just opened, and it
   1093             then sends the 220 service ready greeting.
   1094 
   1095             If program-B is currently the receiver-SMTP and it receives
   1096             the TURN command and sends an OK reply (250) then program-B
   1097             becomes the sender-SMTP.  Program-B is then in the initial
   1098             state as if the transmission channel just opened, and it
   1099             then expects to receive the 220 service ready greeting.
   1100 
   1101             To refuse to change roles the receiver sends the 502 reply.
   1102 
   1103 _R_F_C_ _8_2_1                                                      August 1982
   1104                                            Simple Mail Transfer Protocol
   1105 
   1106          There are restrictions on the order in which these command may
   1107          be used.
   1108 
   1109             The first command in a session must be the HELO command.
   1110             The HELO command may be used later in a session as well.  If
   1111             the HELO command argument is not acceptable a 501 failure
   1112             reply must be returned and the receiver-SMTP must stay in
   1113             the same state.
   1114 
   1115             The NOOP, HELP, EXPN, and VRFY commands can be used at any
   1116             time during a session.
   1117 
   1118             The MAIL, SEND, SOML, or SAML commands begin a mail
   1119             transaction.  Once started a mail transaction consists of
   1120             one of the transaction beginning commands, one or more RCPT
   1121             commands, and a DATA command, in that order.  A mail
   1122             transaction may be aborted by the RSET command.  There may
   1123             be zero or more transactions in a session.
   1124 
   1125             If the transaction beginning command argument is not
   1126             acceptable a 501 failure reply must be returned and the
   1127             receiver-SMTP must stay in the same state.  If the commands
   1128             in a transaction are out of order a 503 failure reply must
   1129             be returned and the receiver-SMTP must stay in the same
   1130             state.
   1131 
   1132             The last command in a session must be the QUIT command.  The
   1133             QUIT command can not be used at any other time in a session.
   1134 
   1135       4.1.2.  COMMAND SYNTAX
   1136 
   1137          The commands consist of a command code followed by an argument
   1138          field.  Command codes are four alphabetic characters.  Upper
   1139          and lower case alphabetic characters are to be treated
   1140          identically.  Thus, any of the following may represent the mail
   1141          command:
   1142 
   1143             MAIL    Mail    mail    MaIl    mAIl
   1144 
   1145          This also applies to any symbols representing parameter values,
   1146          such as "TO" or "to" for the forward-path.  Command codes and
   1147          the argument fields are separated by one or more spaces.
   1148          However, within the reverse-path and forward-path arguments
   1149          case is important.  In particular, in some hosts the user
   1150          "smith" is different from the user "Smith".
   1151 
   1152 August 1982                                                      _R_F_C_ _8_2_1
   1153 Simple Mail Transfer Protocol
   1154 
   1155          The argument field consists of a variable length character
   1156          string ending with the character sequence <CRLF>.  The receiver
   1157          is to take no action until this sequence is received.
   1158 
   1159          Square brackets denote an optional argument field.  If the
   1160          option is not taken, the appropriate default is implied.
   1161 
   1162 _R_F_C_ _8_2_1                                                      August 1982
   1163                                            Simple Mail Transfer Protocol
   1164 
   1165          The following are the SMTP commands:
   1166 
   1167             HELO <SP> <domain> <CRLF>
   1168 
   1169             MAIL <SP> FROM:<reverse-path> <CRLF>
   1170 
   1171             RCPT <SP> TO:<forward-path> <CRLF>
   1172 
   1173             DATA <CRLF>
   1174 
   1175             RSET <CRLF>
   1176 
   1177             SEND <SP> FROM:<reverse-path> <CRLF>
   1178 
   1179             SOML <SP> FROM:<reverse-path> <CRLF>
   1180 
   1181             SAML <SP> FROM:<reverse-path> <CRLF>
   1182 
   1183             VRFY <SP> <string> <CRLF>
   1184 
   1185             EXPN <SP> <string> <CRLF>
   1186 
   1187             HELP [<SP> <string>] <CRLF>
   1188 
   1189             NOOP <CRLF>
   1190 
   1191             QUIT <CRLF>
   1192 
   1193             TURN <CRLF>
   1194 
   1195 August 1982                                                      _R_F_C_ _8_2_1
   1196 Simple Mail Transfer Protocol
   1197 
   1198          The syntax of the above argument fields (using BNF notation
   1199          where applicable) is given below.  The "..." notation indicates
   1200          that a field may be repeated one or more times.
   1201 
   1202             <reverse-path> ::= <path>
   1203 
   1204             <forward-path> ::= <path>
   1205 
   1206             <path> ::= "<" [ <a-d-l> ":" ] <mailbox> ">"
   1207 
   1208             <a-d-l> ::= <at-domain> | <at-domain> "," <a-d-l>
   1209 
   1210             <at-domain> ::= "@" <domain>
   1211 
   1212             <domain> ::=  <element> | <element> "." <domain>
   1213 
   1214             <element> ::= <name> | "#" <number> | "[" <dotnum> "]"
   1215 
   1216             <mailbox> ::= <local-part> "@" <domain>
   1217 
   1218             <local-part> ::= <dot-string> | <quoted-string>
   1219 
   1220             <name> ::= <a> <ldh-str> <let-dig>
   1221 
   1222             <ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
   1223 
   1224             <let-dig> ::= <a> | <d>
   1225 
   1226             <let-dig-hyp> ::= <a> | <d> | "-"
   1227 
   1228             <dot-string> ::= <string> | <string> "." <dot-string>
   1229 
   1230             <string> ::= <char> | <char> <string>
   1231 
   1232             <quoted-string> ::=  """ <qtext> """
   1233 
   1234             <qtext> ::=  "\" <x> | "\" <x> <qtext> | <q> | <q> <qtext>
   1235 
   1236             <char> ::= <c> | "\" <x>
   1237 
   1238             <dotnum> ::= <snum> "." <snum> "." <snum> "." <snum>
   1239 
   1240             <number> ::= <d> | <d> <number>
   1241 
   1242             <CRLF> ::= <CR> <LF>
   1243 
   1244 _R_F_C_ _8_2_1                                                      August 1982
   1245                                            Simple Mail Transfer Protocol
   1246 
   1247             <CR> ::= the carriage return character (ASCII code 13)
   1248 
   1249             <LF> ::= the line feed character (ASCII code 10)
   1250 
   1251             <SP> ::= the space character (ASCII code 32)
   1252 
   1253             <snum> ::= one, two, or three digits representing a decimal
   1254                       integer value in the range 0 through 255
   1255 
   1256             <a> ::= any one of the 52 alphabetic characters A through Z
   1257                       in upper case and a through z in lower case
   1258 
   1259             <c> ::= any one of the 128 ASCII characters, but not any
   1260                       <special> or <SP>
   1261 
   1262             <d> ::= any one of the ten digits 0 through 9
   1263 
   1264             <q> ::= any one of the 128 ASCII characters except <CR>,
   1265                       <LF>, quote ("), or backslash (\)
   1266 
   1267             <x> ::= any one of the 128 ASCII characters (no exceptions)
   1268 
   1269             <special> ::= "<" | ">" | "(" | ")" | "[" | "]" | "\" | "."
   1270                       | "," | ";" | ":" | "@"  """ | the control
   1271                       characters (ASCII codes 0 through 31 inclusive and
   1272                       127)
   1273 
   1274          Note that the backslash, "\", is a quote character, which is
   1275          used to indicate that the next character is to be used
   1276          literally (instead of its normal interpretation).  For example,
   1277          "Joe\,Smith" could be used to indicate a single nine character
   1278          user field with comma being the fourth character of the field.
   1279 
   1280          Hosts are generally known by names which are translated to
   1281          addresses in each host.  Note that the name elements of domains
   1282          are the official names -- no use of nicknames or aliases is
   1283          allowed.
   1284 
   1285          Sometimes a host is not known to the translation function and
   1286          communication is blocked.  To bypass this barrier two numeric
   1287          forms are also allowed for host "names".  One form is a decimal
   1288          integer prefixed by a pound sign, "#", which indicates the
   1289          number is the address of the host.  Another form is four small
   1290          decimal integers separated by dots and enclosed by brackets,
   1291          e.g., "[123.255.37.2]", which indicates a 32-bit ARPA Internet
   1292          Address in four 8-bit fields.
   1293 
   1294 August 1982                                                      _R_F_C_ _8_2_1
   1295 Simple Mail Transfer Protocol
   1296 
   1297          The time stamp line and the return path line are formally
   1298          defined as follows:
   1299 
   1300          <return-path-line> ::= "Return-Path:" <SP><reverse-path><CRLF>
   1301 
   1302          <time-stamp-line> ::= "Received:" <SP> <stamp> <CRLF>
   1303 
   1304             <stamp> ::= <from-domain> <by-domain> <opt-info> ";"
   1305                       <daytime>
   1306 
   1307             <from-domain> ::= "FROM" <SP> <domain> <SP>
   1308 
   1309             <by-domain> ::= "BY" <SP> <domain> <SP>
   1310 
   1311             <opt-info> ::= [<via>] [<with>] [<id>] [<for>]
   1312 
   1313             <via> ::= "VIA" <SP> <link> <SP>
   1314 
   1315             <with> ::= "WITH" <SP> <protocol> <SP>
   1316 
   1317             <id> ::= "ID" <SP> <string> <SP>
   1318 
   1319             <for> ::= "FOR" <SP> <path> <SP>
   1320 
   1321             <link> ::= The standard names for links are registered with
   1322                       the Network Information Center.
   1323 
   1324             <protocol> ::= The standard names for protocols are
   1325                       registered with the Network Information Center.
   1326 
   1327             <daytime> ::= <SP> <date> <SP> <time>
   1328 
   1329             <date> ::= <dd> <SP> <mon> <SP> <yy>
   1330 
   1331             <time> ::= <hh> ":" <mm> ":" <ss> <SP> <zone>
   1332 
   1333             <dd> ::= the one or two decimal integer day of the month in
   1334                       the range 1 to 31.
   1335 
   1336             <mon> ::= "JAN" | "FEB" | "MAR" | "APR" | "MAY" | "JUN" |
   1337                       "JUL" | "AUG" | "SEP" | "OCT" | "NOV" | "DEC"
   1338 
   1339             <yy> ::= the two decimal integer year of the century in the
   1340                       range 00 to 99.
   1341 
   1342 _R_F_C_ _8_2_1                                                      August 1982
   1343                                            Simple Mail Transfer Protocol
   1344 
   1345             <hh> ::= the two decimal integer hour of the day in the
   1346                       range 00 to 24.
   1347 
   1348             <mm> ::= the two decimal integer minute of the hour in the
   1349                       range 00 to 59.
   1350 
   1351             <ss> ::= the two decimal integer second of the minute in the
   1352                       range 00 to 59.
   1353 
   1354             <zone> ::= "UT" for Universal Time (the default) or other
   1355                       time zone designator (as in [2]).
   1356 
   1357      -------------------------------------------------------------
   1358 
   1359                           Return Path Example
   1360 
   1361          Return-Path: <@CHARLIE.ARPA,@BAKER.ARPA:_J_O_E_@_A_B_L_E_._A_R_P_A>
   1362 
   1363                                Example 9
   1364 
   1365      -------------------------------------------------------------
   1366 
   1367      -------------------------------------------------------------
   1368 
   1369                         Time Stamp Line Example
   1370 
   1371       Received: FROM ABC.ARPA BY XYZ.ARPA ; 22 OCT 81 09:23:59 PDT
   1372 
   1373          Received: from ABC.ARPA by XYZ.ARPA via TELENET with X25
   1374                    id M12345 for _S_m_i_t_h_@_P_D_Q_._A_R_P_A ; 22 OCT 81 09:23:59 PDT
   1375 
   1376                                Example 10
   1377 
   1378       -------------------------------------------------------------
   1379 
   1380 August 1982                                                      _R_F_C_ _8_2_1
   1381 Simple Mail Transfer Protocol
   1382 
   1383    4.2.  SMTP REPLIES
   1384 
   1385       Replies to SMTP commands are devised to ensure the synchronization
   1386       of requests and actions in the process of mail transfer, and to
   1387       guarantee that the sender-SMTP always knows the state of the
   1388       receiver-SMTP.  Every command must generate exactly one reply.
   1389 
   1390          The details of the command-reply sequence are made explicit in
   1391          Section 5.3 on Sequencing and Section 5.4 State Diagrams.
   1392 
   1393       An SMTP reply consists of a three digit number (transmitted as
   1394       three alphanumeric characters) followed by some text.  The number
   1395       is intended for use by automata to determine what state to enter
   1396       next; the text is meant for the human user.  It is intended that
   1397       the three digits contain enough encoded information that the
   1398       sender-SMTP need not examine the text and may either discard it or
   1399       pass it on to the user, as appropriate.  In particular, the text
   1400       may be receiver-dependent and context dependent, so there are
   1401       likely to be varying texts for each reply code.  A discussion of
   1402       the theory of reply codes is given in Appendix E.  Formally, a
   1403       reply is defined to be the sequence:  a three-digit code, <SP>,
   1404       one line of text, and <CRLF>, or a multiline reply (as defined in
   1405       Appendix E).  Only the EXPN and HELP commands are expected to
   1406       result in multiline replies in normal circumstances, however
   1407       multiline replies are allowed for any command.
   1408 
   1409 _R_F_C_ _8_2_1                                                      August 1982
   1410                                            Simple Mail Transfer Protocol
   1411 
   1412       4.2.1.  REPLY CODES BY FUNCTION GROUPS
   1413 
   1414          500 Syntax error, command unrecognized
   1415             [This may include errors such as command line too long]
   1416          501 Syntax error in parameters or arguments
   1417          502 Command not implemented
   1418          503 Bad sequence of commands
   1419          504 Command parameter not implemented
   1420 
   1421          211 System status, or system help reply
   1422          214 Help message
   1423             [Information on how to use the receiver or the meaning of a
   1424             particular non-standard command; this reply is useful only
   1425             to the human user]
   1426 
   1427          220 <domain> Service ready
   1428          221 <domain> Service closing transmission channel
   1429          421 <domain> Service not available,
   1430              closing transmission channel
   1431             [This may be a reply to any command if the service knows it
   1432             must shut down]
   1433 
   1434          250 Requested mail action okay, completed
   1435          251 User not local; will forward to <forward-path>
   1436          450 Requested mail action not taken: mailbox unavailable
   1437             [E.g., mailbox busy]
   1438          550 Requested action not taken: mailbox unavailable
   1439             [E.g., mailbox not found, no access]
   1440          451 Requested action aborted: error in processing
   1441          551 User not local; please try <forward-path>
   1442          452 Requested action not taken: insufficient system storage
   1443          552 Requested mail action aborted: exceeded storage allocation
   1444          553 Requested action not taken: mailbox name not allowed
   1445             [E.g., mailbox syntax incorrect]
   1446          354 Start mail input; end with <CRLF>.<CRLF>
   1447          554 Transaction failed
   1448 
   1449 August 1982                                                      _R_F_C_ _8_2_1
   1450 Simple Mail Transfer Protocol
   1451 
   1452       4.2.2.  NUMERIC ORDER LIST OF REPLY CODES
   1453 
   1454          211 System status, or system help reply
   1455          214 Help message
   1456             [Information on how to use the receiver or the meaning of a
   1457             particular non-standard command; this reply is useful only
   1458             to the human user]
   1459          220 <domain> Service ready
   1460          221 <domain> Service closing transmission channel
   1461          250 Requested mail action okay, completed
   1462          251 User not local; will forward to <forward-path>
   1463 
   1464          354 Start mail input; end with <CRLF>.<CRLF>
   1465 
   1466          421 <domain> Service not available,
   1467              closing transmission channel
   1468             [This may be a reply to any command if the service knows it
   1469             must shut down]
   1470          450 Requested mail action not taken: mailbox unavailable
   1471             [E.g., mailbox busy]
   1472          451 Requested action aborted: local error in processing
   1473          452 Requested action not taken: insufficient system storage
   1474 
   1475          500 Syntax error, command unrecognized
   1476             [This may include errors such as command line too long]
   1477          501 Syntax error in parameters or arguments
   1478          502 Command not implemented
   1479          503 Bad sequence of commands
   1480          504 Command parameter not implemented
   1481          550 Requested action not taken: mailbox unavailable
   1482             [E.g., mailbox not found, no access]
   1483          551 User not local; please try <forward-path>
   1484          552 Requested mail action aborted: exceeded storage allocation
   1485          553 Requested action not taken: mailbox name not allowed
   1486             [E.g., mailbox syntax incorrect]
   1487          554 Transaction failed
   1488 
   1489 _R_F_C_ _8_2_1                                                      August 1982
   1490                                            Simple Mail Transfer Protocol
   1491 
   1492    4.3.  SEQUENCING OF COMMANDS AND REPLIES
   1493 
   1494       The communication between the sender and receiver is intended to
   1495       be an alternating dialogue, controlled by the sender.  As such,
   1496       the sender issues a command and the receiver responds with a
   1497       reply.  The sender must wait for this response before sending
   1498       further commands.
   1499 
   1500       One important reply is the connection greeting.  Normally, a
   1501       receiver will send a 220 "Service ready" reply when the connection
   1502       is completed.  The sender should wait for this greeting message
   1503       before sending any commands.
   1504 
   1505          Note: all the greeting type replies have the official name of
   1506          the server host as the first word following the reply code.
   1507 
   1508             For example,
   1509 
   1510                220 <SP> USC-ISIF.ARPA <SP> Service ready <CRLF>
   1511 
   1512       The table below lists alternative success and failure replies for
   1513       each command.  These must be strictly adhered to; a receiver may
   1514       substitute text in the replies, but the meaning and action implied
   1515       by the code numbers and by the specific command reply sequence
   1516       cannot be altered.
   1517 
   1518       COMMAND-REPLY SEQUENCES
   1519 
   1520          Each command is listed with its possible replies.  The prefixes
   1521          used before the possible replies are "P" for preliminary (not
   1522          used in SMTP), "I" for intermediate, "S" for success, "F" for
   1523          failure, and "E" for error.  The 421 reply (service not
   1524          available, closing transmission channel) may be given to any
   1525          command if the SMTP-receiver knows it must shut down.  This
   1526          listing forms the basis for the State Diagrams in Section 4.4.
   1527 
   1528             CONNECTION ESTABLISHMENT
   1529                S: 220
   1530                F: 421
   1531             HELO
   1532                S: 250
   1533                E: 500, 501, 504, 421
   1534             MAIL
   1535                S: 250
   1536                F: 552, 451, 452
   1537                E: 500, 501, 421
   1538 
   1539 August 1982                                                      _R_F_C_ _8_2_1
   1540 Simple Mail Transfer Protocol
   1541 
   1542             RCPT
   1543                S: 250, 251
   1544                F: 550, 551, 552, 553, 450, 451, 452
   1545                E: 500, 501, 503, 421
   1546             DATA
   1547                I: 354 -> data -> S: 250
   1548                                  F: 552, 554, 451, 452
   1549                F: 451, 554
   1550                E: 500, 501, 503, 421
   1551             RSET
   1552                S: 250
   1553                E: 500, 501, 504, 421
   1554             SEND
   1555                S: 250
   1556                F: 552, 451, 452
   1557                E: 500, 501, 502, 421
   1558             SOML
   1559                S: 250
   1560                F: 552, 451, 452
   1561                E: 500, 501, 502, 421
   1562             SAML
   1563                S: 250
   1564                F: 552, 451, 452
   1565                E: 500, 501, 502, 421
   1566             VRFY
   1567                S: 250, 251
   1568                F: 550, 551, 553
   1569                E: 500, 501, 502, 504, 421
   1570             EXPN
   1571                S: 250
   1572                F: 550
   1573                E: 500, 501, 502, 504, 421
   1574             HELP
   1575                S: 211, 214
   1576                E: 500, 501, 502, 504, 421
   1577             NOOP
   1578                S: 250
   1579                E: 500, 421
   1580             QUIT
   1581                S: 221
   1582                E: 500
   1583             TURN
   1584                S: 250
   1585                F: 502
   1586                E: 500, 503
   1587 
   1588 _R_F_C_ _8_2_1                                                      August 1982
   1589                                            Simple Mail Transfer Protocol
   1590 
   1591    4.4.  STATE DIAGRAMS
   1592 
   1593       Following are state diagrams for a simple-minded SMTP
   1594       implementation.  Only the first digit of the reply codes is used.
   1595       There is one state diagram for each group of SMTP commands.  The
   1596       command groupings were determined by constructing a model for each
   1597       command and then collecting together the commands with
   1598       structurally identical models.
   1599 
   1600       For each command there are three possible outcomes:  "success"
   1601       (S), "failure" (F), and "error" (E). In the state diagrams below
   1602       we use the symbol B for "begin", and the symbol W for "wait for
   1603       reply".
   1604 
   1605       First, the diagram that represents most of the SMTP commands:
   1606 
   1607                                   1,3    +---+
   1608                              ----------->| E |
   1609                             |            +---+
   1610                             |
   1611          +---+    cmd    +---+    2      +---+
   1612          | B |---------->| W |---------->| S |
   1613          +---+           +---+           +---+
   1614                             |
   1615                             |     4,5    +---+
   1616                              ----------->| F |
   1617                                          +---+
   1618 
   1619          This diagram models the commands:
   1620 
   1621             HELO, MAIL, RCPT, RSET, SEND, SOML, SAML, VRFY, EXPN, HELP,
   1622             NOOP, QUIT, TURN.
   1623 
   1624 August 1982                                                      _R_F_C_ _8_2_1
   1625 Simple Mail Transfer Protocol
   1626 
   1627       A more complex diagram models the DATA command:
   1628 
   1629          +---+   DATA    +---+ 1,2                 +---+
   1630          | B |---------->| W |-------------------->| E |
   1631          +---+           +---+        ------------>+---+
   1632                          3| |4,5     |
   1633                           | |        |
   1634             --------------   -----   |
   1635            |                      |  |             +---+
   1636            |               ----------     -------->| S |
   1637            |              |       |      |         +---+
   1638            |              |  ------------
   1639            |              | |     |
   1640            V           1,3| |2    |
   1641          +---+   data    +---+     --------------->+---+
   1642          |   |---------->| W |                     | F |
   1643          +---+           +---+-------------------->+---+
   1644                               4,5
   1645 
   1646          Note that the "data" here is a series of lines sent from the
   1647          sender to the receiver with no response expected until the last
   1648          line is sent.
   1649 
   1650 _R_F_C_ _8_2_1                                                      August 1982
   1651                                            Simple Mail Transfer Protocol
   1652 
   1653    4.5.  DETAILS
   1654 
   1655       4.5.1.  MINIMUM IMPLEMENTATION
   1656 
   1657          In order to make SMTP workable, the following minimum
   1658          implementation is required for all receivers:
   1659 
   1660             COMMANDS -- HELO
   1661                         MAIL
   1662                         RCPT
   1663                         DATA
   1664                         RSET
   1665                         NOOP
   1666                         QUIT
   1667 
   1668       4.5.2.  TRANSPARENCY
   1669 
   1670          Without some provision for data transparency the character
   1671          sequence "<CRLF>.<CRLF>" ends the mail text and cannot be sent
   1672          by the user.  In general, users are not aware of such
   1673          "forbidden" sequences.  To allow all user composed text to be
   1674          transmitted transparently the following procedures are used.
   1675 
   1676             1. Before sending a line of mail text the sender-SMTP checks
   1677             the first character of the line.  If it is a period, one
   1678             additional period is inserted at the beginning of the line.
   1679 
   1680             2. When a line of mail text is received by the receiver-SMTP
   1681             it checks the line.  If the line is composed of a single
   1682             period it is the end of mail.  If the first character is a
   1683             period and there are other characters on the line, the first
   1684             character is deleted.
   1685 
   1686          The mail data may contain any of the 128 ASCII characters.  All
   1687          characters are to be delivered to the recipient's mailbox
   1688          including format effectors and other control characters.  If
   1689          the transmission channel provides an 8-bit byte (octets) data
   1690          stream, the 7-bit ASCII codes are transmitted right justified
   1691          in the octets with the high order bits cleared to zero.
   1692 
   1693             In some systems it may be necessary to transform the data as
   1694             it is received and stored.  This may be necessary for hosts
   1695             that use a different character set than ASCII as their local
   1696             character set, or that store data in records rather than
   1697 
   1698 August 1982                                                      _R_F_C_ _8_2_1
   1699 Simple Mail Transfer Protocol
   1700 
   1701             strings.  If such transforms are necessary, they must be
   1702             reversible -- especially if such transforms are applied to
   1703             mail being relayed.
   1704 
   1705       4.5.3.  SIZES
   1706 
   1707          There are several objects that have required minimum maximum
   1708          sizes.  That is, every implementation must be able to receive
   1709          objects of at least these sizes, but must not send objects
   1710          larger than these sizes.
   1711 
   1712           ****************************************************
   1713           *                                                  *
   1714           *  TO THE MAXIMUM EXTENT POSSIBLE, IMPLEMENTATION  *
   1715           *  TECHNIQUES WHICH IMPOSE NO LIMITS ON THE LENGTH *
   1716           *  OF THESE OBJECTS SHOULD BE USED.                *
   1717           *                                                  *
   1718           ****************************************************
   1719 
   1720             user
   1721 
   1722                The maximum total length of a user name is 64 characters.
   1723 
   1724             domain
   1725 
   1726                The maximum total length of a domain name or number is 64
   1727                characters.
   1728 
   1729             path
   1730 
   1731                The maximum total length of a reverse-path or
   1732                forward-path is 256 characters (including the punctuation
   1733                and element separators).
   1734 
   1735             command line
   1736 
   1737                The maximum total length of a command line including the
   1738                command word and the <CRLF> is 512 characters.
   1739 
   1740             reply line
   1741 
   1742                The maximum total length of a reply line including the
   1743                reply code and the <CRLF> is 512 characters.
   1744 
   1745 _R_F_C_ _8_2_1                                                      August 1982
   1746                                            Simple Mail Transfer Protocol
   1747 
   1748             text line
   1749 
   1750                The maximum total length of a text line including the
   1751                <CRLF> is 1000 characters (but not counting the leading
   1752                dot duplicated for transparency).
   1753 
   1754             recipients buffer
   1755 
   1756                The maximum total number of recipients that must be
   1757                buffered is 100 recipients.
   1758 
   1759           ****************************************************
   1760           *                                                  *
   1761           *  TO THE MAXIMUM EXTENT POSSIBLE, IMPLEMENTATION  *
   1762           *  TECHNIQUES WHICH IMPOSE NO LIMITS ON THE LENGTH *
   1763           *  OF THESE OBJECTS SHOULD BE USED.                *
   1764           *                                                  *
   1765           ****************************************************
   1766 
   1767          Errors due to exceeding these limits may be reported by using
   1768          the reply codes, for example:
   1769 
   1770             500 Line too long.
   1771 
   1772             501 Path too long
   1773 
   1774             552 Too many recipients.
   1775 
   1776             552 Too much mail data.
   1777 
   1778 August 1982                                                      _R_F_C_ _8_2_1
   1779 Simple Mail Transfer Protocol
   1780 
   1781 APPENDIX A
   1782 
   1783    TCP Transport service
   1784 
   1785       The Transmission Control Protocol [3] is used in the ARPA
   1786       Internet, and in any network following the US DoD standards for
   1787       internetwork protocols.
   1788 
   1789       Connection Establishment
   1790 
   1791          The SMTP transmission channel is a TCP connection established
   1792          between the sender process port U and the receiver process port
   1793          L.  This single full duplex connection is used as the
   1794          transmission channel.  This protocol is assigned the service
   1795          port 25 (31 octal), that is L=25.
   1796 
   1797       Data Transfer
   1798 
   1799          The TCP connection supports the transmission of 8-bit bytes.
   1800          The SMTP data is 7-bit ASCII characters.  Each character is
   1801          transmitted as an 8-bit byte with the high-order bit cleared to
   1802          zero.
   1803 
   1804 _R_F_C_ _8_2_1                                                      August 1982
   1805                                            Simple Mail Transfer Protocol
   1806 
   1807 APPENDIX B
   1808 
   1809    NCP Transport service
   1810 
   1811       The ARPANET Host-to-Host Protocol [4] (implemented by the Network
   1812       Control Program) may be used in the ARPANET.
   1813 
   1814       Connection Establishment
   1815 
   1816          The SMTP transmission channel is established via NCP between
   1817          the sender process socket U and receiver process socket L.  The
   1818          Initial Connection Protocol [5] is followed resulting in a pair
   1819          of simplex connections.  This pair of connections is used as
   1820          the transmission channel.  This protocol is assigned the
   1821          contact socket 25 (31 octal), that is L=25.
   1822 
   1823       Data Transfer
   1824 
   1825          The NCP data connections are established in 8-bit byte mode.
   1826          The SMTP data is 7-bit ASCII characters.  Each character is
   1827          transmitted as an 8-bit byte with the high-order bit cleared to
   1828          zero.
   1829 
   1830 August 1982                                                      _R_F_C_ _8_2_1
   1831 Simple Mail Transfer Protocol
   1832 
   1833 APPENDIX C
   1834 
   1835    NITS
   1836 
   1837       The Network Independent Transport Service [6] may be used.
   1838 
   1839       Connection Establishment
   1840 
   1841          The SMTP transmission channel is established via NITS between
   1842          the sender process and receiver process.  The sender process
   1843          executes the CONNECT primitive, and the waiting receiver
   1844          process executes the ACCEPT primitive.
   1845 
   1846       Data Transfer
   1847 
   1848          The NITS connection supports the transmission of 8-bit bytes.
   1849          The SMTP data is 7-bit ASCII characters.  Each character is
   1850          transmitted as an 8-bit byte with the high-order bit cleared to
   1851          zero.
   1852 
   1853 _R_F_C_ _8_2_1                                                      August 1982
   1854                                            Simple Mail Transfer Protocol
   1855 
   1856 APPENDIX D
   1857 
   1858    X.25 Transport service
   1859 
   1860       It may be possible to use the X.25 service [7] as provided by the
   1861       Public Data Networks directly, however, it is suggested that a
   1862       reliable end-to-end protocol such as TCP be used on top of X.25
   1863       connections.
   1864 
   1865 August 1982                                                      _R_F_C_ _8_2_1
   1866 Simple Mail Transfer Protocol
   1867 
   1868 APPENDIX E
   1869 
   1870    Theory of Reply Codes
   1871 
   1872       The three digits of the reply each have a special significance.
   1873       The first digit denotes whether the response is good, bad or
   1874       incomplete.  An unsophisticated sender-SMTP will be able to
   1875       determine its next action (proceed as planned, redo, retrench,
   1876       etc.) by simply examining this first digit.  A sender-SMTP that
   1877       wants to know approximately what kind of error occurred (e.g.,
   1878       mail system error, command syntax error) may examine the second
   1879       digit, reserving the third digit for the finest gradation of
   1880       information.
   1881 
   1882          There are five values for the first digit of the reply code:
   1883 
   1884             1yz   Positive Preliminary reply
   1885 
   1886                The command has been accepted, but the requested action
   1887                is being held in abeyance, pending confirmation of the
   1888                information in this reply.  The sender-SMTP should send
   1889                another command specifying whether to continue or abort
   1890                the action.
   1891 
   1892                   [Note: SMTP does not have any commands that allow this
   1893                   type of reply, and so does not have the continue or
   1894                   abort commands.]
   1895 
   1896             2yz   Positive Completion reply
   1897 
   1898                The requested action has been successfully completed.  A
   1899                new request may be initiated.
   1900 
   1901             3yz   Positive Intermediate reply
   1902 
   1903                The command has been accepted, but the requested action
   1904                is being held in abeyance, pending receipt of further
   1905                information.  The sender-SMTP should send another command
   1906                specifying this information.  This reply is used in
   1907                command sequence groups.
   1908 
   1909             4yz   Transient Negative Completion reply
   1910 
   1911                The command was not accepted and the requested action did
   1912                not occur.  However, the error condition is temporary and
   1913                the action may be requested again.  The sender should
   1914 
   1915 _R_F_C_ _8_2_1                                                      August 1982
   1916                                            Simple Mail Transfer Protocol
   1917 
   1918                return to the beginning of the command sequence (if any).
   1919                It is difficult to assign a meaning to "transient" when
   1920                two different sites (receiver- and sender- SMTPs) must
   1921                agree on the interpretation.  Each reply in this category
   1922                might have a different time value, but the sender-SMTP is
   1923                encouraged to try again.  A rule of thumb to determine if
   1924                a reply fits into the 4yz or the 5yz category (see below)
   1925                is that replies are 4yz if they can be repeated without
   1926                any change in command form or in properties of the sender
   1927                or receiver.  (E.g., the command is repeated identically
   1928                and the receiver does not put up a new implementation.)
   1929 
   1930             5yz   Permanent Negative Completion reply
   1931 
   1932                The command was not accepted and the requested action did
   1933                not occur.  The sender-SMTP is discouraged from repeating
   1934                the exact request (in the same sequence).  Even some
   1935                "permanent" error conditions can be corrected, so the
   1936                human user may want to direct the sender-SMTP to
   1937                reinitiate the command sequence by direct action at some
   1938                point in the future (e.g., after the spelling has been
   1939                changed, or the user has altered the account status).
   1940 
   1941          The second digit encodes responses in specific categories:
   1942 
   1943             x0z   Syntax -- These replies refer to syntax errors,
   1944                   syntactically correct commands that don't fit any
   1945                   functional category, and unimplemented or superfluous
   1946                   commands.
   1947 
   1948             x1z   Information --  These are replies to requests for
   1949                   information, such as status or help.
   1950 
   1951             x2z   Connections -- These are replies referring to the
   1952                   transmission channel.
   1953 
   1954             x3z   Unspecified as yet.
   1955 
   1956             x4z   Unspecified as yet.
   1957 
   1958             x5z   Mail system -- These replies indicate the status of
   1959                   the receiver mail system vis-a-vis the requested
   1960                   transfer or other mail system action.
   1961 
   1962          The third digit gives a finer gradation of meaning in each
   1963          category specified by the second digit.  The list of replies
   1964 
   1965 August 1982                                                      _R_F_C_ _8_2_1
   1966 Simple Mail Transfer Protocol
   1967 
   1968          illustrates this.  Each reply text is recommended rather than
   1969          mandatory, and may even change according to the command with
   1970          which it is associated.  On the other hand, the reply codes
   1971          must strictly follow the specifications in this section.
   1972          Receiver implementations should not invent new codes for
   1973          slightly different situations from the ones described here, but
   1974          rather adapt codes already defined.
   1975 
   1976          For example, a command such as NOOP whose successful execution
   1977          does not offer the sender-SMTP any new information will return
   1978          a 250 reply.  The response is 502 when the command requests an
   1979          unimplemented non-site-specific action.  A refinement of that
   1980          is the 504 reply for a command that is implemented, but that
   1981          requests an unimplemented parameter.
   1982 
   1983       The reply text may be longer than a single line; in these cases
   1984       the complete text must be marked so the sender-SMTP knows when it
   1985       can stop reading the reply.  This requires a special format to
   1986       indicate a multiple line reply.
   1987 
   1988          The format for multiline replies requires that every line,
   1989          except the last, begin with the reply code, followed
   1990          immediately by a hyphen, "-" (also known as minus), followed by
   1991          text.  The last line will begin with the reply code, followed
   1992          immediately by <SP>, optionally some text, and <CRLF>.
   1993 
   1994             For example:
   1995                                 123-First line
   1996                                 123-Second line
   1997                                 123-234 text beginning with numbers
   1998                                 123 The last line
   1999 
   2000          In many cases the sender-SMTP then simply needs to search for
   2001          the reply code followed by <SP> at the beginning of a line, and
   2002          ignore all preceding lines.  In a few cases, there is important
   2003          data for the sender in the reply "text".  The sender will know
   2004          these cases from the current context.
   2005 
   2006 _R_F_C_ _8_2_1                                                      August 1982
   2007                                            Simple Mail Transfer Protocol
   2008 
   2009 APPENDIX F
   2010 
   2011    Scenarios
   2012 
   2013       This section presents complete scenarios of several types of SMTP
   2014       sessions.
   2015 
   2016    A Typical SMTP Transaction Scenario
   2017 
   2018       This SMTP example shows mail sent by Smith at host USC-ISIF, to
   2019       Jones, Green, and Brown at host BBN-UNIX.  Here we assume that
   2020       host USC-ISIF contacts host BBN-UNIX directly.  The mail is
   2021       accepted for Jones and Brown.  Green does not have a mailbox at
   2022       host BBN-UNIX.
   2023 
   2024       -------------------------------------------------------------
   2025 
   2026          R: 220 BBN-UNIX.ARPA Simple Mail Transfer Service Ready
   2027          S: HELO USC-ISIF.ARPA
   2028          R: 250 BBN-UNIX.ARPA
   2029 
   2030          S: MAIL FROM:<_S_m_i_t_h_@_U_S_C_-_I_S_I_F_._A_R_P_A>
   2031          R: 250 OK
   2032 
   2033          S: RCPT TO:<_J_o_n_e_s_@_B_B_N_-_U_N_I_X_._A_R_P_A>
   2034          R: 250 OK
   2035 
   2036          S: RCPT TO:<_G_r_e_e_n_@_B_B_N_-_U_N_I_X_._A_R_P_A>
   2037          R: 550 No such user here
   2038 
   2039          S: RCPT TO:<_B_r_o_w_n_@_B_B_N_-_U_N_I_X_._A_R_P_A>
   2040          R: 250 OK
   2041 
   2042          S: DATA
   2043          R: 354 Start mail input; end with <CRLF>.<CRLF>
   2044          S: Blah blah blah...
   2045          S: ...etc. etc. etc.
   2046          S: .
   2047          R: 250 OK
   2048 
   2049          S: QUIT
   2050          R: 221 BBN-UNIX.ARPA Service closing transmission channel
   2051 
   2052                                Scenario 1
   2053 
   2054       -------------------------------------------------------------
   2055 
   2056 August 1982                                                      _R_F_C_ _8_2_1
   2057 Simple Mail Transfer Protocol
   2058 
   2059    Aborted SMTP Transaction Scenario
   2060 
   2061       -------------------------------------------------------------
   2062 
   2063          R: 220 MIT-Multics.ARPA Simple Mail Transfer Service Ready
   2064          S: HELO ISI-VAXA.ARPA
   2065          R: 250 MIT-Multics.ARPA
   2066 
   2067          S: MAIL FROM:<_S_m_i_t_h_@_I_S_I_-_V_A_X_A_._A_R_P_A>
   2068          R: 250 OK
   2069 
   2070          S: RCPT TO:<_J_o_n_e_s_@_M_I_T_-_M_u_l_t_i_c_s_._A_R_P_A>
   2071          R: 250 OK
   2072 
   2073          S: RCPT TO:<_G_r_e_e_n_@_M_I_T_-_M_u_l_t_i_c_s_._A_R_P_A>
   2074          R: 550 No such user here
   2075 
   2076          S: RSET
   2077          R: 250 OK
   2078 
   2079          S: QUIT
   2080          R: 221 MIT-Multics.ARPA Service closing transmission channel
   2081 
   2082                                Scenario 2
   2083 
   2084       -------------------------------------------------------------
   2085 
   2086 _R_F_C_ _8_2_1                                                      August 1982
   2087                                            Simple Mail Transfer Protocol
   2088 
   2089    Relayed Mail Scenario
   2090 
   2091       -------------------------------------------------------------
   2092 
   2093          Step 1  --  Source Host to Relay Host
   2094 
   2095             R: 220 USC-ISIE.ARPA Simple Mail Transfer Service Ready
   2096             S: HELO MIT-AI.ARPA
   2097             R: 250 USC-ISIE.ARPA
   2098 
   2099             S: MAIL FROM:<_J_Q_P_@_M_I_T_-_A_I_._A_R_P_A>
   2100             R: 250 OK
   2101 
   2102             S: RCPT TO:<@USC-ISIE.ARPA:_J_o_n_e_s_@_B_B_N_-_V_A_X_._A_R_P_A>
   2103             R: 250 OK
   2104 
   2105             S: DATA
   2106             R: 354 Start mail input; end with <CRLF>.<CRLF>
   2107             S: Date: 2 Nov 81 22:33:44
   2108             S: From: John Q. Public <_J_Q_P_@_M_I_T_-_A_I_._A_R_P_A>
   2109             S: Subject:  The Next Meeting of the Board
   2110             S: To: _J_o_n_e_s_@_B_B_N_-_V_a_x_._A_R_P_A
   2111             S:
   2112             S: Bill:
   2113             S: The next meeting of the board of directors will be
   2114             S: on Tuesday.
   2115             S:                                              John.
   2116             S: .
   2117             R: 250 OK
   2118 
   2119             S: QUIT
   2120             R: 221 USC-ISIE.ARPA Service closing transmission channel
   2121 
   2122 August 1982                                                      _R_F_C_ _8_2_1
   2123 Simple Mail Transfer Protocol
   2124 
   2125          Step 2  --  Relay Host to Destination Host
   2126 
   2127             R: 220 BBN-VAX.ARPA Simple Mail Transfer Service Ready
   2128             S: HELO USC-ISIE.ARPA
   2129             R: 250 BBN-VAX.ARPA
   2130 
   2131             S: MAIL FROM:<@USC-ISIE.ARPA:_J_Q_P_@_M_I_T_-_A_I_._A_R_P_A>
   2132             R: 250 OK
   2133 
   2134             S: RCPT TO:<_J_o_n_e_s_@_B_B_N_-_V_A_X_._A_R_P_A>
   2135             R: 250 OK
   2136 
   2137             S: DATA
   2138             R: 354 Start mail input; end with <CRLF>.<CRLF>
   2139             S: Received: from MIT-AI.ARPA by USC-ISIE.ARPA ;
   2140                2 Nov 81 22:40:10 UT
   2141             S: Date: 2 Nov 81 22:33:44
   2142             S: From: John Q. Public <_J_Q_P_@_M_I_T_-_A_I_._A_R_P_A>
   2143             S: Subject:  The Next Meeting of the Board
   2144             S: To: _J_o_n_e_s_@_B_B_N_-_V_a_x_._A_R_P_A
   2145             S:
   2146             S: Bill:
   2147             S: The next meeting of the board of directors will be
   2148             S: on Tuesday.
   2149             S:                                              John.
   2150             S: .
   2151             R: 250 OK
   2152 
   2153             S: QUIT
   2154             R: 221 USC-ISIE.ARPA Service closing transmission channel
   2155 
   2156                                Scenario 3
   2157 
   2158       -------------------------------------------------------------
   2159 
   2160 _R_F_C_ _8_2_1                                                      August 1982
   2161                                            Simple Mail Transfer Protocol
   2162 
   2163    Verifying and Sending Scenario
   2164 
   2165       -------------------------------------------------------------
   2166 
   2167          R: 220 SU-SCORE.ARPA Simple Mail Transfer Service Ready
   2168          S: HELO MIT-MC.ARPA
   2169          R: 250 SU-SCORE.ARPA
   2170 
   2171          S: VRFY Crispin
   2172          R: 250 Mark Crispin <_A_d_m_i_n_._M_R_C_@_S_U_-_S_C_O_R_E_._A_R_P_A>
   2173 
   2174          S: SEND FROM:<_E_A_K_@_M_I_T_-_M_C_._A_R_P_A>
   2175          R: 250 OK
   2176 
   2177          S: RCPT TO:<_A_d_m_i_n_._M_R_C_@_S_U_-_S_C_O_R_E_._A_R_P_A>
   2178          R: 250 OK
   2179 
   2180          S: DATA
   2181          R: 354 Start mail input; end with <CRLF>.<CRLF>
   2182          S: Blah blah blah...
   2183          S: ...etc. etc. etc.
   2184          S: .
   2185          R: 250 OK
   2186 
   2187          S: QUIT
   2188          R: 221 SU-SCORE.ARPA Service closing transmission channel
   2189 
   2190                                Scenario 4
   2191 
   2192       -------------------------------------------------------------
   2193 
   2194 August 1982                                                      _R_F_C_ _8_2_1
   2195 Simple Mail Transfer Protocol
   2196 
   2197    Sending and Mailing Scenarios
   2198 
   2199       First the user's name is verified, then  an attempt is made to
   2200       send to the user's terminal.  When that fails, the messages is
   2201       mailed to the user's mailbox.
   2202 
   2203       -------------------------------------------------------------
   2204 
   2205          R: 220 SU-SCORE.ARPA Simple Mail Transfer Service Ready
   2206          S: HELO MIT-MC.ARPA
   2207          R: 250 SU-SCORE.ARPA
   2208 
   2209          S: VRFY Crispin
   2210          R: 250 Mark Crispin <_A_d_m_i_n_._M_R_C_@_S_U_-_S_C_O_R_E_._A_R_P_A>
   2211 
   2212          S: SEND FROM:<_E_A_K_@_M_I_T_-_M_C_._A_R_P_A>
   2213          R: 250 OK
   2214 
   2215          S: RCPT TO:<_A_d_m_i_n_._M_R_C_@_S_U_-_S_C_O_R_E_._A_R_P_A>
   2216          R: 450 User not active now
   2217 
   2218          S: RSET
   2219          R: 250 OK
   2220 
   2221          S: MAIL FROM:<_E_A_K_@_M_I_T_-_M_C_._A_R_P_A>
   2222          R: 250 OK
   2223 
   2224          S: RCPT TO:<_A_d_m_i_n_._M_R_C_@_S_U_-_S_C_O_R_E_._A_R_P_A>
   2225          R: 250 OK
   2226 
   2227          S: DATA
   2228          R: 354 Start mail input; end with <CRLF>.<CRLF>
   2229          S: Blah blah blah...
   2230          S: ...etc. etc. etc.
   2231          S: .
   2232          R: 250 OK
   2233 
   2234          S: QUIT
   2235          R: 221 SU-SCORE.ARPA Service closing transmission channel
   2236 
   2237                                Scenario 5
   2238 
   2239       -------------------------------------------------------------
   2240 
   2241 _R_F_C_ _8_2_1                                                      August 1982
   2242                                            Simple Mail Transfer Protocol
   2243 
   2244       Doing the preceding scenario more efficiently.
   2245 
   2246       -------------------------------------------------------------
   2247 
   2248          R: 220 SU-SCORE.ARPA Simple Mail Transfer Service Ready
   2249          S: HELO MIT-MC.ARPA
   2250          R: 250 SU-SCORE.ARPA
   2251 
   2252          S: VRFY Crispin
   2253          R: 250 Mark Crispin <_A_d_m_i_n_._M_R_C_@_S_U_-_S_C_O_R_E_._A_R_P_A>
   2254 
   2255          S: SOML FROM:<_E_A_K_@_M_I_T_-_M_C_._A_R_P_A>
   2256          R: 250 OK
   2257 
   2258          S: RCPT TO:<_A_d_m_i_n_._M_R_C_@_S_U_-_S_C_O_R_E_._A_R_P_A>
   2259          R: 250 User not active now, so will do mail.
   2260 
   2261          S: DATA
   2262          R: 354 Start mail input; end with <CRLF>.<CRLF>
   2263          S: Blah blah blah...
   2264          S: ...etc. etc. etc.
   2265          S: .
   2266          R: 250 OK
   2267 
   2268          S: QUIT
   2269          R: 221 SU-SCORE.ARPA Service closing transmission channel
   2270 
   2271                                Scenario 6
   2272 
   2273       -------------------------------------------------------------
   2274 
   2275 August 1982                                                      _R_F_C_ _8_2_1
   2276 Simple Mail Transfer Protocol
   2277 
   2278    Mailing List Scenario
   2279 
   2280       First each of two mailing lists are expanded in separate sessions
   2281       with different hosts.  Then the message is sent to everyone that
   2282       appeared on either list (but no duplicates) via a relay host.
   2283 
   2284       -------------------------------------------------------------
   2285 
   2286          Step 1  --  Expanding the First List
   2287 
   2288             R: 220 MIT-AI.ARPA Simple Mail Transfer Service Ready
   2289             S: HELO SU-SCORE.ARPA
   2290             R: 250 MIT-AI.ARPA
   2291 
   2292             S: EXPN Example-People
   2293             R: 250-<_A_B_C_@_M_I_T_-_M_C_._A_R_P_A>
   2294             R: 250-Fred Fonebone <_F_o_n_e_b_o_n_e_@_U_S_C_-_I_S_I_Q_._A_R_P_A>
   2295             R: 250-Xenon Y. Zither <_X_Y_Z_@_M_I_T_-_A_I_._A_R_P_A>
   2296             R: 250-Quincy Smith <@USC-ISIF.ARPA:_Q_-_S_m_i_t_h_@_I_S_I_-_V_A_X_A_._A_R_P_A>
   2297             R: 250-<_j_o_e_@_f_o_o_-_u_n_i_x_._A_R_P_A>
   2298             R: 250 <_x_y_z_@_b_a_r_-_u_n_i_x_._A_R_P_A>
   2299 
   2300             S: QUIT
   2301             R: 221 MIT-AI.ARPA Service closing transmission channel
   2302 
   2303 _R_F_C_ _8_2_1                                                      August 1982
   2304                                            Simple Mail Transfer Protocol
   2305 
   2306          Step 2  --  Expanding the Second List
   2307 
   2308             R: 220 MIT-MC.ARPA Simple Mail Transfer Service Ready
   2309             S: HELO SU-SCORE.ARPA
   2310             R: 250 MIT-MC.ARPA
   2311 
   2312             S: EXPN Interested-Parties
   2313             R: 250-Al Calico <_A_B_C_@_M_I_T_-_M_C_._A_R_P_A>
   2314             R: 250-<_X_Y_Z_@_M_I_T_-_A_I_._A_R_P_A>
   2315             R: 250-Quincy Smith <@USC-ISIF.ARPA:_Q_-_S_m_i_t_h_@_I_S_I_-_V_A_X_A_._A_R_P_A>
   2316             R: 250-<_f_r_e_d_@_B_B_N_-_U_N_I_X_._A_R_P_A>
   2317             R: 250 <_x_y_z_@_b_a_r_-_u_n_i_x_._A_R_P_A>
   2318 
   2319             S: QUIT
   2320             R: 221 MIT-MC.ARPA Service closing transmission channel
   2321 
   2322 August 1982                                                      _R_F_C_ _8_2_1
   2323 Simple Mail Transfer Protocol
   2324 
   2325          Step 3  --  Mailing to All via a Relay Host
   2326 
   2327             R: 220 USC-ISIE.ARPA Simple Mail Transfer Service Ready
   2328             S: HELO SU-SCORE.ARPA
   2329             R: 250 USC-ISIE.ARPA
   2330 
   2331             S: MAIL FROM:<_A_c_c_o_u_n_t_._P_e_r_s_o_n_@_S_U_-_S_C_O_R_E_._A_R_P_A>
   2332             R: 250 OK
   2333             S: RCPT TO:<@USC-ISIE.ARPA:_A_B_C_@_M_I_T_-_M_C_._A_R_P_A>
   2334             R: 250 OK
   2335             S: RCPT TO:<@USC-ISIE.ARPA:_F_o_n_e_b_o_n_e_@_U_S_C_-_I_S_I_Q_A_._A_R_P_A>
   2336             R: 250 OK
   2337             S: RCPT TO:<@USC-ISIE.ARPA:_X_Y_Z_@_M_I_T_-_A_I_._A_R_P_A>
   2338             R: 250 OK
   2339             S: RCPT
   2340                 TO:<@USC-ISIE.ARPA,@USC-ISIF.ARPA:_Q_-_S_m_i_t_h_@_I_S_I_-_V_A_X_A_._A_R_P_A>
   2341             R: 250 OK
   2342             S: RCPT TO:<@USC-ISIE.ARPA:_j_o_e_@_F_O_O_-_U_N_I_X_._A_R_P_A>
   2343             R: 250 OK
   2344             S: RCPT TO:<@USC-ISIE.ARPA:_x_y_z_@_B_A_R_-_U_N_I_X_._A_R_P_A>
   2345             R: 250 OK
   2346             S: RCPT TO:<@USC-ISIE.ARPA:_f_r_e_d_@_B_B_N_-_U_N_I_X_._A_R_P_A>
   2347             R: 250 OK
   2348 
   2349             S: DATA
   2350             R: 354 Start mail input; end with <CRLF>.<CRLF>
   2351             S: Blah blah blah...
   2352             S: ...etc. etc. etc.
   2353             S: .
   2354             R: 250 OK
   2355 
   2356             S: QUIT
   2357             R: 221 USC-ISIE.ARPA Service closing transmission channel
   2358 
   2359                                Scenario 7
   2360 
   2361       -------------------------------------------------------------
   2362 
   2363 _R_F_C_ _8_2_1                                                      August 1982
   2364                                            Simple Mail Transfer Protocol
   2365 
   2366    Forwarding Scenarios
   2367 
   2368       -------------------------------------------------------------
   2369 
   2370          R: 220 USC-ISIF.ARPA Simple Mail Transfer Service Ready
   2371          S: HELO LBL-UNIX.ARPA
   2372          R: 250 USC-ISIF.ARPA
   2373 
   2374          S: MAIL FROM:<_m_o_@_L_B_L_-_U_N_I_X_._A_R_P_A>
   2375          R: 250 OK
   2376 
   2377          S: RCPT TO:<_f_r_e_d_@_U_S_C_-_I_S_I_F_._A_R_P_A>
   2378          R: 251 User not local; will forward to <_J_o_n_e_s_@_U_S_C_-_I_S_I_._A_R_P_A>
   2379 
   2380          S: DATA
   2381          R: 354 Start mail input; end with <CRLF>.<CRLF>
   2382          S: Blah blah blah...
   2383          S: ...etc. etc. etc.
   2384          S: .
   2385          R: 250 OK
   2386 
   2387          S: QUIT
   2388          R: 221 USC-ISIF.ARPA Service closing transmission channel
   2389 
   2390                                Scenario 8
   2391 
   2392       -------------------------------------------------------------
   2393 
   2394 August 1982                                                      _R_F_C_ _8_2_1
   2395 Simple Mail Transfer Protocol
   2396 
   2397       -------------------------------------------------------------
   2398 
   2399          Step 1  --  Trying the Mailbox at the First Host
   2400 
   2401             R: 220 USC-ISIF.ARPA Simple Mail Transfer Service Ready
   2402             S: HELO LBL-UNIX.ARPA
   2403             R: 250 USC-ISIF.ARPA
   2404 
   2405             S: MAIL FROM:<_m_o_@_L_B_L_-_U_N_I_X_._A_R_P_A>
   2406             R: 250 OK
   2407 
   2408             S: RCPT TO:<_f_r_e_d_@_U_S_C_-_I_S_I_F_._A_R_P_A>
   2409             R: 251 User not local; will forward to <_J_o_n_e_s_@_U_S_C_-_I_S_I_._A_R_P_A>
   2410 
   2411             S: RSET
   2412             R: 250 OK
   2413 
   2414             S: QUIT
   2415             R: 221 USC-ISIF.ARPA Service closing transmission channel
   2416 
   2417          Step 2  --  Delivering the Mail at the Second Host
   2418 
   2419             R: 220 USC-ISI.ARPA Simple Mail Transfer Service Ready
   2420             S: HELO LBL-UNIX.ARPA
   2421             R: 250 USC-ISI.ARPA
   2422 
   2423             S: MAIL FROM:<_m_o_@_L_B_L_-_U_N_I_X_._A_R_P_A>
   2424             R: 250 OK
   2425 
   2426             S: RCPT TO:<_J_o_n_e_s_@_U_S_C_-_I_S_I_._A_R_P_A>
   2427             R: OK
   2428 
   2429             S: DATA
   2430             R: 354 Start mail input; end with <CRLF>.<CRLF>
   2431             S: Blah blah blah...
   2432             S: ...etc. etc. etc.
   2433             S: .
   2434             R: 250 OK
   2435 
   2436             S: QUIT
   2437             R: 221 USC-ISI.ARPA Service closing transmission channel
   2438 
   2439                                Scenario 9
   2440 
   2441       -------------------------------------------------------------
   2442 
   2443 _R_F_C_ _8_2_1                                                      August 1982
   2444                                            Simple Mail Transfer Protocol
   2445 
   2446    Too Many Recipients Scenario
   2447 
   2448       -------------------------------------------------------------
   2449 
   2450          R: 220 BERKELEY.ARPA Simple Mail Transfer Service Ready
   2451          S: HELO USC-ISIF.ARPA
   2452          R: 250 BERKELEY.ARPA
   2453 
   2454          S: MAIL FROM:<_P_o_s_t_e_l_@_U_S_C_-_I_S_I_F_._A_R_P_A>
   2455          R: 250 OK
   2456 
   2457          S: RCPT TO:<_f_a_b_r_y_@_B_E_R_K_E_L_E_Y_._A_R_P_A>
   2458          R: 250 OK
   2459 
   2460          S: RCPT TO:<_e_r_i_c_@_B_E_R_K_E_L_E_Y_._A_R_P_A>
   2461          R: 552 Recipient storage full, try again in another transaction
   2462 
   2463          S: DATA
   2464          R: 354 Start mail input; end with <CRLF>.<CRLF>
   2465          S: Blah blah blah...
   2466          S: ...etc. etc. etc.
   2467          S: .
   2468          R: 250 OK
   2469 
   2470          S: MAIL FROM:<_P_o_s_t_e_l_@_U_S_C_-_I_S_I_F_._A_R_P_A>
   2471          R: 250 OK
   2472 
   2473          S: RCPT TO:<_e_r_i_c_@_B_E_R_K_E_L_E_Y_._A_R_P_A>
   2474          R: 250 OK
   2475 
   2476          S: DATA
   2477          R: 354 Start mail input; end with <CRLF>.<CRLF>
   2478          S: Blah blah blah...
   2479          S: ...etc. etc. etc.
   2480          S: .
   2481          R: 250 OK
   2482 
   2483          S: QUIT
   2484          R: 221 BERKELEY.ARPA Service closing transmission channel
   2485 
   2486                               Scenario 10
   2487 
   2488       -------------------------------------------------------------
   2489 
   2490       Note that a real implementation must handle many recipients as
   2491       specified in Section 4.5.3.
   2492 
   2493 August 1982                                                      _R_F_C_ _8_2_1
   2494 Simple Mail Transfer Protocol
   2495 
   2496 GLOSSARY
   2497 
   2498    ASCII
   2499 
   2500       American Standard Code for Information Interchange [1].
   2501 
   2502    command
   2503 
   2504       A request for a mail service action sent by the sender-SMTP to the
   2505       receiver-SMTP.
   2506 
   2507    domain
   2508 
   2509       The hierarchially structured global character string address of a
   2510       host computer in the mail system.
   2511 
   2512    end of mail data indication
   2513 
   2514       A special sequence of characters that indicates the end of the
   2515       mail data.  In particular, the five characters carriage return,
   2516       line feed, period, carriage return, line feed, in that order.
   2517 
   2518    host
   2519 
   2520       A computer in the internetwork environment on which mailboxes or
   2521       SMTP processes reside.
   2522 
   2523    line
   2524 
   2525       A a sequence of ASCII characters ending with a <CRLF>.
   2526 
   2527    mail data
   2528 
   2529       A sequence of ASCII characters of arbitrary length, which conforms
   2530       to the standard set in the Standard for the Format of ARPA
   2531       Internet Text Messages (_R_F_C_ _8_2_2 [2]).
   2532 
   2533    mailbox
   2534 
   2535       A character string (address) which identifies a user to whom mail
   2536       is to be sent.  Mailbox normally consists of the host and user
   2537       specifications.  The standard mailbox naming convention is defined
   2538       to be "user@domain".  Additionally, the "container" in which mail
   2539       is stored.
   2540 
   2541 _R_F_C_ _8_2_1                                                      August 1982
   2542                                            Simple Mail Transfer Protocol
   2543 
   2544    receiver-SMTP process
   2545 
   2546       A process which transfers mail in cooperation with a sender-SMTP
   2547       process.  It waits for a connection to be established via the
   2548       transport service.  It receives SMTP commands from the
   2549       sender-SMTP, sends replies, and performs the specified operations.
   2550 
   2551    reply
   2552 
   2553       A reply is an acknowledgment (positive or negative) sent from
   2554       receiver to sender via the transmission channel in response to a
   2555       command.  The general form of a reply is a completion code
   2556       (including error codes) followed by a text string.  The codes are
   2557       for use by programs and the text is usually intended for human
   2558       users.
   2559 
   2560    sender-SMTP process
   2561 
   2562       A process which transfers mail in cooperation with a receiver-SMTP
   2563       process.  A local language may be used in the user interface
   2564       command/reply dialogue.  The sender-SMTP initiates the transport
   2565       service connection.  It initiates SMTP commands, receives replies,
   2566       and governs the transfer of mail.
   2567 
   2568    session
   2569 
   2570       The set of exchanges that occur while the transmission channel is
   2571       open.
   2572 
   2573    transaction
   2574 
   2575       The set of exchanges required for one message to be transmitted
   2576       for one or more recipients.
   2577 
   2578    transmission channel
   2579 
   2580       A full-duplex communication path between a sender-SMTP and a
   2581       receiver-SMTP for the exchange of commands, replies, and mail
   2582       text.
   2583 
   2584    transport service
   2585 
   2586       Any reliable stream-oriented data communication services.  For
   2587       example, NCP, TCP, NITS.
   2588 
   2589 August 1982                                                      _R_F_C_ _8_2_1
   2590 Simple Mail Transfer Protocol
   2591 
   2592    user
   2593 
   2594       A human being (or a process on behalf of a human being) wishing to
   2595       obtain mail transfer service.  In addition, a recipient of
   2596       computer mail.
   2597 
   2598    word
   2599 
   2600       A sequence of printing characters.
   2601 
   2602    <CRLF>
   2603 
   2604       The characters carriage return and line feed (in that order).
   2605 
   2606    <SP>
   2607 
   2608       The space character.
   2609 
   2610 _R_F_C_ _8_2_1                                                      August 1982
   2611                                            Simple Mail Transfer Protocol
   2612 
   2613 REFERENCES
   2614 
   2615    [1]  ASCII
   2616 
   2617       ASCII, "USA Code for Information Interchange", United States of
   2618       America Standards Institute, X3.4, 1968.  Also in:  Feinler, E.
   2619       and J. Postel, eds., "ARPANET Protocol Handbook", NIC 7104, for
   2620       the Defense Communications Agency by SRI International, Menlo
   2621       Park, California, Revised January 1978.
   2622 
   2623    [2]  _R_F_C_ _8_2_2
   2624 
   2625       Crocker, D., "Standard for the Format of ARPA Internet Text
   2626       Messages," _R_F_C_ _8_2_2, Department of Electrical Engineering,
   2627       University of Delaware, August 1982.
   2628 
   2629    [3]  TCP
   2630 
   2631       Postel, J., ed., "Transmission Control Protocol - DARPA Internet
   2632       Program Protocol Specification", _R_F_C_ _7_9_3, USC/Information Sciences
   2633       Institute, NTIS AD Number A111091, September 1981.  Also in:
   2634       Feinler, E. and J. Postel, eds., "Internet Protocol Transition
   2635       Workbook", SRI International, Menlo Park, California, March 1982.
   2636 
   2637    [4]  NCP
   2638 
   2639       McKenzie,A., "Host/Host Protocol for the ARPA Network", NIC 8246,
   2640       January 1972.  Also in:  Feinler, E. and J. Postel, eds., "ARPANET
   2641       Protocol Handbook", NIC 7104, for the Defense Communications
   2642       Agency by SRI International, Menlo Park, California, Revised
   2643       January 1978.
   2644 
   2645    [5]  Initial Connection Protocol
   2646 
   2647       Postel, J., "Official Initial Connection Protocol", NIC 7101,
   2648       11 June 1971.  Also in:  Feinler, E. and J. Postel, eds., "ARPANET
   2649       Protocol Handbook", NIC 7104, for the Defense Communications
   2650       Agency by SRI International, Menlo Park, California, Revised
   2651       January 1978.
   2652 
   2653    [6]  NITS
   2654 
   2655       PSS/SG3, "A Network Independent Transport Service", Study Group 3,
   2656       The Post Office PSS Users Group, February 1980.  Available from
   2657       the DCPU, National Physical Laboratory, Teddington, UK.
   2658 
   2659 August 1982                                                      _R_F_C_ _8_2_1
   2660 Simple Mail Transfer Protocol
   2661 
   2662    [7]  X.25
   2663 
   2664       CCITT, "Recommendation X.25 - Interface Between Data Terminal
   2665       Equipment (DTE) and Data Circuit-terminating Equipment (DCE) for
   2666       Terminals Operating in the Packet Mode on Public Data Networks,"
   2667       CCITT Orange Book, Vol. VIII.2, International Telephone and
   2668       Telegraph Consultative Committee, Geneva, 1976.
   2669  
   2670 Comments about this RFC:
   2671     * _R_F_C_ _8_2_1_:_ _w_h_e_r_e_ _i_ _c_a_n_ _w_r_i_t_e_ _m_y_ _s_c_r_i_p_t_s by mahmood (1/31/2004)
   2672     * _R_F_C_ _8_2_1_:_ _A_ _r_o_n_a_l_d_ _r_ _d_a_v_i_s_ _o_n_ _p_a_r_o_l_e_ _h_a_s_ _h_a_c_k_e_d_ _i_n_t_o_ _m_y_ _a_c_c_o_u_n_t_._ _h_e_ _i_s_ _n_o_t
   2673       _s_u_p_p_o_s_s_e_d_ _t_o_._._. by lifeisunfair (12/20/2006)
   2674     * _R_F_C_ _8_2_1_:_ _I_ _a_m_ _u_n_a_b_l_e_ _t_o_ _s_e_n_d_ _o_u_t_ _e_-_m_a_i_l_s_._T_h_e_ _e_r_r_o_r_ _m_e_s_s_a_g_e_ _s_a_y_s_:_ _T_h_e
   2675       _m_e_s_s_a_g_e_ _c_o_u_l_d_ _n_o_t_ _b_e_._._. by nita (11/5/2004)
   2676     * _R_F_C_ _8_2_1_:_ _H_o_w_ _c_a_n_ _I_ _c_r_e_a_t_e_ _a_ _s_c_r_i_p_t_ _d_o_ _r_u_n_ _o_n_ _W_i_n_d_o_w_s_ _?_ _?_ _?_ _I_'_d_ _l_i_k_e_ _t_o
   2677       _u_s_e_ _a_ _s_c_r_i_p_t_._._. by Marcelo (11/8/2004)
   2678     * _R_F_C_ _8_2_1_:_ _h_o_w_ _s_m_t_p_ _w_o_r_k_s_ _i_n_ _e_x_c_h_a_n_g_e_ _s_y_t_e_m_? by saif (12/4/2005)
   2679     * _R_F_C_ _8_2_1_:_ _V_e_r_y_ _G_o_o_d_ _B_u_t_ _I_ _W_a_n_t_ _C_o_d_i_n_g_ _o_f_ _S_i_m_l_e_ _M_a_i_l_ _t_r_a_n_s_f_e_r_ _p_r_o_t_o_c_o_l by
   2680       Ankit Pahuja (3/23/2006)
   2681     * _R_F_C_ _8_2_1_:_ _T_h_i_s_ _R_F_C_ _i_s_ _o_b_s_o_l_e_t_e_d_ _b_y_ _R_F_C_2_8_2_1_._ _A_n_y_o_n_e_ _s_e_e_k_i_n_g_ _t_o_ _u_n_d_e_r_s_t_a_n_d
   2682       _m_o_d_e_r_n_ _S_M_T_P_ _o_r_._._. by William Cole (4/23/2005)
   2683     * _R_F_C_ _8_2_1_:_ _C_a_n_ _I_ _a_t_t_a_c_h_ _a_ _f_i_l_e_ _t_o_ _a_n_ _o_u_t_g_o_i_n_g_ _e_-_m_a_i_l_ _o_n_ _t_h_e_ _m_a_i_n_f_r_a_m_e_? by
   2684       dphill06 (5/23/2006)
   2685     * _R_F_C_ _8_2_1_:_ _I_ _w_a_n_t_ _t_o_ _g_e_t_ _t_h_e_ _i_n_f_o_r_m_a_t_i_o_n_ _o_f_ _u_t_l___s_m_t_p by eagle_hawk (6/2/
   2686       2005)
   2687     * _R_F_C_ _8_2_1_:_ _I_ _a_m_ _a_ _M_A_C_ _u_s_e_r_ _w_h_o_ _w_a_s_ _p_r_o_v_i_d_e_d_ _a_n_ _s_m_p_t_ _c_a_p_a_b_i_l_i_t_y_ _w_h_i_c_h_ _I_ _c_a_n
   2688       _n_o_t_ _u_s_e_ _f_o_r_ _l_a_c_k_._._. by Larry Stolurow (6/22/2006)
   2689     * _R_F_C_ _8_2_1_:_ _A_l_w_a_y_s_ _a_ _g_o_o_d_ _r_e_a_d_!_I_ _i_m_p_l_e_m_e_n_t_ _S_M_T_P_ _o_v_e_r_ _V_B_6_ _W_i_n_s_o_c_k_._ _W_o_r_k_s
   2690       _g_r_e_a_t_,_ _r_e_f_e_r_ _t_o_._._. by python_kiss (11/3/2005)
   2691     * _R_F_C_ _8_2_1_:_ _v_e_r_y_ _s_i_m_p_l_e_ _t_o_ _c_o_n_f_i_g_u_r_e by dixson (3/26/2007)
   2692     * _R_F_C_ _8_2_1_:_ _R_F_C_ _8_2_1_ _d_o_e_s_ _n_o_t_ _c_o_m_m_e_n_t_ _o_n_ _t_h_e_ _v_a_l_i_d_i_t_y_ _o_f_ _t_r_a_i_l_i_n_g_ _d_o_t_s_ _f_o_r
   2693       _d_o_m_a_i_n_ _n_a_m_e_s_._ _I_t_._._. by Brett (12/22/2004)
   2694     * _R_F_C_ _8_2_1_:_ _W_h_a_t_ _i_s_ _R_F_C_ _f_o_r_m_a_t_?_H_o_ _i_t_ _i_s_ _u_s_e_d_? by siva (3/2/2004)
   2695     * _R_F_C_ _8_2_1_:_ _s_i_r_,_w_e_ _a_r_e_ _d_o_i_n_g_ _p_r_o_j_e_c_t_ _o_n_ _S_M_S_ _f_r_o_m_ _m_o_b_i_l_e_ _t_o_ _i_n_t_e_r_n_e_t_._S_o_ _f_o_r
   2696       _c_o_m_m_u_n_i_c_a_t_i_n_g_w_i_t_h_._._. by Krishna (5/9/2004)
   2697     * _R_F_C_ _8_2_1_:_ _H_i_!_ _V_e_r_y_ _n_i_c_e_ _s_i_t_e_!_ _T_h_a_n_k_s_ _y_o_u_ _v_e_r_y_ _m_u_c_h_!_ _m_8_8_C_X_f_G_F_N_X_H_O_k_S by
   2698       rzq9PUrVNv (1/21/2007)
   2699     * _R_F_C_ _8_2_1_:_ _i_ _n_e_e_t_ _s_l_e_e_p_ _p_f_f_f_f_f_f_ _w_a_t_ _i_ _n_e_e_ _t_e_ _d_o_e by goldface (9/24/2005)
   2700 
   2701 Previous: _R_F_C_ _0_8_2_0_ _-_ _A_s_s_i_g_n_e_d_ _n_u_m_b_e_r_s         Next: _R_F_C_ _0_8_2_2_ _-_ _S_T_A_N_D_A_R_D_ _F_O_R_ _T_H_E
   2702                                           _F_O_R_M_A_T_ _O_F_ _A_R_P_A_ _I_N_T_E_R_N_E_T_ _T_E_X_T_ _M_E_S_S_A_G_E_S
   2703                                                                                
   2704 ===============================================================================
   2705    [ _R_F_C_ _I_n_d_e_x | _R_F_C_ _S_e_a_r_c_h | _U_s_e_n_e_t_ _F_A_Q_s | _W_e_b_ _F_A_Q_s | _D_o_c_u_m_e_n_t_s | _C_i_t_i_e_s ]
   2706  2008 FAQS.ORG. All rights reserved.
   2707