Postel                                                          [Page 5]                                                                        August 1982                                                      RFC 821Simple Mail Transfer Protocol                                                 -------------------------------------------------------------                     Example of the SMTP Procedure         This SMTP example shows mail sent by Smith at host Alpha.ARPA,         to Jones, Green, and Brown at host Beta.ARPA.  Here we assume         that host Alpha contacts host Beta directly.            S: MAIL FROM:<Smith@Alpha.ARPA>            R: 250 OK            S: RCPT TO:<Jones@Beta.ARPA>            R: 250 OK            S: RCPT TO:<Green@Beta.ARPA>            R: 550 No such user here            S: RCPT TO:<Brown@Beta.ARPA>            R: 250 OK            S: DATA            R: 354 Start mail input; end with <CRLF>.<CRLF>            S: Blah blah blah...            S: ...etc. etc. etc.            S: <CRLF>.<CRLF>            R: 250 OK         The mail has now been accepted for Jones and Brown.  Green did         not have a mailbox at host Beta.                               Example 1      -------------------------------------------------------------[Page 6]                                                          Postel                                                                        RFC 821                                                      August 1982                                           Simple Mail Transfer Protocol   3.2.  FORWARDING      There are some cases where the destination information in the      <forward-path> is incorrect, but the receiver-SMTP knows the      correct destination.  In such cases, one of the following replies      should be used to allow the sender to contact the correct      destination.         251 User not local; will forward to <forward-path>            This reply indicates that the receiver-SMTP knows the user's            mailbox is on another host and indicates the correct            forward-path to use in the future.  Note that either the            host or user or both may be different.  The receiver takes            responsibility for delivering the message.         551 User not local; please try <forward-path>            This reply indicates that the receiver-SMTP knows the user's            mailbox is on another host and indicates the correct            forward-path to use.  Note that either the host or user or            both may be different.  The receiver refuses to accept mail            for this user, and the sender must either redirect the mail            according to the information provided or return an error            response to the originating user.      Example 2 illustrates the use of these responses.      -------------------------------------------------------------                         Example of Forwarding      Either      S: RCPT TO:<Postel@USC-ISI.ARPA>      R: 251 User not local; will forward to <Postel@USC-ISIF.ARPA>      Or      S: RCPT TO:<Paul@USC-ISIB.ARPA>      R: 551 User not local; please try <Mockapetris@USC-ISIF.ARPA>                               Example 2      -------------------------------------------------------------Postel                                                          [Page 7]                                                                        August 1982                                                      RFC 821Simple Mail Transfer Protocol                                              3.3.  VERIFYING AND EXPANDING      SMTP provides as additional features, commands to verify a user      name or expand a mailing list.  This is done with the VRFY and      EXPN commands, which have character string arguments.  For the      VRFY command, the string is a user name, and the response may      include the full name of the user and must include the mailbox of      the user.  For the EXPN command, the string identifies a mailing      list, and the multiline response may include the full name of the      users and must give the mailboxes on the mailing list.      "User name" is a fuzzy term and used purposely.  If a host      implements the VRFY or EXPN commands then at least local mailboxes      must be recognized as "user names".  If a host chooses to      recognize other strings as "user names" that is allowed.      In some hosts the distinction between a mailing list and an alias      for a single mailbox is a bit fuzzy, since a common data structure      may hold both types of entries, and it is possible to have mailing      lists of one mailbox.  If a request is made to verify a mailing      list a positive response can be given if on receipt of a message      so addressed it will be delivered to everyone on the list,      otherwise an error should be reported (e.g., "550 That is a      mailing list, not a user").  If a request is made to expand a user      name a positive response can be formed by returning a list      containing one name, or an error can be reported (e.g., "550 That      is a user name, not a mailing list").      In the case of a multiline reply (normal for EXPN) exactly one      mailbox is to be specified on each line of the reply.  In the case      of an ambiguous request, for example, "VRFY Smith", where there      are two Smith's the response must be "553 User ambiguous".      The case of verifying a user name is straightforward as shown in      example 3.[Page 8]                                                          Postel                                                                        RFC 821                                                      August 1982                                           Simple Mail Transfer Protocol      -------------------------------------------------------------                    Example of Verifying a User Name         Either            S: VRFY Smith            R: 250 Fred Smith <Smith@USC-ISIF.ARPA>         Or            S: VRFY Smith            R: 251 User not local; will forward to <Smith@USC-ISIQ.ARPA>         Or            S: VRFY Jones            R: 550 String does not match anything.         Or            S: VRFY Jones            R: 551 User not local; please try <Jones@USC-ISIQ.ARPA>         Or            S: VRFY Gourzenkyinplatz            R: 553 User ambiguous.                               Example 3      -------------------------------------------------------------Postel                                                          [Page 9]                                                                        August 1982                                                      RFC 821Simple Mail Transfer Protocol                                                 The case of expanding a mailbox list requires a multiline reply as      shown in example 4.      -------------------------------------------------------------                  Example of Expanding a Mailing List         Either            S: EXPN Example-People            R: 250-Jon Postel <Postel@USC-ISIF.ARPA>            R: 250-Fred Fonebone <Fonebone@USC-ISIQ.ARPA>            R: 250-Sam Q. Smith <SQSmith@USC-ISIQ.ARPA>            R: 250-Quincy Smith <@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA>            R: 250-<joe@foo-unix.ARPA>            R: 250 <xyz@bar-unix.ARPA>         Or            S: EXPN Executive-Washroom-List            R: 550 Access Denied to You.                               Example 4      -------------------------------------------------------------      The character string arguments of the VRFY and EXPN commands      cannot be further restricted due to the variety of implementations      of the user name and mailbox list concepts.  On some systems it      may be appropriate for the argument of the EXPN command to be a      file name for a file containing a mailing list, but again there is      a variety of file naming conventions in the Internet.      The VRFY and EXPN commands are not included in the minimum      implementation (Section 4.5.1), and are not required to work      across relays when they are implemented.[Page 10]                                                         Postel                                                                        RFC 821                                                      August 1982                                           Simple Mail Transfer Protocol   3.4.  SENDING AND MAILING      The main purpose of SMTP is to deliver messages to user's      mailboxes.  A very similar service provided by some hosts is to      deliver messages to user's terminals (provided the user is active      on the host).  The delivery to the user's mailbox is called      "mailing", the delivery to the user's terminal is called      "sending".  Because in many hosts the implementation of sending is      nearly identical to the implementation of mailing these two      functions are combined in SMTP.  However the sending commands are      not included in the required minimum implementation      (Section 4.5.1).  Users should have the ability to control the      writing of messages on their terminals.  Most hosts permit the      users to accept or refuse such messages.      The following three command are defined to support the sending      options.  These are used in the mail transaction instead of the      MAIL command and inform the receiver-SMTP of the special semantics      of this transaction:         SEND <SP> FROM:<reverse-path> <CRLF>            The SEND command requires that the mail data be delivered to            the user's terminal.  If the user is not active (or not            accepting terminal messages) on the host a 450 reply may            returned to a RCPT command.  The mail transaction is            successful if the message is delivered the terminal.         SOML <SP> FROM:<reverse-path> <CRLF>            The Send Or MaiL command requires that the mail data be            delivered to the user's terminal if the user is active (and            accepting terminal messages) on the host.  If the user is            not active (or not accepting terminal messages) then the            mail data is entered into the user's mailbox.  The mail            transaction is successful if the message is delivered either            to the terminal or the mailbox.         SAML <SP> FROM:<reverse-path> <CRLF>            The Send And MaiL command requires that the mail data be            delivered to the user's terminal if the user is active (and            accepting terminal messages) on the host.  In any case the            mail data is entered into the user's mailbox.  The mail            transaction is successful if the message is delivered the            mailbox.Postel                                                         [Page 11]                                                                        August 1982                                                      RFC 821Simple Mail Transfer Protocol                                                 The same reply codes that are used for the MAIL commands are used      for these commands.