[Page 12]                                                         Postel                                                                        RFC 821                                                      August 1982                                           Simple Mail Transfer Protocol   3.5.  OPENING AND CLOSING      At the time the transmission channel is opened there is an      exchange to ensure that the hosts are communicating with the hosts      they think they are.      The following two commands are used in transmission channel      opening and closing:         HELO <SP> <domain> <CRLF>         QUIT <CRLF>      In the HELO command the host sending the command identifies      itself; the command may be interpreted as saying "Hello, I am      <domain>".      -------------------------------------------------------------                     Example of Connection Opening         R: 220 BBN-UNIX.ARPA Simple Mail Transfer Service Ready         S: HELO USC-ISIF.ARPA         R: 250 BBN-UNIX.ARPA                               Example 5      -------------------------------------------------------------      -------------------------------------------------------------                     Example of Connection Closing         S: QUIT         R: 221 BBN-UNIX.ARPA Service closing transmission channel                               Example 6      -------------------------------------------------------------Postel                                                         [Page 13]                                                                        August 1982                                                      RFC 821Simple Mail Transfer Protocol                                              3.6.  RELAYING      The forward-path may be a source route of the form      "@ONE,@TWO:JOE@THREE", where ONE, TWO, and THREE are hosts.  This      form is used to emphasize the distinction between an address and a      route.  The mailbox is an absolute address, and the route is      information about how to get there.  The two concepts should not      be confused.      Conceptually the elements of the forward-path are moved to the      reverse-path as the message is relayed from one server-SMTP to      another.  The reverse-path is a reverse source route, (i.e., a      source route from the current location of the message to the      originator of the message).  When a server-SMTP deletes its      identifier from the forward-path and inserts it into the      reverse-path, it must use the name it is known by in the      environment it is sending into, not the environment the mail came      from, in case the server-SMTP is known by different names in      different environments.      If when the message arrives at an SMTP the first element of the      forward-path is not the identifier of that SMTP the element is not      deleted from the forward-path and is used to determine the next      SMTP to send the message to.  In any case, the SMTP adds its own      identifier to the reverse-path.      Using source routing the receiver-SMTP receives mail to be relayed      to another server-SMTP  The receiver-SMTP may accept or reject the      task of relaying the mail in the same way it accepts or rejects      mail for a local user.  The receiver-SMTP transforms the command      arguments by moving its own identifier from the forward-path to      the beginning of the reverse-path.  The receiver-SMTP then becomes      a sender-SMTP, establishes a transmission channel to the next SMTP      in the forward-path, and sends it the mail.      The first host in the reverse-path should be the host sending the      SMTP commands, and the first host in the forward-path should be      the host receiving the SMTP commands.      Notice that the forward-path and reverse-path appear in the SMTP      commands and replies, but not necessarily in the message.  That      is, there is no need for these paths and especially this syntax to      appear in the "To:" , "From:", "CC:", etc. fields of the message      header.      If a server-SMTP has accepted the task of relaying the mail and[Page 14]                                                         Postel                                                                        RFC 821                                                      August 1982                                           Simple Mail Transfer Protocol      later finds that the forward-path is incorrect or that the mail      cannot be delivered for whatever reason, then it must construct an      "undeliverable mail" notification message and send it to the      originator of the undeliverable mail (as indicated by the      reverse-path).      This notification message must be from the server-SMTP at this      host.  Of course, server-SMTPs should not send notification      messages about problems with notification messages.  One way to      prevent loops in error reporting is to specify a null reverse-path      in the MAIL command of a notification message.  When such a      message is relayed it is permissible to leave the reverse-path      null.  A MAIL command with a null reverse-path appears as follows:         MAIL FROM:<>      An undeliverable mail notification message is shown in example 7.      This notification is in response to a message originated by JOE at      HOSTW and sent via HOSTX to HOSTY with instructions to relay it on      to HOSTZ.  What we see in the example is the transaction between      HOSTY and HOSTX, which is the first step in the return of the      notification message.Postel                                                         [Page 15]                                                                        August 1982                                                      RFC 821Simple Mail Transfer Protocol                                                 -------------------------------------------------------------            Example Undeliverable Mail Notification Message         S: MAIL FROM:<>         R: 250 ok         S: RCPT TO:<@HOSTX.ARPA:JOE@HOSTW.ARPA>         R: 250 ok         S: DATA         R: 354 send the mail data, end with .         S: Date: 23 Oct 81 11:22:33         S: From: SMTP@HOSTY.ARPA         S: To: JOE@HOSTW.ARPA         S: Subject: Mail System Problem         S:         S:   Sorry JOE, your message to SAM@HOSTZ.ARPA lost.         S:   HOSTZ.ARPA said this:         S:    "550 No Such User"         S: .         R: 250 ok                               Example 7      -------------------------------------------------------------[Page 16]                                                         Postel                                                                        RFC 821                                                      August 1982                                           Simple Mail Transfer Protocol   3.7.  DOMAINS      Domains are a recently introduced concept in the ARPA Internet      mail system.  The use of domains changes the address space from a      flat global space of simple character string host names to a      hierarchically structured rooted tree of global addresses.  The      host name is replaced by a domain and host designator which is a      sequence of domain element strings separated by periods with the      understanding that the domain elements are ordered from the most      specific to the most general.      For example, "USC-ISIF.ARPA", "Fred.Cambridge.UK", and      "PC7.LCS.MIT.ARPA" might be host-and-domain identifiers.      Whenever domain names are used in SMTP only the official names are      used, the use of nicknames or aliases is not allowed.Postel                                                         [Page 17]                                                                        August 1982                                                      RFC 821Simple Mail Transfer Protocol                                              3.8.  CHANGING ROLES      The TURN command may be used to reverse the roles of the two      programs communicating over the transmission channel.      If program-A is currently the sender-SMTP and it sends the TURN      command and receives an ok reply (250) then program-A becomes the      receiver-SMTP.      If program-B is currently the receiver-SMTP and it receives the      TURN command and sends an ok reply (250) then program-B becomes      the sender-SMTP.      To refuse to change roles the receiver sends the 502 reply.      Please note that this command is optional.  It would not normally      be used in situations where the transmission channel is TCP.      However, when the cost of establishing the transmission channel is      high, this command may be quite useful.  For example, this command      may be useful in supporting be mail exchange using the public      switched telephone system as a transmission channel, especially if      some hosts poll other hosts for mail exchanges.[Page 18]                                                         Postel                                                                        RFC 821                                                      August 1982                                           Simple Mail Transfer Protocol4.  THE SMTP SPECIFICATIONS   4.1.  SMTP COMMANDS      4.1.1.  COMMAND SEMANTICS         The SMTP commands define the mail transfer or the mail system         function requested by the user.  SMTP commands are character         strings terminated by <CRLF>.  The command codes themselves are         alphabetic characters terminated by <SP> if parameters follow         and <CRLF> otherwise.  The syntax of mailboxes must conform to         receiver site conventions.  The SMTP commands are discussed         below.  The SMTP replies are discussed in the Section 4.2.         A mail transaction involves several data objects which are         communicated as arguments to different commands.  The