rfc780.txt

RFC 相关的技术文档

      preliminary reply by sending a continue (CONT) or abort (ABRT)
      command.  In the case of the continue, the next reply from the
      MTP-receiver will be any of the replies expected for the MAIL
      command, most likely "354 Start mail input, ...".  In the case of
      the abort, the next reply from the MTP-receiver will be "201
      Command okay, action aborted".

   3.2.  SOURCE ROUTING

      The receiver-path may be a source route of the form
      "@ONE,@TWO,JOE@THREE", where ONE, TWO, and THREE are hosts.  This
      form is used to emphasize the distinction between an address and a
      route.

      At some distant future time it might be necessary to expand the
      mailbox format to include a region identifier, such as
      "user@host@region".  If this occured the MTP  path convention
      could be expanded to
      "host@region,host@region,...user@host@region". For example,
      "ONE@R1,TWO@R2,JOE@THREE@R3".

      The mailbox is an absolute address, and the route is information
      about how to get there.  The two concepts should not be confused.

      The elements of the receiver-path are to be moved to the
      sender-path as the message is relayed from one MTP to another. The
      sender-path is a reverse source route, that is, a source route to
      the originator of the message.  When an MTP deletes its identifier
      from the receiver-path and inserts it into the sender-path, it
      must use the name it is known by in the environment it is sending
      into, not the environment the mail came from, in case the MTP is
      known be different names in different environments.

      When source routing is used the receiver-MTP will receive mail to
      be relayed to another MTP.  The receiver-MTP may accept the task
      of relaying the mail or reject it in the same way it accepts or
      reject mail for a local user.  It does not use the 151 "User not
      local" or 152 "User unknown" preliminary replies.  Once the
      receiver-MTP accepts the relaying task it receives the mail text
      and transforms the command arguments by removing its own
      identifier from the receiver-path and inserting it in the



[Page 6]                                                Sluizer & Postel


                                                                        
RFC 780                                                         May 1981
                                                  Mail Transfer Protocol



      beginning of the sender-path.  The receiver-MTP then becomes a
      sender-MTP and establishes a transmission channel to the next MTP
      in the receiver-path and sends it the mail.

      If an MTP has accepted the task of relaying the mail and later
      finds that the receiver-path is incorrect or that the mail cannot
      be delivered for whatever reason, then it must construct a
      notification message and send it to the originator of the
      undeliverable mail as indicated by the sender-path.  This
      notification message must be from the MTP at this host.  That is,
      the sender-path of the notification message itself will be
      "MTP@<host>", and in the notification message header the From
      field will be "MTP at <host>".  Of course, MTPs should not send
      notification messages about problems with notification messages.



































Sluizer & Postel                                                [Page 7]


                                                                        
May 1981                                                         RFC 780
Mail Transfer Protocol                                                  



4.  MULTI-RECIPIENT MAIL

   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 host.  In one
   scheme, all recipients are specified first, and then the text is
   sent.  In the other scheme, the order is reversed and the text is
   sent first, followed by the recipients.  The sender-MTP suggests the
   scheme it would prefer, but receiver-MTP controls which scheme is
   actually used.  To select a particular scheme, the MRSQ command is
   used; to specify recipients after a scheme is chosen, MRCP commands
   are given; and to furnish text, the MAIL command is used.

   Both schemes are necessary 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.  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.

   4.1.  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.





[Page 8]                                                Sluizer & Postel


                                                                        
RFC 780                                                         May 1981
                                                  Mail Transfer Protocol



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

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

      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> <string>] <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 reseting all schemes to their initial state.  This
      reset must be done no matter what the reply will be -- 200, 215,
      or 504.  The actions necessary for a reset will be explained when
      discussing how each scheme actually works.

      Note that the receiver gets to choose which scheme is used.  The
      sender must be prepared to do either.

   4.2.  MESSAGE TEXT SPECIFICATION:  MAIL

      Regardless of which scheme (if any) has been selected, a MAIL
      command with a non-null receiver-path 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" all schemes to their initial state.

      It is only when the receiver-path argument is null that the
      particular scheme chosen is important.

         MAIL FROM:<sender-path> <CRLF>



Sluizer & Postel                                                [Page 9]


                                                                        
May 1981                                                         RFC 780
Mail Transfer Protocol                                                  



      Rather than producing an error, the receiver will accept message
      text for this "null" recipient specification.  What it does with
      it depends on which scheme is in effect, and will be described in
      the section on Scheme Mechanics.

   4.3.  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:<receiver-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
            550 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.

   4.4.  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.

      Sending message text to stored recipients is done by giving a MAIL
      command with no receiver-path argument; that is, just MAIL <SP>
      FROM: <sender-path> <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



[Page 10]                                               Sluizer & Postel


                                                                        
RFC 780                                                         May 1981
                                                  Mail Transfer Protocol



      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 (or MAIL with a non-null receiver-path
      argument).

      A 452 reply (out of storage space) 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
      receiver-path 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".

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

                  Example of MRSQ R (Recipients First)

         First the sender must establish that the receiver implements
         MRSQ.

            S: MRSQ <CRLF>
            R: 200 OK, no scheme selected

         An MRSQ with a null argument always returns a 200 if
         implemented, selecting the default "scheme", i.e., none of
         them.  If MRSQ were not implemented, a code of 4xx or 5xx would
         be returned.

            S: MRSQ R <CRLF>
            R: 200 OK, using that scheme

         All is well; now the recipients can be specified.

            S: MRCP TO:<Foo@Y> <CRLF>
            R: 200 OK





Sluizer & Postel                                               [Page 11]


                                                                        
May 1981                                                         RFC 780
Mail Transfer Protocol                                                  



            S: MRCP TO:<Raboof@Y> <CRLF>
            R: 550 No such user here

            S: MRCP TO:<bar@Y> <CRLF>
            R: 200 OK

            S: MRCP TO:<@Y,@X,fubar@Z> <CRLF>
            R: 200 OK

         Note that the failure of "Raboof" has no effect on the storage
         of mail for "Foo", "bar" or the mail to be relayed to "fubar@Z"
         through host "X".  Now the message text is furnished, by giving
         a MAIL command with no receiver-path argument.

            S: MAIL FROM:<waldo@A><CRLF>
            R: 354 Start mail input; end with <CRLF>.<CRLF>
            S: Blah blah blah blah....etc. etc. etc.
            S: <CRLF>.<CRLF>
            R: 250 Mail sent

         The mail text has now been sent to "Foo" and "bar" as well as
         relayed to "fubar@Z".

                               Example 2

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

   4.5.  SCHEME MECHANICS:  MRSQ T (TEXT-FIRST)

      In the text-first scheme, MAIL with no receiver-path 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 receiver-path
      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.



[Page 12]                                               Sluizer & Postel


                                                                        
RFC 780                                                         May 1981
                                                  Mail Transfer Protocol



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

                     Example of MRSQ T (Text First)

         First the sender must establish that the receiver implements
         MRSQ.