rfc1891.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

    however, in this case the MTA-name-type subfield MUST NOT be "dns".
    A MTA-name-type subfield value of "x-local-hostname" is suggested.

(c) Other per-message fields as defined in [5] MAY be supplied as
    appropriate.

(d) If the ORCPT parameter was provided for this recipient, the
    Original-Recipient field MUST be supplied, with its value taken from
    the ORCPT parameter.  If no ORCPT parameter was provided for this
    recipient, the Original-Recipient field MUST NOT appear.

(e) The Final-Recipient field MUST be supplied. It MUST contain the
    recipient address from the message envelope.  If the message was
    received via SMTP, the address-type will be "rfc822".

(f) The Action field MUST be supplied.





Moore                       Standards Track                    [Page 19]

RFC 1891           SMTP Delivery Status Notifications       January 1996


(g) The Status field MUST be supplied, using a status-code from [10].
    If there is no specific code which suitably describes a delivery
    failure, either 4.0.0 (temporary failure), or 5.0.0 (permanent
    failure) MUST be used.

(h) For DSNs resulting from attempts to relay a message to one or more
    recipients via SMTP, the Remote-MTA field MUST be supplied for each
    of those recipients.  The mta-name-type subfields of those Remote-
    MTA fields will be "dns".

(i) For DSNs resulting from attempts to relay a message to one or more
    recipients via SMTP, the Diagnostic-Code MUST be supplied for each
    of those recipients.  The diagnostic-type subfield will be "smtp".
    See section 9.2(a) of this document for a description of the "smtp"
    diagnostic-code.

(j) For DSNs resulting from attempts to relay a message to one or more
    recipients via SMTP, an SMTP-Remote-Recipient extension field MAY be
    supplied for each recipient, which contains the address of that
    recpient which was presented to the remote SMTP server.

(k) Other per-recipient fields defined in [5] MAY appear, as
    appropriate.

8. Acknowledgments

   The author wishes to thank Eric Allman, Harald Alvestrand, Jim
   Conklin, Bryan Costales, Peter Cowen, Dave Crocker, Roger Fajman, Ned
   Freed, Marko Kaittola, Steve Kille, John Klensin, Anastasios
   Kotsikonas, John Gardiner Myers, Julian Onions, Jacob Palme, Marshall
   Rose, Greg Vaudreuil, and Klaus Weide for their suggestions for
   improvement of this document.



















Moore                       Standards Track                    [Page 20]

RFC 1891           SMTP Delivery Status Notifications       January 1996


9. Appendix - Type-Name Definitions

   The following type names are defined for use in DSN fields generated
   by conforming SMTP-based MTAs:

9.1 "rfc822" address-type

   The "rfc822" address-type is to be used when reporting Internet
   electronic mail address in the Original-Recipient and Final-Recipient
   DSN fields.

(a) address-type name: rfc822

(b) syntax for mailbox addresses

    RFC822 mailbox addresses are generally expected to be of the form

    [route] addr-spec

    where "route" and "addr-spec" are defined in [2], and the "domain"
    portions of both "route" and "addr-spec" are fully-qualified domain
    names that are registered in the DNS.  However, an MTA MUST NOT
    modify an address obtained from the message envelope to force it to
    conform to syntax rules.

(c) If addresses of this type are not composed entirely of graphic
characters from the US-ASCII repertoire, a specification for how they
are to be encoded as graphic US-ASCII characters in a DSN Original-
Recipient or Final-Recipient DSN field.

    RFC822 addresses consist entirely of graphic characters from the US-
    ASCII repertoire, so no translation is necessary.

9.2 "smtp" diagnostic-type

   The "smtp" diagnostic-type is to be used when reporting SMTP reply-
   codes in Diagnostic-Code DSN fields.

(a) diagnostic-type name: SMTP

(b) A description of the syntax to be used for expressing diagnostic
codes of this type as graphic characters from the US-ASCII repertoire.

    An SMTP diagnostic-code is of the form

    *( 3*DIGIT "-" *text ) 3*DIGIT SPACE *text





