rfc772.txt

RFC 相关的技术文档

         <host> ::= <string>

         <user> ::= <string>

         <char> ::= any of the 128 ASCII characters except <CR> and <LF>






                                   8


                                                                        
RFC 772                                                   September 1980
                                                  Mail Transfer Protocol



   CONTROL FUNCTIONS

      Most time-sharing systems provide mechanisms to allow a terminal
      user to regain control of a "runaway" process.  When used locally,
      such systems have access to all user-supplied signals, whether
      these are normal characters or special "out of band" signals.
      When terminals are connected to the system through the network,
      the system does not necessarily have access to all user signals;
      the network's flow control mechanisms may cause such signals to be
      buffered elsewhere, for example in the user's host.

      To counter this problem, the TELNET "Synch" mechanism is used.  A
      Synch signal consists of a TCP Urgent or an NCP Interrupt
      notification, coupled with the TELNET command DATA MARK (DM).
      This notification, which is not subject to the flow control
      pertaining to the TELNET connection, is used to invoke special
      handling of the data stream by the process which receives it.  In
      this mode the data stream is immediately scanned for a TELNET
      Interrupt Process (IP) command.  (The rationale for the use of the
      TELNET IP command is to allow an existing server TELNET module to
      sit "under" the MTP.  If this code were directly implemented in
      the MTP the IP command would be unnecessary.)  The TELNET command
      DM is the synchronizing mark in the data stream which indicates
      that any special signal has already occurred and the recipient can
      return to normal processing of the data stream.  For a more
      complete understanding of this mechanism, see the TELNET Protocol
      Specification in the Internet Protocol Handbook.

      The effect of this mechanism is to to discard all characters (up
      to the DM) between the sender of the Synch and its recipeint.
      Thus, all characters in the control connection are ignored until
      the TELNET command DM is received.  The full sequence is
      illustrated below.  Each vertical bar (|) represents the boundary
      between data octets; IAC refers to the TELNET command code
      Interpret As Command.

                       Old                       New
                    -+-+-+-+-+-----+---+--+---+--+-  
                  ...|M|A|I|L| ... |IAC|IP|IAC|DM|...
                    -+-+-+-+-+-----+---+--+---+--+-  









                                   9


                                                                        
September 1980                                                   RFC 772
Mail Transfer Protocol                                                  



MTP REPLIES

   Replies to Mail Transfer Protocol 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.  Every command must generate at least one reply,
   although there may be more than one.  In the latter case, the
   multiple replies must be easily distinguished.  Additionally, some
   commands must occur sequentially, such as MRSQ T->MAIL->MRCP or
   MRSQ R->MRCP->MAIL.  Replies to these sequences show the existence of
   an intermediate state if all preceding commands have been successful.
   A failure at any point in the sequence necessitates the repetition of
   the entire sequence from the beginning.

      The details of the command-reply sequence are made explicit in the
      section on 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.

   Formally, a reply is defined to be the sequence:  a three-digit code,
   space <SP>, one line of text (where the maximum line length is 65),
   and a terminal <CRLF>.  Occasionally the text is longer than a single
   line; in these cases the complete text must be bracketed so the
   sender-MTP knows when it can stop reading the reply.  This requires a
   special first line format to indicate a multiple line reply, and
   another on the last line to so designate it.  Both lines will contain
   the appropriate reply code which indicates the transaction state.

      Thus the format for multi-line replies is that the first line will
      begin with the exact required reply code, followed immediately by
      a Hyphen, "-" (also known as minus), followed by text.  The last
      line will begin with the same code, followed immediately by space
      <SP>, optionally some text, and <CRLF>.








                                   10


                                                                        
