rfc1894.txt

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

RFC 1894             Delivery Status Notifications          January 1996


    NOTE: For delivery status notifications gatewayed from foreign
    systems, the headers of the original message may not be available.
    In this case the third component of the DSN may be omitted, or it
    may contain "simulated" RFC 822 headers which contain equivalent
    information.  In particular, it is very desirable to preserve the
    subject, date, and message-id (or equivalent) fields from the
    original message.

   The DSN MUST be addressed (in both the message header and the
   transport envelope) to the return address from the transport envelope
   which accompanied the original message for which the DSN was
   generated.  (For a message that arrived via SMTP, the envelope return
   address appears in the MAIL FROM command.)

   The From field of the message header of the DSN SHOULD contain the
   address of a human who is responsible for maintaining the mail system
   at the Reporting MTA site (e.g.  Postmaster), so that a reply to the
   DSN will reach that person.  Exception: if a DSN is translated from a
   foreign delivery report, and the gateway performing the translation
   cannot determine the appropriate address, the From field of the DSN
   MAY be the address of a human who is responsible for maintaining the
   gateway.

   The envelope sender address of the DSN SHOULD be chosen to ensure
   that no delivery status reports will be issued in response to the DSN
   itself, and MUST be chosen so that DSNs will not generate mail loops.
   Whenever an SMTP transaction is used to send a DSN, the MAIL FROM
   command MUST use a NULL return address, i.e. "MAIL FROM:<>".

   A particular DSN describes the delivery status for exactly one
   message.  However, an MTA MAY report on the delivery status for
   several recipients of the same message in a single DSN.  Due to the
   nature of the mail transport system (where responsibility for
   delivery of a message to its recipients may be split among several
   MTAs, and delivery to any particular recipient may be delayed),
   multiple DSNs may be still be issued in response to a single message
   submission.














Moore & Vaudreuil           Standards Track                     [Page 7]

RFC 1894             Delivery Status Notifications          January 1996


2.1 The message/delivery-status content-type

   The message/delivery-status content-type is defined as follows:

     MIME type name:                message
     MIME subtype name:             delivery-status
     Optional parameters:           none
     Encoding considerations:       "7bit" encoding is sufficient and
                                    MUST be used to maintain readability
                                    when viewed by non-MIME mail
                                    readers.
     Security considerations:       discussed in section 4 of this memo.

   The message/delivery-status report type for use in the
   multipart/report is "delivery-status".

   The body of a message/delivery-status consists of one or more
   "fields" formatted according to the ABNF of RFC 822 header "fields"
   (see [6]).  The per-message fields appear first, followed by a blank
   line.  Following the per-message fields are one or more groups of
   per-recipient fields.  Each group of per-recipient fields is preceded
   by a blank line.  Using the ABNF of RFC 822, the syntax of the
   message/delivery-status content is as follows:

     delivery-status-content =
          per-message-fields 1*( CRLF per-recipient-fields )

   The per-message fields are described in section 2.2.  The per-
   recipient fields are described in section 2.3.


2.1.1 General conventions for DSN fields

   Since these fields are defined according to the rules of RFC 822, the
   same conventions for continuation lines and comments apply.
   Notification fields may be continued onto multiple lines by beginning
   each additional line with a SPACE or HTAB.  Text which appears in
   parentheses is considered a comment and not part of the contents of
   that notification field.  Field names are case-insensitive, so the
   names of notification fields may be spelled in any combination of
   upper and lower case letters.  Comments in DSN fields may use the
   "encoded-word" construct defined in [7].

   A number of DSN fields are defined to have a portion of a field body
   of "xtext".  "xtext" is used to allow encoding sequences of octets
   which contain values outside the range [1-127 decimal] of traditional
   ASCII characters, and also to allow comments to be inserted in the
   data.  Any octet may be encoded as "+" followed by two upper case



Moore & Vaudreuil           Standards Track                     [Page 8]

