rfc2298.txt

来自「著名的RFC文档,其中有一些文档是已经翻译成中文的的.」· 文本 代码 · 共 1,572 行 · 第 1/5 页

   disposition type to be sent, user consent SHOULD also be obtained
   before sending an MDN with a disposition type of "failed".

2.3 The Original-Recipient Header

   Since electronic mail addresses may be rewritten while the message is
   in transit, it is useful for the original recipient address to be
   made available by the delivering MTA.  The delivering MTA may be able
   to obtain this information from the ORCPT parameter of the SMTP RCPT
   TO command, as defined in RFC 1891 [8].  If this information is
   available, the delivering MTA SHOULD insert an Original-Recipient
   header at the beginning of the message (along with the Return-Path
   header).  The delivering MTA MAY delete any other Original-Recipient
   headers that occur in the message.  The syntax of this header, using
   the ABNF of RFC 822 [2], is as follows

     original-recipient-header =
          "Original-Recipient" ":" address-type ";" generic-address




Fajman                      Standards Track                     [Page 6]

RFC 2298           Message Disposition Notifications          March 1998


   The address-type and generic-address token are as as specified in the
   description of the Original-Recipient field in section 3.2.3.

   The purpose of carrying the original recipient information and
   returning it in the MDN is to permit automatic correlation of MDNs
   with the original message on a per-recipient basis.

2.4 Use with the Message/Partial Content Type

   The use of the headers Disposition-Notification-To, Disposition-
   Notification-Options, and Original-Recipient with the MIME
   Message/partial content type (RFC 2046 [5]) requires further
   definition.

   When a message is segmented into two or more message/partial
   fragments, the three headers mentioned in the above paragraph SHOULD
   be placed in the "inner" or "enclosed" message (using the terms of
   RFC 2046 [5]).  These headers SHOULD NOT be used in the headers of
   any of the fragments themselves.

   When the multiple message/partial fragments are reassembled, the
   following applies.  If these headers occur along with the other
   headers of a message/partial fragment message, they pertain to an MDN
   to be generated for the fragment.  If these headers occur in the
   headers of the "inner" or "enclosed" message (using the terms of RFC
   2046 [5]), they pertain to an MDN to be generated for the reassembled
   message.  Section 5.2.2.1 of RFC 2046 [5]) is amended to specify
   that, in addition to the headers specified there, the three headers
   described in this specification are to be appended, in order, to the
   headers of the reassembled message.  Any occurances of the three
   headers defined here in the headers of the initial enclosing message
   must not be copied to the reassembled message.

3.  Format of a Message Disposition Notification

   A message disposition notification is a MIME message with a top-
   level content-type of multipart/report (defined in RFC 1892 [7]).
   When a multipart/report content is used to transmit an MDN:

   (a)  The report-type parameter of the multipart/report content is
        "disposition-notification".

   (b)  The first component of the multipart/report contains a human-
        readable explanation of the MDN, as described in RFC 1892 [7].

   (c)  The second component of the multipart/report is of content-type
        message/disposition-notification, described in section 3.1 of
        this document.



Fajman                      Standards Track                     [Page 7]

RFC 2298           Message Disposition Notifications          March 1998


   (d)  If the original message or a portion of the message is to be
        returned to the sender, it appears as the third component of the
        multipart/report.  The decision of whether or not to return the
        message or part of the message is up to the UA generating the
        MDN.  However, in the case of encrypted messages requesting
        MDNs, encrypted message text MUST be returned, if it is returned
        at all, only in its original encrypted form.

        NOTE:  For message dispostion notifications gatewayed from
        foreign systems, the headers of the original message may not be
        available.  In this case the third component of the MDN 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 and date fields from the
        original message.

   The MDN MUST be addressed (in both the message header and the
   transport envelope) to the address(es) from the Disposition-
   Notification-To header from the original message for which the MDN is
   being generated.

   The From field of the message header of the MDN MUST contain the
   address of the person for whom the message disposition notification
   is being issued.

   The envelope sender address (i.e., SMTP MAIL FROM) of the MDN MUST be
   null (<>), specifying that no Delivery Status Notification messages
   or other messages indicating successful or unsuccessful delivery are
   to be sent in response to an MDN.

   A message disposition notification MUST NOT itself request an MDN.
   That is, it MUST NOT contain a Disposition-Notification-To header.

   The Message-ID header (if present) for an MDN MUST be different from
   the Message-ID of the message for which the MDN is being issued.

   A particular MDN describes the disposition of exactly one message for
   exactly one recipient.  Multiple MDNs may be generated as a result of
   one message submission, one per recipient.  However, due to the
   circumstances described in Section 2.1, MDNs may not be generated for
   some recipients for which MDNs were requested.

3.1 The message/disposition-notification content-type

   The message/disposition-notification content-type is defined as
   follows:

     MIME type name:                message



