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
-- 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
-- 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
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 184.108.40.206 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.
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.
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
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 220.127.116.11) 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
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
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.
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-
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:
"Disposition-Notification-To" ":" mailbox-list CRLF
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
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
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
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.
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>
Subject: Disposition notification
To: Jane Sender <Jane_Sender@example.org>
Content-Type: multipart/report; report-type=disposition-notification;
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.
Reporting-UA: joes-pc.cs.example.com; Foomail 97.1
Disposition: manual-action/MDN-sent-manually; displayed
[original message optionally goes here]
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
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
To register, complete the following applicable form and send it via
electronic mail to <IANA@IANA.ORG>.
10.1. Disposition-Notification-Options Header Field
A registration for a Disposition-Notification-Options header field
disposition-notification-parameter name MUST include the following
a. The proposed disposition-notification-parameter name.
b. The syntax for disposition-notification-parameter values,
specified using BNF, ABNF, regular expressions, or other
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-
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
10.3. MDN Extension Field Names
A registration for an MDN extension-field name MUST include the
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
11.1. Normative References
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
DOI 10.17487/RFC5321, October 2008,
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
DOI 10.17487/RFC5322, October 2008,
[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,
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-
"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
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
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/
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.
Tony Hansen (editor)
200 Laurel Ave. South
Middletown, NJ 07748
United States of America
Alexey Melnikov (editor)
14 Castle Mews
Hampton, Middlesex TW12 2NP