RFC 1894             Delivery Status Notifications          January 1996


   hexadecimal digits.  (The "+" character MUST be encoded as "+2B".)
   With certain exceptions, octets that correspond to ASCII characters
   may be represented as themselves.  SPACE and HTAB characters are
   ignored.  Comments may be included by enclosing them in parenthesis.
   Except within comments, encoded-words such as defined in [7] may NOT
   be used in xtext.

   "xtext" is formally defined as follows:

     xtext = *( xchar / hexchar / linear-white-space / comment )

     xchar = any ASCII CHAR between "!" (33) and "~" (126) inclusive,
          except for "+", "\" and "(".

   "hexchar"s are intended to encode octets that cannot be represented
   as plain text, either because they are reserved, or because they are
   non-printable.  However, any octet value may be represented by a
   "hexchar".

     hexchar = ASCII "+" immediately followed by two upper case
          hexadecimal digits

   When encoding an octet sequence as xtext:

   + Any ASCII CHAR between "!" and "~" inclusive, except for "+", "\",
     and "(", MAY be encoded as itself.  (Some CHARs in this range may
     also be encoded as "hexchar"s, at the implementor's discretion.)

   + ASCII CHARs that fall outside the range above must be encoded as
     "hexchar".

   + Line breaks (CR LF SPACE) MAY be inserted as necessary to keep line
     lengths from becoming excessive.

   + Comments MAY be added to clarify the meaning for human readers.

2.1.2 "*-type" subfields

   Several DSN fields consist of a "-type" subfield, followed by a
   semicolon, followed by "*text".  For these fields, the keyword used
   in the address-type, diagnostic-type, or MTA-name-type subfield
   indicates the expected format of the address, status-code, or MTA-
   name which follows.








Moore & Vaudreuil           Standards Track                     [Page 9]

RFC 1894             Delivery Status Notifications          January 1996


   The "-type" subfields are defined as follows:

(a) An "address-type" specifies the format of a mailbox address.  For
    example, Internet mail addresses use the "rfc822" address-type.

         address-type = atom

(b) A "diagnostic-type" specifies the format of a status code.  For
    example, when a DSN field contains a reply code reported via the
    Simple Mail Transfer Protocol [3], the "smtp" diagnostic-type is
    used.

         diagnostic-type = atom

(c) An "MTA-name-type" specifies the format of an MTA name.  For
    example, for an SMTP server on an Internet host, the MTA name is the
    domain name of that host, and the "dns" MTA-name-type is used.

         mta-name-type = atom

   Values for address-type, diagnostic-type, and MTA-name-type are
   case-insensitive.  Thus address-type values of "RFC822" and "rfc822"
   are equivalent.

   The Internet Assigned Numbers Authority (IANA) will maintain a
   registry of address-types, diagnostic-types, and MTA-name-types,
   along with descriptions of the meanings and acceptable values of
   each, or a reference to a one or more specifications that provide
   such descriptions.  (The "rfc822" address-type, "smtp" diagnostic-
   type, and "dns" MTA-name-type are defined in [4].)  Registration
   forms for address-type, diagnostic-type, and MTA-name-type appear in
   section 8 of this document.

   IANA will not accept registrations for any address-type, diagnostic-
   type, or MTA-name-type name that begins with "X-".  These type names
   are reserved for experimental use.

2.1.3 Lexical tokens imported from RFC 822

   The following lexical tokens, defined in [6], are used in the ABNF
   grammar for DSNs: atom, CHAR, comment, CR, CRLF, DIGIT, LF, linear-
   white-space, SPACE, text.  The date-time lexical token is defined in
   [8].








Moore & Vaudreuil           Standards Track                    [Page 10]

RFC 1894             Delivery Status Notifications          January 1996


2.2 Per-Message DSN Fields

   Some fields of a DSN apply to all of the delivery attempts described
   by that DSN.  These fields may appear at most once in any DSN.  These
   fields are used to correlate the DSN with the original message
   transaction and to provide additional information which may be useful
   to gateways.

     per-message-fields =
          [ original-envelope-id-field CRLF ]
          reporting-mta-field CRLF
          [ dsn-gateway-field CRLF ]
          [ received-from-mta-field CRLF ]
          [ arrival-date-field CRLF ]
          *( extension-field CRLF )

2.2.1 The Original-Envelope-Id field

   The optional Original-Envelope-Id field contains an "envelope
   identifier" which uniquely identifies the transaction during which
   the message was submitted, and was either (a) specified by the sender
   and supplied to the sender's MTA, or (b) generated by the sender's
   MTA and made available to the sender when the message was submitted.
   Its purpose is to allow the sender (or her user agent) to associate
   the returned DSN with the specific transaction in which the message
   was sent.

   If such an envelope identifier was present in the envelope which
   accompanied the message when it arrived at the Reporting MTA, it
   SHOULD be supplied in the Original-Envelope-Id field of any DSNs
   issued as a result of an attempt to deliver the message.  Except when
   a DSN is issued by the sender's MTA, an MTA MUST NOT supply this
   field unless there is an envelope-identifier field in the envelope
   which accompanied this message on its arrival at the Reporting MTA.

   The Original-Envelope-Id field is defined as follows:

     original-envelope-id-field =
          "Original-Envelope-Id" ":" envelope-id

     envelope-id = *text

   There may be at most one Original-Envelope-Id field per DSN.

   The envelope-id is CASE-SENSITIVE.  The DSN MUST preserve the
   original case and spelling of the envelope-id.





Moore & Vaudreuil           Standards Track                    [Page 11]

RFC 1894             Delivery Status Notifications          January 1996


   NOTE: The Original-Envelope-Id is NOT the same as the Message-Id from
   the message header.  The Message-Id identifies the content of the
   message, while the Original-Envelope-Id identifies the transaction in
   which the message is sent.

2.2.2 The Reporting-MTA DSN field

     reporting-mta-field =
          "Reporting-MTA" ":" mta-name-type ";" mta-name

     mta-name = *text

   The Reporting-MTA field is defined as follows:

   A DSN describes the results of attempts to deliver, relay, or gateway
   a message to one or more recipients.  In all cases, the Reporting-MTA
   is the MTA which attempted to perform the delivery, relay, or gateway
   operation described in the DSN.  This field is required.

   Note that if an SMTP client attempts to relay a message to an SMTP
   server and receives an error reply to a RCPT command, the client is
   responsible for generating the DSN, and the client's domain name will
   appear in the Reporting-MTA field.  (The server's domain name will
   appear in the Remote-MTA field.)

   Note that the Reporting-MTA is not necessarily the MTA which actually
   issued the DSN.  For example, if an attempt to deliver a message
   outside of the Internet resulted in a nondelivery notification which
   was gatewayed back into Internet mail, the Reporting-MTA field of the
   resulting DSN would be that of the MTA that originally reported the
   delivery failure, not that of the gateway which converted the foreign
   notification into a DSN.  See Figure 2.



















Moore & Vaudreuil           Standards Track                    [Page 12]

RFC 1894             Delivery Status Notifications          January 1996