rfc780.txt

RFC 相关的技术文档

            <scheme> ::= "R" | "T" | "?"

            <string> ::= <char> | <char> <string>

            <path> ::= "<" ["@" <host> "," ...] <mailbox> ">"

            <host> ::= <a> <string> | "#" <number> | "[" <dotnum> "]"

            <mailbox> ::= <user> "@" <host>

            <user> ::= <string>

            <char> ::= <c> | '\' <c> | '\' <s>

            <dotnum> ::= <snum> "." <snum> "." <snum> "." <snum>

            <number> ::= <d> | <d> <number>

            <snum> ::= three digits representing an integer value in the
            range 0 through 255

            <specials> ::= '<', '>', '(', ')', '\', ',', ';', ':', '@',
            '"', and the control characters (ASCII codes 0 through 37
            octal inclusive and 177 octal)

            <a> ::= any one of the 26 letters A through Z in either case

            <c> ::= any one of the 128 ASCII characters except
            <specials>

            <d> ::= any one of the ten digits 0 through 9

            <s> ::= any one of <specials>

            Note that the backslash, '\', is a quote character, which is
            used to indicate that the next character is to be used
            literally instead of with its normal interpretation.  For




[Page 20]                                               Sluizer & Postel


                                                                        
RFC 780                                                         May 1981
                                                  Mail Transfer Protocol



            example, "Joe\,Smith" could be used to indicate a single
            nine character user field with comma being the fourth
            character of the field.

         Hosts are generally known by names which are translated to
         addresses  in each host.  Sometimes a host is not known to the
         translation function and communication is blocked.  To bypass
         this barrier numeric forms are also allowed for host "names".
         One form is a decimal integer prefixed by a pound sign, "#",
         which indicates the number is the address of the host.  Another
         form is four small decimal integers separated by dots and
         enclosed by brackets, e.g., "[123.255.37.321]", which indicates
         a 32 bit ARPA Internet Address in four eight bit fields.

         


































Sluizer & Postel                                               [Page 21]


                                                                        
May 1981                                                         RFC 780
Mail Transfer Protocol                                                  



   5.2.  MTP REPLIES

      Replies to MTP commands are devised to ensure the synchronization
      of requests and actions in the process of mail transfer, and to
      guarantee that the sender-MTP always knows the state of the
      receiver-MTP.  Every command must generate exactly one reply.
      Additionally, some commands must occur sequentially, such as
      MRSQ T->MAIL->MRCP or MRSQ R->MRCP->MAIL.

         The details of the command-reply sequence are made explicit in
         the Sections 5.3 and 5.4 on Sequencing and State Diagrams.

      An MTP reply consists of a three digit number (transmitted as
      three alphanumeric characters) followed by some text.  The number
      is intended for use by automata to determine what state to enter
      next; the text is meant for the human user.  It is intended that
      the three digits contain enough encoded information that the
      sender-MTP will not need to examine the text and may either
      discard it or pass it on to the user, as appropriate.  In
      particular, the text may be receiver-dependent, so there are
      likely to be varying texts for each reply code. Further
      explanation of the assignment of reply codes is given in the
      Appendix E on the Theory of Reply Codes.  Formally, a reply is
      defined to be the sequence:  a three-digit code, <SP>, one line of
      text, and <CRLF>.
























[Page 22]                                               Sluizer & Postel


                                                                        
RFC 780                                                         May 1981
                                                  Mail Transfer Protocol



      5.2.1.  REPLY CODES BY FUNCTION GROUPS

         200 Command okay
         201 Command okay, action aborted
         500 Syntax error, command unrecognized
            [This may include errors such as command line too long]
         501 Syntax error in parameters or arguments
         502 Command not implemented
         503 Bad sequence of commands
         504 Command parameter not implemented
          
         211 System status, or system help reply
         214 Help message
            [Information on how to use the receiver or the meaning of a
            particular non-standard command; this reply is useful only
            to the human user]
         215 <scheme> is the preferred scheme
          
         120 <host> Service ready in nnn minutes
         220 <host> Service ready for new user
         221 <host> Service closing transmission channel
         421 <host> Service not available, closing transmission channel
            [This may be a reply to any command if the service knows it
            must shut down]
          
         151 User not local; will forward to <user>@<host>
         152 User unknown; mail will be forwarded by the operator
         250 Requested mail action okay, completed
         450 Requested mail action not taken: mailbox unavailable
            [E.g., mailbox busy]
         550 Requested action not taken: mailbox unavailable
            [E.g., mailbox not found, no access]
         451 Requested action aborted: local error in processing
         452 Requested action not taken: insufficient system storage
         552 Requested mail action aborted: exceeded storage allocation
            [For current mailbox location]
         553 Requested action not taken: mailbox name not allowed
            [E.g., mailbox syntax incorrect]
         354 Start mail input; end with <CRLF>.<CRLF>
         









