rfc772.txt

RFC 的详细文档！

      In the text-first scheme, MAIL with no "TO" argument is used to
      specify message text, which the receiver stores away.  Succeeding
      MRCPs are then treated as if they were MAIL commands, except that
      none of the text transfer manipulations are done; the stored
      message text is sent to the specified recipient, and a reply code
      is returned identical to that which an actual MAIL would invoke.
      (Note that ANY 2xx code indicates success.)

      The stored message text is not forgotten until the next MAIL or
      MRSQ, which will either replace it with new text or flush it
      entirely.  Any use of MRSQ will reset this scheme by flushing
      stored text, as will any use of MAIL with a non-null argument.

      If an MRCP is seen before any message text has been stored, the
      sender in effect is trying to send a null message; some receivers
      might allow this, others would return an error code.




                                   19


                                                                        
September 1980                                                   RFC 772
Mail Transfer Protocol                                                  



      See the example in Appendix B for a mail transfer using MRSQ T.

   WHY TWO SCHEMES ANYWAY?

      Because neither by itself is optimal for all systems.  MRSQ R
      allows more of a "bulk" mailing because everything is saved up and
      then mailed simultaneously.  This is very useful for systems such
      as ITS where the MTP-receiver does not itself write mail directly,
      but hands it on to a central mailer demon of great power.  The
      more information (e.g., recipients) associated with a single
      "hand-off", the more efficiently mail can be delivered.

      By contrast, MRSQ T is geared to receiver-MTPs which want to
      deliver mail directly, in one-by-one incremental fashion.  For
      each given recipient this scheme returns an individual
      success/failure reply code which may depend on variable mail
      system factors such as exceeding disk allocation, mailbox access
      conflicts, and so forth.  If these receiver-MTPs tried to emulate
      MRSQ Rs bulk mailing, they would have to ensure that a success
      reply to the MAIL indeed meant that it had been delivered to ALL
      recipients specified -- not just some.

   NOTES:

      * Because these commands are not required in the minimum
        implementation of MTP, one must be prepared to deal with sites
        which don't recognize either MRSQ or MRCP.  "MRSQ" and "MRSQ ?"
        are explicitly designed as tests to see whether either scheme is
        implemented.  MRCP is not designed as a test, and a failure
        return of the "unimplemented" variety could be confused with "No
        scheme selected yet", or even with "Recipient unknown".

      * There is no way to indicate in a positive response to "MRSQ ?"
        that the preferred "scheme" for a receiver is that of the
        default state; i.e., none of the multi-recipient schemes.  The
        rationale is that in this case, it would be pointless to
        implement MRSQ/MRCP at all, and the response would therefore be
        negative.











                                   20


                                                                        
RFC 772                                                   September 1980
                                                  Mail Transfer Protocol



      * One reason that the use of MAIL is restricted to null "TO"
        arguments with this multi-recipient extension is the ambiguity
        that would result if a non-null "TO" argument were allowed.  For
        example, if MRSQ R was in effect and some MRCPs had been given,
        and a MAIL FROM:<X@Y> TO:<FOO><CRLF> was done, there would be no
        way to distinguish a failure reply for mailbox "FOO" from a
        global failure for all recipients specified.  A similar
        situation exists for MRSQ T; it would not be clear whether the
        text was stored and the mailbox failed, or vice versa, or both.

      * "Resets" are done by all MRSQs and "normal" MAILs to avoid
        confusion and overly complicated implementation.  The MRSQ
        command implies a change or uncertainty of status, and the MAIL
        command would otherwise have to use some independent mechanisms
        to avoid clobbering the data bases (e.g., message text storage
        area) used by the T/R schemes.  However, once a scheme is
        selected, it remains "in effect" just as an FTP "TYPE A" remains
        selected.  The recommended way for doing a reset, without
        changing the current selection, is with "MRSQ ?".  Remember that
        "MRSQ" alone reverts to the no-scheme state.

      * It is permissible to intersperse other MTP commands among the
        MRSQ/MRCP/MAIL sequences.


























                                   21


                                                                        
