rfc772.txt

RFC 相关的技术文档

   and to furnish text, the MAIL command is used.

   SCHEME SELECTION:  MRSQ

      MRSQ is the means by which a sender-MTP can test for MRSQ/MRCP
      implementation, select a particular scheme, reset its state, and
      even do some rudimentary negotiation.  Its format is as follows:

         MRSQ [<SP> <scheme>] <CRLF>

         <scheme> is a single character.  The following are defined:
            R  Recipients first.  If this is not implemented, T must be.
            T  Text first.  If this is not implemented, R must be.
            ?  Request for preference.  This must always be implemented.

            No argument means a "selection" of none of the schemes (the
            default).

         Possible replies are:
            200 OK, we'll use specified scheme
            215 <scheme> This is the scheme I prefer
            501 I understand MRSQ but can't use that scheme
            5xx Command unrecognized or unimplemented



                                   16


                                                                        
RFC 772                                                   September 1980
                                                  Mail Transfer Protocol



      There are three aspects of MRSQ.  The first is that an MRSQ with
      no argument must always return a 200 reply and restore the default
      state of having no scheme selected.  Any other reply implies that
      MRSQ and hence MRCP are not understood or cannot be performed
      correctly.

      The second is that the use of "?" as a <scheme> asks the MTP
      receiver to return a 215 reply in which the receiver specifies a
      "preferred" scheme.  The format of this reply is simple:

         215 <SP> <scheme> [<SP> <arbitrary text>] <CRLF>

         Any other reply (e.g., 4xx or 5xx) implies that MRSQ and MRCP
         are not implemented, because "?" must always be implemented if
         MRSQ is.

      The third important point about MRSQ is that it always has the
      side effect of resetting all schemes to their initial state.  This
      reset must be done no matter what the reply will be -- 200, 215,
      or 501.  The actions necessary for a reset will be explained when
      discussing how each scheme actually works.

   MESSAGE TEXT SPECIFICATION:  MAIL

      Regardless of which scheme (if any) has been selected, a MAIL
      command with a non-null "TO" argument will behave exactly as
      before; the MRSQ/MRCP commands have no effect on it.  However, a
      normal MAIL command does have the same side effect as MRSQ; it
      "resets" the current scheme to its initial state.

      It is only when the "TO" argument is null (e.g., MAIL FROM:<X@Y>
      <CRLF>) that the particular scheme chosen is important.  Rather
      than producing an error (as most receivers currently do), the
      receiver will accept message text for this "null" specification.
      What it does with it depends on which scheme is in effect, and
      will be described in the section on Scheme Mechanics.













                                   17


                                                                        
September 1980                                                   RFC 772
Mail Transfer Protocol                                                  



   RECIPIENT SPECIFICATION:  MRCP

      In order to specify recipient names (i.e., mailboxes) and receive
      some acknowledgment (or refusal) for each name, the following
      command is used:

         MRCP <SP> TO:<path> <CRLF>

         Reply for no scheme:
            503 No scheme specified yet; use MRSQ
         Replies for scheme T are identical to those for MAIL.
         Replies for scheme R (recipients first):
            200 OK, name stored
            452 Recipient table full, this name not stored
            553 Recipient name rejected
            4xx Temporary error, try this name again later
            5xx Permanent error, report to sender

      Note that use of this command is an error if no scheme has been
      selected yet; an MRSQ <scheme> must have been given if MRCP is to
      be used.

   SCHEME MECHANICS:  MRSQ R (RECIPIENTS-FIRST)

      In the recipients-first scheme, MRCP is used to specify names
      which the MTP receiver stores in a list or table.  Normally the
      reply for each MRCP will be either a 200 for acceptance or a
      4xx/5xx rejection code.  All 5xx codes are permanent rejections
      (e.g., user not known) which should be reported to the human user,
      whereas 4xx codes in general connote some temporary error that may
      be rectified later.  None of the 4xx/5xx replies impinge on
      previous or succeeding MRCP commands, except for 452 which
      indicates that no further MRCPs will succeed unless a message is
      sent to the already stored recipients or a reset is done.















                                   18


                                                                        
RFC 772                                                   September 1980
                                                  Mail Transfer Protocol



      Sending message text to stored recipients is done by giving a MAIL
      command with no "TO" argument; that is, just MAIL <SP> <sender>
      <CRLF>.  Transmission of the message text is exactly the same as
      for normal MAIL.  However, a positive acknowledgment at the end of
      transmission means the message has been sent to ALL recipients
      that were remembered with MRCP, and a failure code means that it
      should be considered to have failed for ALL of these specified
      recipients.  This applies regardless of the actual error code.
      Regardless of what the reply signifies, all stored recipient names
      are flushed and forgotten -- in other words, things are reset to
      their initial state.  This purging of the recipient name list must
      also be done as the reset side effect of any use of MRSQ.

      A 452 reply to an MRCP can be handled by using MAIL to specify the
      message for currently stored recipients, and then sending more
      MRCPs and another MAIL, as many times as necessary.  For example,
      if a receiver only had room for 10 names this would result in a
      50-recipient message being sent 5 times, to 10 different
      recipients each time.

      If a sender attempts to specify message text (MAIL with no "TO"
      argument) before any successful MRCPs have been given, this should
      be treated exactly as a "normal" MAIL with a null recipient would
      be; some receivers return an error, such as "550 Null recipient".

      See the example in Appendix A for a mail transfer using MRSQ R.

   SCHEME MECHANICS:  MRSQ T (TEXT-FIRST)

      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