smtp-simple mail transfer protocol.txt

黑客培训教程

Postel                                                          [Page 5]


                                                                        
August 1982                                                      RFC 821
Simple 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:<[e-mail]>
            R: 250 OK

            S: RCPT TO:<[e-mail]>
            R: 250 OK

            S: RCPT TO:<[e-mail]>
            R: 550 No such user here

            S: RCPT TO:<[e-mail]>
            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:<[e-mail]>
      R: 251 User not local; will forward to <[e-mail]>

      Or

      S: RCPT TO:<[e-mail]>
      R: 551 User not local; please try <[e-mail]>

                               Example 2

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




Postel                                                          [Page 7]


                                                                        
August 1982                                                      RFC 821
Simple Mail Transfer Protocol                                           



   3.3.  VERIFYING AND EXPANDING

      SMTP provides as additional features, commands to verify a user
      name or expand a mailing list.  This is done with the VRFY and
      EXPN commands, which have 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 <[e-mail]>

         Or

            S: VRFY Smith
            R: 251 User not local; will forward to <[e-mail]>

         Or

            S: VRFY Jones
            R: 550 String does not match anything.

         Or

            S: VRFY Jones
            R: 551 User not local; please try <[e-mail]>

         Or

            S: VRFY Gourzenkyinplatz
            R: 553 User ambiguous.

                               Example 3

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

















Postel                                                          [Page 9]


                                                                        
August 1982                                                      RFC 821
Simple Mail Transfer Protocol                                           



      The case of expanding a mailbox list requires a multiline reply as
      shown in example 4.

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

                  Example of Expanding a Mailing List

         Either

            S: EXPN Example-People
            R: 250-Jon Postel <[e-mail]>
            R: 250-Fred Fonebone <[e-mail]>
            R: 250-Sam Q. Smith <[e-mail]>
            R: 250-Quincy Smith <@USC-ISIF.ARPA:[e-mail]>
            R: 250-<[e-mail]>
            R: 250 <[e-mail]>

         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 821
Simple Mail Transfer Protocol                                           



      The same reply codes that are used for the MAIL commands are used
      for these commands.