September 1980                                                   RFC 772
Mail Transfer Protocol                                                  



DECLARATIVE SPECIFICATIONS

   MINIMUM IMPLEMENTATION

      In order to make MTP workable without needless error messages, the
      following minimum implementation is required for all receivers:

         COMMANDS -- QUIT
                     MAIL
                     NOOP

      In terms of FTP, the values of the transfer parameters must be:

         TYPE -- ASCII
         MODE -- STREAM
         STRU -- FILE-STRUCTURE

      All hosts must use the above values for mail transfer.

   CONNECTIONS

      The receiver-MTP shall "listen" on Port L.  The sender-MTP shall
      initiate the TCP/NCP control connection.  The control connection
      consists of a full-duplex connection under TCP; it is two simplex
      connections under NCP.  Receiver- and sender- MTPs should follow
      the conventions of the TELNET Protocol as specified in the ARPA
      Internet Protocol Handbook.  Receivers are under no obligation to
      provide for editing of command lines and may specify that it be
      done in the sender host.  The control connection shall be closed
      by the receiver at the sender's request after all transfers and
      replies are completed.

   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 initial primary success or failure
      response before sending further commands.

      Certain commands require a second reply for which the sender
      should also wait.  These replies may, for example, report on the
      progress or completion of mail transfer.  They are secondary
      replies to mail transfer commands.

      One important group of informational replies is the connection



                                   22


                                                                        
RFC 772                                                   September 1980
                                                  Mail Transfer Protocol



      greetings.  Under normal circumstances, a receiver will send a 220
      reply, "awaiting input", 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 and a 220
      reply when ready.  The sender will then know not to hang up if
      there is a delay.

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

      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

         In this section, the command-reply sequence is presented.  Each
         command is listed with its possible replies; command groups are
         listed together.  Preliminary replies are listed first (with
         their succeeding replies indented under them), then positive
         and negative completion, and finally intermediary replies with
         the remaining commands from the sequence following.  The 421
         reply (service not available, closing control connection) may
         be given at any point if the MTP-receiver knows it must shut
         down.  This listing forms the basis for the state diagrams,
         which will be presented separately.

            CONNECTION ESTABLISHMENT
               120
                  220
               220
               421
            MAIL ACTION COMMANDS
               MAIL
                  151, 152
                     354
                        250
                        451, 552
                  354
                     250
                     451, 552
                  450, 550, 452, 553
                  500, 501, 502, 421



                                   23


                                                                        
September 1980                                                   RFC 772
Mail Transfer Protocol                                                  



               MRSQ
                  200, 215
                  500, 501, 502, 421
               MRCP
                  151, 152
                     200
                  200
                  450, 550, 452, 553
                  500, 501, 502, 503, 421
               QUIT
                  221
            INFORMATIONAL COMMANDS
               HELP
                  211, 214
                  500, 501, 502, 421
            MISCELLANEOUS COMMANDS
               NOOP
                  200
                  500 421

STATE DIAGRAMS

   Here we present state diagrams for a very simple minded MTP
   implementation.  Only the first digit of the reply codes is used.
   There is one state diagram for each group of MTP commands.

   The command groupings were determined by constructing a model for
   each command and then collecting together the commands with
   structurally identical models.

   For each command there are three possible outcomes:  "success" (S),
   "failure" (F), and "error" (E). In the state diagrams below we use
   the symbol B for "begin", and the symbol W for "wait for reply".
















                                   24


                                                                        
RFC 772                                                   September 1980
                                                  Mail Transfer Protocol



   We first present the diagram that represents the most MTP commands:

      
                               1,3    +---+
                          ----------->| E |
                         |            +---+
                         |
      +---+    cmd    +---+    2      +---+
      | B |---------->| W |---------->| S |
      +---+           +---+           +---+
                         |
                         |     4,5    +---+
                          ----------->| F |
                                      +---+
      

      This diagram models the commands:

         HELP, MRCP, MRSQ, NOOP, QUIT.