Moore                       Standards Track                    [Page 21]

RFC 1891           SMTP Delivery Status Notifications       January 1996


    For a single-line SMTP reply to an SMTP command, the diagnostic-code
    SHOULD be an exact transcription of the reply.  For multi-line SMTP
    replies, it is necessary to insert a SPACE before each line after
    the first.  For example, an SMTP reply of:

    550-mailbox unavailable
    550 user has moved with no forwarding address

    could appear as follows in a Diagnostic-Code DSN field:

    Diagnostic-Code: smtp ; 550-mailbox unavailable
     550 user has moved with no forwarding address

(c) A list of valid diagnostic codes of this type and the meaning of
each code.

    SMTP reply-codes are currently defined in [1], [4], and [9].
    Additional codes may be defined by other RFCs.

9.3 "dns" MTA-name-type

   The "dns" MTA-name-type should be used in the Reporting-MTA field.
   An MTA-name of type "dns" is a fully-qualified domain name.  The name
   must be registered in the DNS, and the address Postmaster@{mta-name}
   must be valid.

(a) MTA-name-type name: dns

(b) A description of the syntax of MTA names of this type, using BNF,
regular expressions, ASN.1, or other non-ambiguous language.

    MTA names of type "dns" SHOULD be valid Internet domain names.  If
    such domain names are not available, a domain-literal containing the
    internet protocol address is acceptable.  Such domain names
    generally conform to the following syntax:

    domain = real-domain / domain-literal

    real-domain = sub-domain *("." sub-domain)

    sub-domain = atom

    domain-literal = "[" 1*3DIGIT 3("." 1*3DIGIT) "]"

    where "atom" and "DIGIT" are defined in [2].






Moore                       Standards Track                    [Page 22]

RFC 1891           SMTP Delivery Status Notifications       January 1996


(c) If MTA names of this type do not consist entirely of graphic
characters from the US-ASCII repertoire, a specification for how an MTA
name of this type should be expressed as a sequence of graphic US-ASCII
characters.

    MTA names of type "dns" consist entirely of graphic US-ASCII
    characters, so no translation is needed.

10. Appendix - Example

   This example traces the flow of a single message addressed to
   multiple recipients.  The message is sent by [e-mail] to
   [e-mail], [e-mail], [e-mail],
   [e-mail], [e-mail], and [e-mail], with a
   variety of per-recipient options.  The message is successfully
   delivered to Bob, Dana (via a gateway), Eric, and Fred.  Delivery
   fails for Carol and George.

   NOTE: Formatting rules for RFCs require that no line be longer than
   72 characters.  Therefore, in the following examples, some SMTP
   commands longer than 72 characters are printed on two lines, with the
   first line ending in "\".  In an actual SMTP transaction, such a
   command would be sent as a single line (i.e. with no embedded CRLFs),
   and without the "\" character that appears in these examples.

10.1 Submission

   Alice's user agent sends the message to the SMTP server at Pure-
   Heart.ORG.  Note that while this example uses SMTP as a mail
   submission protocol, other protocols could also be used.

<<< 220 Pure-Heart.ORG SMTP server here
>>> EHLO Pure-Heart.ORG
<<< 250-Pure-Heart.ORG
<<< 250-DSN
<<< 250-EXPN
<<< 250 SIZE
>>> MAIL FROM:<[e-mail]> RET=HDRS ENVID=QQ314159
<<< 250 <[e-mail]> sender ok
>>> RCPT TO:<[e-mail]> NOTIFY=SUCCESS \
    ORCPT=rfc822;[e-mail]
<<< 250 <[e-mail]> recipient ok
>>> RCPT TO:<[e-mail]> NOTIFY=FAILURE \
    ORCPT=rfc822;[e-mail]
<<< 250 <[e-mail]> recipient ok
>>> RCPT TO:<[e-mail]> NOTIFY=SUCCESS,FAILURE \
    ORCPT=rfc822;[e-mail]
