4.  Timeline of Events

   The following timeline shows when various events in the processing of
   a message and generation of MDNs take place:

   -- User composes message.

   -- User tells MUA to send message.

   -- MUA passes message to Mail Submission Agent (MSA) and original
      recipient information is passed along.

   -- MSA sends message to next MTA.

   -- Final MTA receives message.

   -- Final MTA delivers message to recipient's mailbox (possibly
      generating a Delivery Status Notification (DSN)).

   -- (Recipient's) MUA discovers a new message in recipient's mailbox
      and decides whether an MDN should be generated.  If the MUA has
      information that an MDN has already been generated for this
      message, no further MDN processing described below is performed.
      If MUA decides that no MDN can be generated, no further MDN
      processing described below is performed.

   -- MUA performs automatic processing and might generate corresponding
      MDNs ("dispatched", "processed", or "deleted" disposition type
      with "automatic-action" and "MDN-sent-automatically" disposition
      modes).  The MUA remembers that an MDN was generated.

   -- MUA displays list of messages to user.

   -- User selects a message and requests that some action be performed
      on it.

   -- MUA performs requested action; if an automatic MDN has not already
      been generated, with user's permission, sends an appropriate MDN
      ("displayed", "dispatched", "processed", or "deleted" disposition
      type, with "manual-action" and "MDN-sent-manually" or "MDN-sent-
      automatically" disposition mode).  The MUA remembers that an MDN
      was generated.

   -- User possibly performs other actions on message, but no further
      MDNs are generated.

5.  Conformance and Usage Requirements

   An MUA or gateway conforms to this specification if it generates MDNs
   according to the protocol defined in this memo.  It is not necessary
   to be able to generate all of the possible values of the Disposition
   field.

   MUAs and gateways MUST NOT generate the Original-Recipient field of
   an MDN unless the mail protocols provide the address originally
   specified by the sender at the time of submission.  Ordinary SMTP
   does not make that guarantee, but the SMTP extension defined in RFC--
   DSN-SMTP [RFC3461] permits such information to be carried in the
   envelope if it is available.  The Original-Recipient header field
   defined in this document provides a way for the MTA to pass the
   original recipient address to the MUA.

   Each sender-specified recipient address may result in more than one
   MDN.  If an MDN is requested for a recipient that is forwarded to
   multiple recipients of an "alias" (as defined in Section 6.2.7.3 of
   RFC-DSN-SMTP [RFC3461]), each of the recipients may issue an MDN.

   Successful distribution of a message to a mailing list exploder or
   gateway to Usenet newsgroup SHOULD be considered the final
   disposition of the message.  A mailing list exploder MAY issue an MDN
   with a disposition type of "processed" and disposition modes of
   "automatic-action" and "MDN-sent-automatically" indicating that the
   message has been forwarded to the list.  In this case, the request
   for MDNs is not propagated to the members of the list.

   Alternatively (if successful distribution of a message to a mailing
   list exploder / Usenet newsgroup is not considered the final
   disposition of the message), the mailing list exploder can issue no
   MDN and propagate the request for MDNs to all members of the list.
   The latter behavior is not recommended for any but small, closely
   knit lists, as it might cause large numbers of MDNs to be generated
   and may cause confidential subscribers to the list to be revealed.
   The mailing list exploder can also direct MDNs to itself, correlate
   them, and produce a report to the original sender of the message.

   This specification places no restrictions on the processing of MDNs
   received by user agents or mailing lists.

6.  Security Considerations

   The following security considerations apply when using MDNs.

6.1.  Forgery

   MDNs can be (and are, in practice) forged as easily as ordinary
   Internet electronic mail.  User agents and automatic mail handling
   facilities (such as mail distribution list exploders) that wish to
   make automatic use of MDNs should take appropriate precautions to
   minimize the potential damage from denial-of-service attacks.

   Security threats related to forged MDNs include the sending of:

   a.  A falsified disposition notification when the indicated
       disposition of the message has not actually occurred, and

   b.  Unsolicited MDNs.

   Similarly, a forged spam or phishing email message can contain
   Disposition-Notification-To header field that can trick the recipient
   to send an MDN.  MDN processing should only be invoked once
   authenticity of an email message is verified.

6.2.  Privacy

   Another dimension of security is privacy.  There may be cases in
   which a message recipient does not wish the disposition of messages
   addressed to him to be known, or is concerned that the sending of
   MDNs may reveal other sensitive information (e.g., when the message
   was read, using which email client, and which OS was used).  In this
   situation, it is acceptable for the MUA to silently ignore requests
   for MDNs.

   If the Disposition-Notification-To header field is passed on
   unmodified when a message is distributed to the subscribers of a
   mailing list, the subscribers to the list may be revealed to the
   sender of the original message by the generation of MDNs.

   Headers of the original message returned in part 3 of the multipart/
   report, as well as content of the message/disposition-notification
   part, could reveal confidential information about host names and/or
   network topology inside a firewall.

   Disposition mode (Section 3.2.6.1) can leak information about
   recipient's MUA configuration, in particular, whether MDNs are

   acknowledged manually or automatically.  If this is a concern, MUAs
   can return "manual-action/MDN-sent-manually" disposition mode in
   generated MDNs.

   In general, any optional MDN field may be omitted if the Reporting
   MUA site or user determines that inclusion of the field would impose
   too great a compromise of site confidentiality.  The need for such
   confidentiality must be balanced against the utility of the omitted
   information in MDNs.

   In some cases, someone with access to the message stream may use the
   MDN request mechanism to monitor the mail reading habits of a target.
   If the target is known to generate MDN reports, they could add a
   Disposition-Notification-To header field containing the envelope from
   address.  This risk can be minimized by not sending MDN's
   automatically.

6.2.1.  Disclosure of Product Information

   The "Reporting-UA" field (Section 3.2.1), User-Agent header field,
   and other header fields often reveal information about the respective
   sender's software systems.  In theory, this can make it easier for an
   attacker to exploit known security holes; in practice, attackers tend
   to try all potential holes regardless of the apparent software
   versions being used.  Also note that the "Reporting-UA" field doesn't
   provide any new information in comparison to the "User-Agent" and/or
   (undocumented) "X-Mailer" header fields used by many MUAs.

6.2.2.  MUA Fingerprinting

   The "Reporting-UA" field (Section 3.2.1) might contain enough
   information to uniquely identify a specific device, usually when
   combined with other characteristics, particularly if the user agent
   sends excessive details about the user's system or extensions.  Even
   when the guidance in Section 3.2.1 is followed to avoid
   fingerprinting, other sources of unique information may still be
   present, such as the Accept-Language header fields.

6.3.  Non-repudiation

   MDNs do not provide non-repudiation with proof of delivery.  Within
   the framework of today's Internet Mail, the MDNs defined in this
   document provide valuable information to the mail user; however, MDNs
   cannot be relied upon as a guarantee that a message was or was not
   seen by the recipient.  Even if MDNs are not actively forged, they
   may be lost in transit.  The recipient may bypass the MDN issuing
   mechanism in some manner.

   One possible solution for this purpose can be found in RFC-SEC-
   SERVICES [RFC2634].

6.4.  Mail Bombing

   The MDN request mechanism introduces an additional way of mail
   bombing a mailbox.  The MDN request notification provides an address
   to which MDN's should be sent.  It is possible for an attacking agent
   to send a potentially large set of messages to otherwise unsuspecting
   third party recipients with a false Disposition-Notification-To
   address.  Automatic or simplistic processing of such requests would
   result in a flood of MDN notifications to the target of the attack.
   Additionally, as generated MDN notifications can include the full
   content of messages that caused them and thus they can be bigger than
   such messages, they can be used for bandwidth amplification attacks.
   Such an attack could overrun the storage capacity of the targeted
   mailbox and/or of the mail transport system, and deny service.

   For that reason, MDN's SHOULD NOT be sent automatically where the
   Disposition-Notification-To address is different from the SMTP "MAIL
   FROM" address (which is carried in the Return-Path header field).
   See Section 2.1 for further discussion.

7.  Collected ABNF Grammar

   NOTE: The following lexical tokens are defined in RFC-MSGFMT
   [RFC5322]: CRLF, FWS, CFWS, field-name, mailbox-list, msg-id, text,
   comment, and word.  The following lexical tokens are defined in
   RFC-SMTP [RFC5321]: Atom.  (Note that RFC-MSGFMT [RFC5322] also
   defines "atom", but the version from RFC-SMTP [RFC5321] is more
   restrictive and this more restrictive version is used in this
   document.)  The "encoded-word" construct defined in RFC-MIME-HEADER
   [RFC2047] is allowed everywhere where RFC-MSGFMT [RFC5322] "comment"
   is used, for example, in CFWS.

    OWS = [CFWS]
          ; Optional whitespace.
          ; MDN generators SHOULD use "*WSP"
          ; (Typically a single space or nothing.
          ; It SHOULD be nothing at the end of a field.),
          ; unless an RFC 5322 "comment" is required.
          ;
          ; MDN parsers MUST parse it as "[CFWS]".

 Message header fields:
    mdn-request-header =
           "Disposition-Notification-To" ":" mailbox-list CRLF

    Disposition-Notification-Options =
           "Disposition-Notification-Options" ":" [FWS]
                     disposition-notification-parameter-list CRLF

    disposition-notification-parameter-list =
                     disposition-notification-parameter
                     *([FWS] ";" [FWS]
                     disposition-notification-parameter)

    disposition-notification-parameter = attribute [FWS] "=" [FWS]
                     importance [FWS] "," [FWS] value *([FWS] ","
                     [FWS] value)

    importance = "required" / "optional"

    attribute = Atom

    value = word

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

 Report content:
    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
           *( error-field CRLF )
           *( extension-field CRLF )

    address-type = Atom

    mta-name-type = Atom

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

    ua-name = *text-no-semi

    ua-product = *([FWS] text)

    text-no-semi = %d1-9 /        ; "text" characters excluding NUL, CR,
            %d11 / %d12 / %d14-58 / %d60-127      ; LF, or semi-colon

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

    mta-name = *text

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

    generic-address = *text

    final-recipient-field =
           "Final-Recipient" ":" OWS address-type OWS
           ";" OWS generic-address OWS

    original-message-id-field = "Original-Message-ID" ":" msg-id

    disposition-field =
           "Disposition" ":" OWS disposition-mode OWS ";"
           OWS disposition-type
           [ OWS "/" OWS disposition-modifier
           *( OWS "," OWS disposition-modifier ) ] OWS

    disposition-mode = action-mode OWS "/" OWS sending-mode

    action-mode = "manual-action" / "automatic-action"

    sending-mode = "MDN-sent-manually" / "MDN-sent-automatically"

    disposition-type = "displayed" / "deleted" / "dispatched" /
            "processed"

    disposition-modifier = "error" / disposition-modifier-extension

    disposition-modifier-extension = Atom

    error-field = "Error" ":" *([FWS] text)

    extension-field = extension-field-name ":" *([FWS] text)

    extension-field-name = field-name

8.  Guidelines for Gatewaying MDNs

   NOTE: This section provides non-binding recommendations for the
   construction of mail gateways that wish to provide semi-transparent
   disposition notifications between the Internet and another electronic
   mail system.  Specific MDN gateway requirements for a particular pair
   of mail systems may be defined by other documents.

8.1.  Gatewaying from Other Mail Systems to MDNs

   A mail gateway may issue an MDN to convey the contents of a "foreign"
   disposition notification over Internet Mail.  When there are
   appropriate mappings from the foreign notification elements to MDN
   fields, the information may be transmitted in those MDN fields.
   Additional information (such as what might be needed to tunnel the
   foreign notification through the Internet) may be defined in
   extension MDN fields.  (Such fields should be given names that
   identify the foreign mail protocol, e.g., X400-* for X.400 protocol
   elements [X.400]).

   The gateway must attempt to supply reasonable values for the
   Reporting-UA, Final-Recipient, and Disposition fields.  These will
   normally be obtained by translating the values from the foreign
   notification into their Internet-style equivalents.  However, some
   loss of information is to be expected.

   The sender-specified recipient address and the original message-id,
   if present in the foreign notification, should be preserved in the
   Original-Recipient and Original-Message-ID fields.

   The gateway should also attempt to preserve the "final" recipient
   address from the foreign system.  Whenever possible, foreign protocol
   elements should be encoded as meaningful printable ASCII strings.

   For MDNs produced from foreign disposition notifications, the name of
   the gateway MUST appear in the MDN-Gateway field of the MDN.

8.2.  Gatewaying from MDNs to Other Mail Systems

   It may be possible to gateway MDNs from the Internet into a foreign
   mail system.  The primary purpose of such gatewaying is to convey
   disposition information in a form that is usable by the destination
   system.  A secondary purpose is to allow "tunneling" of MDNs through
   foreign mail systems in case the MDN may be gatewayed back into the
   Internet.

   In general, the recipient of the MDN (i.e., the sender of the
   original message) will want to know, for each recipient: the closest
   available approximation to the original recipient address and the
   disposition (displayed, printed, etc.).

   If possible, the gateway should attempt to preserve the Original-
   Recipient address and Original-Message-ID (if present) in the
   resulting foreign disposition report.

   If it is possible to tunnel an MDN through the destination
   environment, the gateway specification may define a means of
   preserving the MDN information in the disposition reports used by
   that environment.

8.3.  Gatewaying of MDN-Requests to Other Mail Systems

   By use of the separate Disposition-Notification-To request header
   field, this specification offers a richer functionality than most, if
   not all, other email systems.  In most other email systems, the
   notification recipient is identical to the message sender as
   indicated in the "from" address.  There are two interesting cases
   when gatewaying into such systems:

   1.  If the address in the Disposition-Notification-To header field is
       identical to the address in the SMTP "MAIL FROM", the expected
       behavior will result, even if the Disposition-Notification-To
       information is lost.  Systems should propagate the MDN request.

   2.  If the address in the Disposition-Notification-To header field is
       different from the address in the SMTP "MAIL FROM", gatewaying
       into a foreign system without a separate notification address
       will result in unintended behavior.  This is especially important
       when the message arrives via a mailing list expansion software
       that may specifically replace the SMTP "MAIL FROM" address with
       an alternate address.  In such cases, the MDN request should not
       be gatewayed and should be silently dropped.  This is consistent
       with other forms of non-support for MDN.

9.  Example

   NOTE: This example is provided as illustration only and is not
   considered part of the MDN protocol specification.  If the example
   conflicts with the protocol definition above, the example is wrong.

   Likewise, the use of *-type subfield names or extension fields in
   this example is not to be construed as a definition for those type
   names or extension fields.

   This is an MDN issued after a message has been displayed to the user
   of an Internet Mail user agent.

   Date: Wed, 20 Sep 1995 00:19:00 (EDT) -0400
   From: Joe Recipient <Joe_Recipient@example.com>
   Message-Id: <199509200019.12345@example.com>
   Subject: Disposition notification
   To: Jane Sender <Jane_Sender@example.org>
   MIME-Version: 1.0
   Content-Type: multipart/report; report-type=disposition-notification;
      boundary="RAA14128.773615765/example.com"

   --RAA14128.773615765/example.com

   The message sent on 1995 Sep 19 at 13:30:00 (EDT) -0400 to Joe
   Recipient <Joe_Recipient@example.com> with subject "First draft of
   report" has been displayed.
   This is no guarantee that the message has been read or understood.

   --RAA14128.773615765/example.com
   Content-Type: message/disposition-notification

   Reporting-UA: joes-pc.cs.example.com; Foomail 97.1
   Original-Recipient: rfc822;Joe_Recipient@example.com
   Final-Recipient: rfc822;Joe_Recipient@example.com
   Original-Message-ID: <199509192301.23456@example.org>
   Disposition: manual-action/MDN-sent-manually; displayed

   --RAA14128.773615765/example.com
   Content-Type: message/rfc822

   [original message optionally goes here]

   --RAA14128.773615765/example.com--

10.  IANA Considerations

   IANA has completed the following actions:

   1.  IANA has updated the registration template for the message/
       disposition-notification media type to match what appears in
       Section 3.1 of this document and updated the reference for the
       media type to point to this document (instead of to RFC 3798).

   2.  The registries specified here already exist; this section updates
       their documentation.  IANA has changed the reference document for
       the three Message Disposition Notification Parameters registries
       to point to this document (instead of to RFC 3798).

   This document specifies three types of parameters that must be
   registered with the Internet Assigned Numbers Authority (IANA).  All
   of them use the "Specification Required" IANA registration policy
   [RFC5226].

   The forms below are for use when registering a new disposition-
   notification-parameter name for the Disposition-Notification-Options
   header field, a new disposition modifier name, or a new MDN extension
   field.  Each piece of information required by a registration form may
   be satisfied either by providing the information on the form itself
   or by including a reference to a published and publicly available
   specification that includes the necessary information.  IANA MAY
   reject registrations because of incomplete registration forms or
   incomplete specifications.

   To register, complete the following applicable form and send it via
   electronic mail to <IANA@IANA.ORG>.

10.1.  Disposition-Notification-Options Header Field
       disposition-notification-parameter Names

   A registration for a Disposition-Notification-Options header field
   disposition-notification-parameter name MUST include the following
   information:

   a.  The proposed disposition-notification-parameter name.

   b.  The syntax for disposition-notification-parameter values,
       specified using BNF, ABNF, regular expressions, or other
       non-ambiguous language.

   c.  If disposition-notification-parameter values 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 Disposition-Notification-Options header field.

   d.  A reference to a permanent and readily available public
       specification that describes the semantics of the disposition-
       notification-parameter values.

10.2.  Disposition Modifier Names

   A registration for a disposition-modifier name (used in the
   Disposition field of a message/disposition-notification) MUST include
   the following information:

   a.  The proposed disposition-modifier name.

   b.  A reference to a permanent and readily available public
       specification that describes the semantics of the disposition
       modifier.

10.3.  MDN Extension Field Names

   A registration for an MDN extension-field name MUST include the
   following information:

   a.  The proposed extension field name.

   b.  The syntax for extension values, specified using BNF, ABNF,
       regular expressions, or other non-ambiguous language.

   c.  If extension-field values 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
       Disposition-Notification-Options header field.

   d.  A reference to a permanent and readily available public
       specification that describes the semantics of the extension
       field.

11.  References

11.1.  Normative References

   [RFC5321]  Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
              DOI 10.17487/RFC5321, October 2008,
              <http://www.rfc-editor.org/info/rfc5321>.

   [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
              DOI 10.17487/RFC5322, October 2008,
              <http://www.rfc-editor.org/info/rfc5322>.

   [RFC2045]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part One: Format of Internet Message
              Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
              <http://www.rfc-editor.org/info/rfc2045>.

   [RFC2046]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part Two: Media Types", RFC 2046,
              DOI 10.17487/RFC2046, November 1996,
              <http://www.rfc-editor.org/info/rfc2046>.

   [RFC2047]  Moore, K., "MIME (Multipurpose Internet Mail Extensions)
              Part Three: Message Header Extensions for Non-ASCII Text",
              RFC 2047, DOI 10.17487/RFC2047, November 1996,
              <http://www.rfc-editor.org/info/rfc2047>.

   [RFC6522]  Kucherawy, M., Ed., "The Multipart/Report Media Type for
              the Reporting of Mail System Administrative Messages",
              STD 73, RFC 6522, DOI 10.17487/RFC6522, January 2012,
              <http://www.rfc-editor.org/info/rfc6522>.

   [RFC3461]  Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
              Extension for Delivery Status Notifications (DSNs)",
              RFC 3461, DOI 10.17487/RFC3461, January 2003,
              <http://www.rfc-editor.org/info/rfc3461>.

   [RFC3464]  Moore, K. and G. Vaudreuil, "An Extensible Message Format
              for Delivery Status Notifications", RFC 3464,
              DOI 10.17487/RFC3464, January 2003,
              <http://www.rfc-editor.org/info/rfc3464>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC3503]  Melnikov, A., "Message Disposition Notification (MDN)
              profile for Internet Message Access Protocol (IMAP)",
              RFC 3503, DOI 10.17487/RFC3503, March 2003,
              <http://www.rfc-editor.org/info/rfc3503>.

11.2.  Informative References

   [RFC2634]  Hoffman, P., Ed., "Enhanced Security Services for S/MIME",
              RFC 2634, DOI 10.17487/RFC2634, June 1999,
              <http://www.rfc-editor.org/info/rfc2634>.

   [RFC3249]  Cancio, V., Moldovan, M., Tamura, H., and D. Wing,
              "Implementers Guide for Facsimile Using Internet Mail",
              RFC 3249, DOI 10.17487/RFC3249, September 2002,
              <http://www.rfc-editor.org/info/rfc3249>.

   [RFC3501]  Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
              4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,
              <http://www.rfc-editor.org/info/rfc3501>.

   [RFC3801]  Vaudreuil, G. and G. Parsons, "Voice Profile for Internet
              Mail - version 2 (VPIMv2)", RFC 3801,
              DOI 10.17487/RFC3801, June 2004,
              <http://www.rfc-editor.org/info/rfc3801>.

   [RFC5233]  Murchison, K., "Sieve Email Filtering: Subaddress
              Extension", RFC 5233, DOI 10.17487/RFC5233, January 2008,
              <http://www.rfc-editor.org/info/rfc5233>.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              DOI 10.17487/RFC5226, May 2008,
              <http://www.rfc-editor.org/info/rfc5226>.

   [RFC5429]  Stone, A., Ed., "Sieve Email Filtering: Reject and
              Extended Reject Extensions", RFC 5429,
              DOI 10.17487/RFC5429, March 2009,
              <http://www.rfc-editor.org/info/rfc5429>.

   [RFC5598]  Crocker, D., "Internet Mail Architecture", RFC 5598,
              DOI 10.17487/RFC5598, July 2009,
              <http://www.rfc-editor.org/info/rfc5598>.

   [RFC6533]  Hansen, T., Ed., Newman, C., and A. Melnikov,
              "Internationalized Delivery Status and Disposition
              Notifications", RFC 6533, DOI 10.17487/RFC6533, February
              2012, <http://www.rfc-editor.org/info/rfc6533>.

   [X.400]    International Telecommunications Union, "Message handling
              system and service overview", ITU-T Recommendation
              F.400/X.400, June 1999.

Appendix A.  Changes from RFC 3798

   Changed IANA registration for different subregistries to
   "Specification Required" to match what is already used by IANA.

   Updated IANA registration template for message/disposition-
   notification.

   "X-" fields no longer reserved for experimental use and can now be
   registered in compliance with RFC 6648.

   Fixed the default MTA-name-type used in "MDN-Gateway" to be "dns".

   Strengthen requirements on obtaining user consent in order to protect
   user privacy.

   Removed discussion of using source routes with MDNs, as source route
   is a deprecated Email feature.

   The values of "dispatched" and "processed" were lost from the ABNF
   for "disposition-type".  (Erratum #691)

   Because the warning disposition modifier was previously removed, the
   warning-field has also been removed.  (Erratum #692)

   Because the failed disposition type was previously removed, the
   failure-field has also been removed.

   The ABNF for ua-name and ua-product included a semi-colon, which
   could not be distinguished from *text in the production.  The ua-name
   was restricted to not include semi-colon.  Semi-colon can still
   appear in the ua-product.

   Removed recommendation to include the MUA DNS host name in the
   "Reporting-UA" MDN field.

   The ABNF did not indicate all places that whitespace was allowable,
   in particular folding whitespace, although all implementations allow
   whitespace and folding in the header fields just like any other
   header field formatted as described in RFC-MSGFMT [RFC5322].  There
   were also a number of places in the ABNF that inconsistently
   permitted comments and whitespace in one leg of the production and
   not another.  The ABNF now specifies FWS and CFWS in several places
   that should have already been specified by the grammar.

   Extension-field was defined in the collected grammar but not in the
   main text.

   The comparison of mailboxes in Disposition-Notification-To to the
   Return-Path addr-spec was clarified.

   The use of the grammar production "parameter" was confusing with the
   RFC 2045 [RFC2045] production of the same name, as well as other uses
   of the same term.  These have been clarified.

   A clarification was added on the extent of the 7bit nature of MDNs.

   Uses of the terms "may" and "might" were clarified.

   A clarification was added on the order of the fields in the message/
   disposition-notification content.

Acknowledgements

   The contributions of Bruce Lilly, Alfred Hoenes, Barry Leiba, Ben
   Campbell, Pete Resnick, Donald Eastlake, and Alissa Cooper are
   gratefully acknowledged for this revision.

   The contributions of Roger Fajman and Greg Vaudreuil to earlier draft
   versions of this document are also gratefully acknowledged.

Authors' Addresses

   Tony Hansen (editor)
   AT&T Laboratories
   200 Laurel Ave. South
   Middletown, NJ  07748
   United States of America

   Email: tony@att.com


   Alexey Melnikov (editor)
   Isode Ltd
   14 Castle Mews
   Hampton, Middlesex  TW12 2NP
   United Kingdom

   Email: Alexey.Melnikov@isode.com