Fajman                      Standards Track                     [Page 8]

RFC 2298           Message Disposition Notifications          March 1998


     MIME subtype name:             disposition-notification
     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 6 of this memo.

   The message/disposition-notification report type for use in the
   multipart/report is "disposition-notification".

   The body of a message/disposition-notification consists of one or
   more "fields" formatted according to the ABNF of RFC 822 header
   "fields" (see [2]).  Using the ABNF of RFC 822, the syntax of the
   message/disposition-notification content is as follows:

     disposition-notification-content = [ reporting-ua-field CRLF ]
          [ mdn-gateway-field CRLF ]
          [ original-recipient-field CRLF ]
          final-recipient-field CRLF
          [ original-message-id-field CRLF ]
          disposition-field CRLF
          *( failure-field CRLF )
          *( error-field CRLF )
          *( warning-field CRLF )
          *( extension-field CRLF )

3.1.1 General conventions for fields

   Since these fields are defined according to the rules of RFC 822 [2],
   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 notification fields may
   use the "encoded-word" construct defined in RFC 2047 [6].

3.1.2 "*-type" subfields

   Several fields consist of a "-type" subfield, followed by a semi-
   colon, followed by "*text".  For these fields, the keyword used in
   the address-type or MTA-type subfield indicates the expected format
   of the address or MTA-name that follows.

   The "-type" subfields are defined as follows:




Fajman                      Standards Track                     [Page 9]

RFC 2298           Message Disposition Notifications          March 1998


   (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)  An "MTA-name-type" specifies the format of a mail transfer
        agent 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 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-type and mta-name-type values, along with
   descriptions of the meanings of each, or a reference to a one or more
   specifications that provide such descriptions.  (The "rfc822"
   address-type is defined in RFC 1891 [8].) Registration forms for
   address-type and mta-name-type appear in RFC 1894 [9].

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

3.1.3 Lexical tokens imported from RFC 822

   The following lexical tokens, defined in RFC 822 [2], are used in the
   ABNF grammar for MDNs:  atom, CRLF, mailbox, msg-id, text.

3.2 Message/disposition-notification Fields

3.2.1 The Reporting-UA field

     reporting-ua-field = "Reporting-UA" ":" ua-name
                          [ ";" ua-product ]

     ua-name = *text

     ua-product = *text

   The Reporting-UA field is defined as follows:

   A MDN describes the disposition of a message after it has been
   delivered to a recipient.  In all cases, the Reporting-UA is the UA
   that performed the disposition described in the MDN.  This field is



Fajman                      Standards Track                    [Page 10]

RFC 2298           Message Disposition Notifications          March 1998


   optional, but recommended.  For Internet Mail user agents, it is
   recommended that this field contain both the DNS name of the
   particular instance of the UA that generated the MDN and the name of
   the product.  For example,

     Reporting-UA:  rogers-mac.dcrt.nih.gov; Foomail 97.1

   If the reporting UA consists of more than one component (e.g., a base
   program and plug-ins), this may be indicated by including a list of
   product names.

3.2.2 The MDN-Gateway field

   The MDN-Gateway field indicates the name of the gateway or MTA that
   translated a foreign (non-Internet) message disposition notification
   into this MDN.  This field MUST appear in any MDN which was
   translated by a gateway from a foreign system into MDN format, and
   MUST NOT appear otherwise.

        mdn-gateway-field = "MDN-Gateway" ":" mta-name-type ";" mta-name

        mta-name = *text

   For gateways into Internet Mail, the MTA-name-type will normally be
   "smtp", and the mta-name will be the Internet domain name of the
   gateway.

3.2.3 Original-Recipient field

   The Original-Recipient field indicates the original recipient address
   as specified by the sender of the message for which the MDN is being
   issued.  For Internet Mail messages the value of the

   Original-Recipient field is obtained from the Original-Recipient
   header from the message for which the MDN is being generated.  If
   there is no Original-Recipient header in the message, then the
   Original-Recipient field MUST be omitted, unless the same information
   is reliably available some other way.  If there is an Original-
   Recipient header in the original message (or original recipient
   information is reliably available some other way), then the
   Original-Recipient field must be supplied.  If there is more than one
   Original-Recipient header in the message, the UA may choose the one
   to use or act as if no Original-Recipient header is present.

     original-recipient-field =
          "Original-Recipient" ":" address-type ";" generic-address

     generic-address = *text



Fajman                      Standards Track                    [Page 11]

RFC 2298           Message Disposition Notifications          March 1998


   The address-type field indicates the type of the original recipient
   address.  If the message originated within the Internet, the
   address-type field field will normally be "rfc822", and the address
   will be according to the syntax specified in RFC 822 [2].  The value
   "unknown" should be used if the Reporting UA cannot determine the
   type of the original recipient address from the message envelope.
   This address is the same as that provided by the sender and can be
   used to automatically correlate MDN reports with original messages on