<<< 250 <[e-mail]> recipient ok



Moore                       Standards Track                    [Page 23]

RFC 1891           SMTP Delivery Status Notifications       January 1996


>>> RCPT TO:<[e-mail]> NOTIFY=FAILURE \
    ORCPT=rfc822;[e-mail]
<<< 250 <[e-mail]> recipient ok
>>> RCPT TO:<[e-mail]> NOTIFY=NEVER
<<< 250 <[e-mail]> recipient ok
>>> RCPT TO:<[e-mail]> NOTIFY=FAILURE \
    ORCPT=rfc822;[e-mail]
<<< 250 <[e-mail]> recipient ok
>>> DATA
<<< 354 okay, send message
>>> (message goes here)
>>> .
<<< 250 message accepted
>>> QUIT
<<< 221 goodbye

10.2 Relay to Big-Bucks.COM

   The SMTP at Pure-Heart.ORG then relays the message to Big-Bucks.COM.
   (For the purpose of this example, mail.Big-Bucks.COM is the primary
   mail exchanger for Big-Bucks.COM).

<<< 220 mail.Big-Bucks.COM says hello
>>> EHLO Pure-Heart.ORG
<<< 250-mail.Big-Bucks.COM
<<< 250 DSN
>>> MAIL FROM:<[e-mail]> RET=HDRS ENVID=QQ314159
<<< 250 sender okay
>>> RCPT TO:<[e-mail]> NOTIFY=SUCCESS \
    ORCPT=rfc822;[e-mail]
<<< 250 recipient okay
>>> DATA
<<< 354 send message
>>> (message goes here)
>>> .
<<< 250 message received
>>> QUIT
<<< 221 bcnu

10.3 Relay to Ivory.EDU

   The SMTP at Pure-Heart.ORG relays the message to Ivory.EDU, which (as
   it happens) is a gateway to a LAN-based mail system that accepts SMTP
   mail and supports the DSN extension.

<<< 220 Ivory.EDU gateway to FooMail(tm) here
>>> EHLO Pure-Heart.ORG
<<< 250-Ivory.EDU



Moore                       Standards Track                    [Page 24]

RFC 1891           SMTP Delivery Status Notifications       January 1996


<<< 250 DSN
>>> MAIL FROM:<[e-mail]> RET=HDRS ENVID=QQ314159
<<< 250 ok
>>> RCPT TO:<[e-mail]> NOTIFY=FAILURE \
    ORCPT=rfc822;[e-mail]
<<< 550 error - no such recipient
>>> RCPT TO:<[e-mail]> NOTIFY=SUCCESS,FAILURE \
    ORCPT=rfc822;[e-mail]
<<< 250 recipient ok
>>> DATA
<<< 354 send message, end with '.'
>>> (message goes here)
>>> .
<<< 250 message received
>>> QUIT
<<< 221 bye

   Note that since the Ivory.EDU refused to accept mail for
   [e-mail], and the sender specified NOTIFY=FAILURE, the
   sender-SMTP (in this case Pure-Heart.ORG) must generate a DSN.

10.4 Relay to Bombs.AF.MIL

   The SMTP at Pure-Heart.ORG relays the message to Bombs.AF.MIL, which
   does not support the SMTP extension.  Because the sender specified
   NOTIFY=NEVER for recipient [e-mail], the SMTP at Pure-
   Heart.ORG chooses to send the message for that recipient in a
   separate transaction with a reverse-path of <>.

<<< 220-Bombs.AF.MIL reporting for duty.
<<< 220 Electronic mail is to be used for official business only.
>>> EHLO Pure-Heart.ORG
<<< 502 command not implemented
>>> RSET
<<< 250 reset
>>> HELO Pure-Heart.ORG
<<< 250 Bombs.AF.MIL
>>> MAIL FROM:<[e-mail]>
<<< 250 ok
>>> RCPT TO:<[e-mail]>
<<< 250 ok
>>> DATA