RFC 772                                                   September 1980
                                                  Mail Transfer Protocol



         For example:
                                123-First line
                                Second line
                                  234 A line beginning with numbers
                                123 The last line

      The sender-MTP then simply needs to search for the second
      occurrence of the same reply code followed by <SP> (space> at the
      beginning of a line, and ignore all intermediary lines.  If an
      intermediary line begins with a three-digit number, the receiver
      must pad the front to avoid confusion.

         This scheme allows standard system routines to be used for
         reply information, with "artificial" first and last lines
         tacked on.  In the rare cases where these routines are able to
         generate three digits and a space at the beginning of any line,
         the beginning of each text line should be offset by some
         neutral text, like space.

      This scheme assumes that multi-line replies may not be nested.  In
      general, reply nesting will not occur except for random system
      messages (also called spontaneous replies) which may interrupt
      another reply.  System messages (i.e., those not processed by the
      receiver-MTP) will NOT carry reply codes and may occur anywhere in
      the command-reply sequence.  They may be ignored by the sender-MTP
      as they are only information for the human user.

   The three digits of the reply each have a special significance.  This
   is intended to allow a range of very simple to very sophisticated
   response by the sender-MTP.  The first digit denotes whether the
   response is good, bad or incomplete.  (Referring to the state
   diagram) an unsophisticated sender-MTP will be able to determine its
   next action (proceed as planned, redo, retrench, etc.) by simply
   examining this first digit.  A sender-MTP that wants to know
   approximately what kind of error occurred (e.g., mail system error,
   command syntax error) may examine the second digit, reserving the
   third digit for the finest gradation of information.

      There are five values for the first digit of the reply code:

         1yz   Positive Preliminary reply

            The requested action is being initiated; expect another
            reply before proceeding with a new command.  (The sender-MTP
            sending another command before the completion reply would be




                                   11


                                                                        
September 1980                                                   RFC 772
Mail Transfer Protocol                                                  



            in violation of protocol.  However, receiver-MTP processes
            should queue any commands that arrive while a preceding
            command is in progress.)

         2yz   Positive Completion reply

            The requested action has been successfully completed.  A new
            request may be initiated.

         3yz   Positive Intermediate reply

            The command has been accepted, but the requested action is
            being held in abeyance, pending receipt of further
            information.  The sender-MTP should send another command
            specifying this information.  This reply is used in command
            sequence groups.

         4yz   Transient Negative Completion reply

            The command was not accepted and the requested action did
            not occur.  However, the error condition is temporary and
            the action may be requested again.  The sender should return
            to the beginning of the command sequence (if any).  It is
            difficult to assign a meaning to "transient" when two
            different sites (receiver- and sender- MTPs) must agree on
            the interpretation.  Each reply in this category might have
            a different time value, but the sender-MTP is encouraged to
            try again.  A rule of thumb to determine if a reply fits
            into the 4yz or the 5yz category (see below) is that replies
            are 4yz if they can be repeated without any change in
            command form or in properties of the sender or receiver.
            (E.g., the command is repeated identically; the receiver
            does not put up a new implementation).

         5yz   Permanent Negative Completion reply

            The command was not accepted and the requested action did
            not occur.  The sender-MTP is discouraged from repeating the
            exact request (in the same sequence).  Even some "permanent"
            error conditions can be corrected, so the human user may
            want to direct the sender-MTP to reinitiate the command
            sequence by direct action at some point in the future (e.g.,
            after the spelling has been changed, or the user has altered
            his/her directory status.)





                                   12


                                                                        
RFC 772                                                   September 1980
                                                  Mail Transfer Protocol



      The second digit encodes responses in specific categories:

         x0z   Syntax -- These replies refer to syntax errors,
               syntactically correct commands that don't fit any
               functional category, and unimplemented or superfluous
               commands.

         x1z   Information --  These are replies to requests for
               information, such as status or help.

         x2z   Connections -- These are replies referring to the control
               connection.

         x3z   Unspecified as yet.

         x4z   Unspecified as yet.

         x5z   Mail system -- These replies indicate the status of the
               receiver mail system vis-a-vis the requested transfer or
               other mail system action.

      The third digit gives a finer gradation of meaning in each
      category specified by the second digit.  The list of replies below
      will illustrate this.  Each reply text is recommended rather than
      mandatory, and may even change according to the command with which
      it is associated.  On the other hand, the reply codes must
      strictly follow the specifications in this section.  Receiver
      implementations should not invent new codes for slightly different
      situations from the ones described here, but rather adapt codes
      already defined.

         A command such as NOOP whose successful execution does not
         offer the sender-MTP any new information will return a 200
         reply.  The response is 502 when the command requests an
         unimplemented non-site-specific action.  A refinement of that
         is the 504 reply for a command that IS implemented, but that
         requests an unimplemented parameter.

   REPLY CODES BY FUNCTION GROUPS

      200 Command okay
      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



                                   13


                                                                        
September 1980                                                   RFC 772
Mail Transfer Protocol                                                  



       
      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 control connection
      421 <host> Service not available, closing control connection
         [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 space
      552 Requested mail action aborted: exceeded storage allocation
         [For current mailbox location]
      553 Requested action not taken: mailbox name not allowed
      354 Start mail input; end with <CR><LF>.<CR><LF>
      

   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
      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 control connection
      250 Requested mail action okay, completed
      354 Start mail input; end with <CR><LF>.<CR><LF>



                                   14


                                                                        
RFC 772                                                   September 1980
                                                  Mail Transfer Protocol



      421 <host> Service not available, closing control connection
         [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 space
      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
      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
      

DISCUSSION OF MAIL TRANSFER

   The basic command for transmitting mail is MAIL.  This command causes
   the transmitted data to be entered into the recipient's mailbox.

      MAIL <SP> "FROM:" <sender> [<SP> "TO:" <path>] <CRLF>

         <sender> is a mailbox and <path> is a source routing list of
         hosts and destination mailbox.  If accepted, it returns a 354
         reply and considers all succeeding lines to be the message
         text.  It is terminated by a line containing only a period,
         upon which a 250 completion reply is returned.  Various errors
         are possible.

   There are two possible preliminary replies that a receiver may use to
   indicate that it is accepting mail for a user whose mailbox is not at
   that receiver.

      151 User not local; will forward to <user>@<host>

         This reply indicates that the receiver knows the user's mailbox
         is on another host and will take responsibility for forwarding
         the mail to that host.  For example, at BBN (or ISI) there are
         several hosts.  Each has a list of many of the users on the
         hosts.  Each host can accept mail for any user on their list
         and forward it to the correct host.




                                   15


                                                                        
September 1980                                                   RFC 772
Mail Transfer Protocol                                                  



      152 User Unknown; mail will be forwarded by the operator

         This reply indicates that the host does not recognize the user
         name, but that it will accept the mail and have the operator
         attempt to deliver it.  This is useful if the user name is
         misspelled, but may be a disservice if the mail is really
         undeliverable.

   If forwarding by the operator is unacceptable or if the user would
   prefer to send the mail directly to the recipient's actual host, the
   dialogue may be terminated upon receipt of one of these preliminary
   responses.

   There are two MTP commands which allow the text of a message to be
   mailed to several recipients simultaneously; such message
   transmission is far more efficient than the practice of sending the
   text again and again for each additional recipient at a site.  In
   one, all recipients are specified first, and then the text is sent.
   In the other, the order is reversed and the text is sent first,
   followed by the recipients.  Both schemes are necessary because
   neither by itself is optimal for all systems, as will be explained
   later.  To select a particular scheme, the MRSQ command is used; to
   specify recipients after a scheme is chosen, MRCP commands are given;