rfc780.txt

RFC 相关的技术文档

            S: MRSQ ? <CRLF>
            R: 215 T Text first, please

         MRSQ is indeed implemented, and the receiver says that it
         prefers "T", but that needn't stop the sender from trying
         something else.

            S: MRSQ R <CRLF>
            R: 504 Sorry, I really can't do that

         It's possible that it could have understood "R" also, but in
         general it's best to use the "preferred" scheme, since the
         receiver knows which is most efficient for its particular site.

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

         Scheme "T" is now selected, and the message text is sent 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 stored

         Now recipients can be specified.

            S: MRCP TO:<Foo@Y> <CRLF>
            R: 250 Stored mail sent

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

            S: MRCP TO:<bar@Y> <CRLF>
            R: 250 Stored mail sent

            S: MRCP TO:<@Y,@X,fubar@Z> <CRLF>
            R: 250 Mail accepted for relaying



Sluizer & Postel                                               [Page 13]


                                                                        
May 1981                                                         RFC 780
Mail Transfer Protocol                                                  



         The text has now been sent to "Foo" and "bar" at host "Y" and
         will be relayed to "fubar@Z" through host "X", and still
         remains stored.  A new message can be sent with another
         MAIL/MRCP ... sequence, but a careful sender would reset the
         state using the exchange below.

            S: MRSQ ? <CRLF>
            R: 215 T Text first, please

         Which resets the state without altering the scheme in effect.

                               Example 3

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

   4.6.  DISCUSSION

      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.

      One reason that the use of MAIL is restricted to null
      receiver-path arguments with this multi-recipient extension is the
      ambiguity that would result if a non-null receiver-path 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@Z><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" of all schemes 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



[Page 14]                                               Sluizer & Postel


                                                                        
RFC 780                                                         May 1981
                                                  Mail Transfer Protocol



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












































Sluizer & Postel                                               [Page 15]


                                                                        
May 1981                                                         RFC 780
Mail Transfer Protocol                                                  



5.  SPECIFICATIONS

   5.1.  MTP COMMANDS

      5.1.1.  COMMAND SEMANTICS

         The MTP commands define the mail transfer or the mail system
         function requested by the user.  MTP commands are character
         strings terminated by <CRLF>.  The command codes themselves are
         alphabetic characters terminated by <SP> if parameters follow
         and <CRLF> otherwise.  The syntax of mailboxes must conform to
         receiver site conventions. The MTP commands are discussed
         below.  MTP replies are discussed in the Section 5.2.

         MAIL (MAIL)

            This command is used to send mail over the transmission
            channel.  The argument field contains a sender-path sequence
            and optional receiver-path sequence.

            The sender-path sequence consists of an optional list of
            hosts and the sender mailbox.  When the list of hosts is
            present, it is "reverse" source routing information and
            indicates that the mail was relayed through each host on the
            list (the first host in the list was the most recent relay).
            This list is used as source routing to return non-delivery
            notices to the sender.  As each relay host adds itself to
            the beginning of the list, it must use its name as known in
            the network to which it is relaying the mail rather than the
            network from which the mail came (if they are different).

            If the receiver-path sequence is present, it consists of an
            optional list of hosts and a destination mailbox.  When the
            list of hosts is present, it is source routing information
            and indicates that the mail must be relayed to the first
            host on the list.

            The receiver treats the lines following the command as mail
            text from the sender.  The mail text is terminated by the
            character sequence "<CRLF>.<CRLF>", (see Section 5.5.2 on
            Transparency).

            As mail is relayed along the receiver-path sequence, each
            relay host must remove itself from the path sequence and put
            itself at the beginning of the sender-path sequence.  When
            mail reaches its ultimate destination (the receiver-path



[Page 16]                                               Sluizer & Postel


                                                                        
RFC 780                                                         May 1981
                                                  Mail Transfer Protocol



            sequence has only a destination mailbox), the receiver-MTP
            inserts it into the destination mailbox in accordance with
            its host mail conventions.  (For example, "MAIL FROM:<X@Y>
            TO:<@A,@B,C@D> <CRLF>" will eventually be relayed as "MAIL
            FROM:<@A,X@Y> TO:<@B,C@D> <CRLF>.)

            If the receiver-path sequence is empty, the mail is destined
            for a printer or other designated place for host general
            delivery mail (if allowed at this host).  The mail may be
            marked as sent from the sender as specified in the
            sender-path sequence field.

         MAIL RECIPIENT SCHEME QUESTION (MRSQ)

            This MTP command is used to select a scheme for the
            transmission of mail to several users at the same host.  The
            schemes are recipients-first, or text-first.

         MAIL RECIPIENT (MRCP)

            This command is used to identify the individual recipients
            of the mail in the transmission of mail for multiple users
            at one host.

         HELP (HELP)

            This command causes the receiver to send helpful information
            regarding its implementation status over the transmission
            channel to the receiver.  The command may take an argument
            (e.g., any command name) and return more specific
            information as a response.

         QUIT (QUIT)

            This command specifies that the receiver must close the
            transmission channel.

         NOOP (NOOP)

            This command does not affect any parameters or previously
            entered commands.  It specifies no action other than that
            the receiver send an OK reply.







Sluizer & Postel                                               [Page 17]


                                                                        
May 1981                                                         RFC 780
Mail Transfer Protocol                                                  



         CONTINUE (CONT)

            This command specifies that the previously specified action
            is to be continued.  This is sent only following a
            preliminary reply.

         ABORT (ABRT)

            This command specifies that the previously specified action
            is to be aborted.  This is sent only following a preliminary
            reply.  It specifies no further action other than that the
            receiver send an OK reply.

      5.1.2.  COMMAND SYNTAX

         The commands begin with a command code followed by an argument
         field.  The command codes are four alphabetic characters.
         Upper and lower case alphabetic characters are to be treated
         identically.  Thus any of the following may represent the mail
         command:

            MAIL    Mail    mail    MaIl    mAIl

         This also applies to any symbols representing parameter values,
         such as R or r for RECIPIENT first.  The command codes and the
         argument fields are separated by one or more spaces.

         But, note that in the sender-path and receiver-path arguments
         case is important.  In particular, in some hosts the user "foo"
         is different from the user "Foo".

         The argument field consists of a variable length character
         string ending with the character sequence <CRLF>.  It should be
         noted that the receiver is to take no action until the end of
         the line is received.

         Square brackets denote an optional argument field.  If the
         option is not taken, the appropriate default is implied.  All
         characters are in the ASCII characters set.










[Page 18]                                               Sluizer & Postel


                                                                        
RFC 780                                                         May 1981
                                                  Mail Transfer Protocol



         The following are the MTP commands:

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

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

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

         HELP [<SP> <string>] <CRLF>

         QUIT <CRLF>

         NOOP <CRLF>

         CONT <CRLF>

         ABRT <CRLF>
































Sluizer & Postel                                               [Page 19]


                                                                        
May 1981                                                         RFC 780
Mail Transfer Protocol                                                  



         The syntax of the above argument fields (using BNF notation
         where applicable) is given below.  The "..." notation indicates
         that a field may be repeated one or more times.

            <sender-path> ::= <path>

            <receiver-path> ::= <path>