Sluizer & Postel                                               [Page 23]


                                                                        
May 1981                                                         RFC 780
Mail Transfer Protocol                                                  



      5.2.2.  NUMERIC ORDER LIST OF REPLY CODES

         120 <host> Service ready in nnn minutes
         151 User not local; will forward to <user>@<host>
         152 User unknown; mail will be forwarded by the operator
          
         200 Command okay
         201 Command okay, action aborted
         211 System status, or system help reply
         214 Help message
            [Information on how to use the receiver or the meaning of a
            particular non-standard command; this reply is useful only
            to the human user]
         215 <scheme> is the preferred scheme
         220 <host> Service ready for new user
         221 <host> Service closing transmission channel
         250 Requested mail action okay, completed
          
         354 Start mail input; end with <CRLF>.<CRLF>
          
         421 <host> Service not available, closing transmission channel
            [This may be a reply to any command if the service knows it
            must shut down]
         450 Requested mail action not taken: mailbox unavailable
            [E.g., mailbox busy]
         451 Requested action aborted: local error in processing
         452 Requested action not taken: insufficient system storage
          
         500 Syntax error, command unrecognized
            [This may include errors such as command line too long]
         501 Syntax error in parameters or arguments
         502 Command not implemented
         503 Bad sequence of commands
         504 Command parameter not implemented
         550 Requested action not taken: mailbox unavailable
            [E.g., mailbox not found, no access]
         552 Requested mail action aborted: exceeded storage allocation
            [For current mailbox location]
         553 Requested action not taken: mailbox name not allowed
            [E.g., mailbox syntax incorrect]
         








[Page 24]                                               Sluizer & Postel


                                                                        
RFC 780                                                         May 1981
                                                  Mail Transfer Protocol



   5.3.  SEQUENCING OF COMMANDS AND REPLIES

      The communication between the sender and receiver is intended to
      be an alternating dialogue.  As such, the sender issues an MTP
      command and the receiver responds with a prompt primary reply.
      The sender should wait for this response before sending further
      commands.

      The preliminary (1xx) and intermediate (3xx) replies indicate that
      further commands and information are required to complete the
      required action.  The preliminary replies require either a
      continue or abort command to proceed; the intermediate replies
      require action dependent further commands.

      One important reply is the connection greetings.  Under normal
      circumstances, a receiver will send a 220 "Awaiting input" reply
      when the connection is completed.  The sender should wait for this
      greeting message before sending any commands.  If the receiver is
      unable to accept input right away, it should send a 120 "Expected
      delay" reply immediately.  The sender can then indicate it is
      willing to wait via a continue command, or not via the abort
      command.  The receiver will respond to the abort with a 201 reply,
      and to the continue with the 220 reply when ready.

         Note: all the greeting type replies have the official name of
         the server host as the first word following the reply code.

            For example,

               220 <SP> USC-ISIF <SP> Service ready <CRLF>

      The table below lists alternative success and failure replies for
      each command.  These must be strictly adhered to; a receiver may
      substitute text in the replies, but the meaning and action implied
      by the code numbers and by the specific command reply sequence
      cannot be altered.

      COMMAND-REPLY SEQUENCES

         Each command is listed with its possible replies.  Preliminary
         replies are listed first with their succeeding replies indented
         under them, then success and failure completion, and finally
         intermediary replies with the remaining commands from the
         sequence following.  The prefixes used before the possible
         replies are "P" for preliminary, "I" for intermediate, "S" for
         success, "F" for failure, and "E" for error.  The 421 reply



Sluizer & Postel                                               [Page 25]


                                                                        
May 1981                                                         RFC 780
Mail Transfer Protocol                                                  



         (service not available, closing transmission channel) may be
         given to any command if the MTP-receiver knows it must shut
         down.  This listing forms the basis for the State Diagrams, in
         Section 5.4.

            CONNECTION ESTABLISHMENT
               P: 120 -> CONT -> S: 220
                                 F: 421
                         ABRT    S: 201
                                 F: 421
               S: 220
               F: 421
            MAIL
               P: 151 -> CONT -> I: 354 -> text -> S: 250
                  152                              F: 451,552,450,
                                                      550,452,553
                         ABRT -> S: 201
                                 F: 451,552,450,550,452,553
               I: 354 -> text -> S: 250
                                 F: 451,552,450,550,452,553
               F: 451, 552, 450, 550, 452, 553
               E: 500, 501, 502, 421
            MRSQ
               S: 200, 215
               E: 500, 501, 502, 504, 421
            MRCP
               P: 151 -> CONT -> S: 200, 215, 250
                  152            F: 451,552,450,550,452,553
                         ABRT -> S: 201
                                 F: 451,552,450,550,452,553
               S: 200, 215, 250
               F: 451, 552, 450, 550, 452, 553
               E: 500, 501, 502, 503, 421
















[Page 26]                                               Sluizer & Postel


                                                                        
RFC 780                                                         May 1981
                                                  Mail Transfer Protocol



            QUIT
               S: 221
               E: 500, 421
            HELP
               S: 211, 214
               E: 500, 501, 502, 504, 421
            NOOP
               S: 200