Request for Comments: 3798 AT&T Laboratories
Obsoletes: 2298 G. Vaudreuil, Ed.
Updates: 3461, 2046 Lucent Technologies
Category: Standards Track May 2004
Message Disposition Notification
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This memo defines a MIME content-type that may be used by a mail user
agent (MUA) or electronic mail gateway to report the disposition of a
message after it has been successfully delivered to a recipient.
This content-type is intended to be machine-processable. Additional
message headers are also defined to permit Message Disposition
Notifications (MDNs) to be requested by the sender of a message. The
purpose is to extend Internet Mail to support functionality often
found in other messaging systems, such as X.400 and the proprietary
"LAN-based" systems, and often referred to as "read receipts,"
"acknowledgements", or "receipt notifications." The intention is to
do this while respecting privacy concerns, which have often been
expressed when such functions have been discussed in the past.
Because many messages are sent between the Internet and other
messaging systems (such as X.400 or the proprietary "LAN-based"
systems), the MDN protocol is designed to be useful in a multi-
protocol messaging environment. To this end, the protocol described
in this memo provides for the carriage of "foreign" addresses, in
addition to those normally used in Internet Mail. Additional
attributes may also be defined to support "tunneling" of foreign
notifications through Internet Mail.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Purposes . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Terminology. . . . . . . . . . . . . . . . . . . . . . . 4
2. Requesting Message Disposition Notifications . . . . . . . . . 4
2.1. The Disposition-Notification-To Header . . . . . . . . . 4
2.2. The Disposition-Notification-Options Header. . . . . . . 6
2.3. The Original-Recipient Header. . . . . . . . . . . . . . 7
2.4. Use with the Message/Partial Content Type. . . . . . . . 8
3. FORMAT OF A MESSAGE DISPOSITION NOTIFICATION . . . . . . . . . 8
3.1. The message/disposition-notification content-type. . . . 9
3.2. Message/disposition-notification Fields. . . . . . . . . 11
3.3. Extension-fields . . . . . . . . . . . . . . . . . . . . 16
4. Timeline of Events . . . . . . . . . . . . . . . . . . . . . . 17
5. Conformance and Usage Requirements . . . . . . . . . . . . . . 18
6. Security Considerations. . . . . . . . . . . . . . . . . . . . 19
6.1. Forgery. . . . . . . . . . . . . . . . . . . . . . . . . 19
6.2. Privacy. . . . . . . . . . . . . . . . . . . . . . . . . 19
6.3. Non-Repudiation. . . . . . . . . . . . . . . . . . . . . 20
6.4. Mail Bombing . . . . . . . . . . . . . . . . . . . . . . 20
7. Collected Grammar. . . . . . . . . . . . . . . . . . . . . . . 20
8. Guidelines for Gatewaying MDNS . . . . . . . . . . . . . . . . 22
8.1. Gatewaying from other mail systems to MDNs . . . . . . . 23
8.2. Gatewaying from MDNs to other mail systems . . . . . . . 23
8.3. Gatewaying of MDN-requests to other mail systems . . . . 24
9. Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
10. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 25
10.1. Disposition-Notification-Options header parameter names. 26
10.2. Disposition modifier names . . . . . . . . . . . . . . . 26
10.3. MDN extension field names. . . . . . . . . . . . . . . . 26
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
12.1. Normative References . . . . . . . . . . . . . . . . . . 27
12.2. Informative References . . . . . . . . . . . . . . . . . 28
Appendix A - Changes from RFC 2298 . . . . . . . . . . . . . . . . 29
Authors’ Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction
This memo defines a [RFC-MIME-MEDIA] content-type for message
disposition notifications (MDNs). An MDN can be used to notify the
sender of a message of any of several conditions that may occur after
successful delivery, such as display of the message contents,
printing of the message, deletion (without display) of the message,
or the recipient’s refusal to provide MDNs. The
"message/disposition-notification" content-type defined herein is
intended for use within the framework of the "multipart/report"
content type defined in [RFC-REPORT].
This memo defines the format of the notifications and the [RFC-
MSGFMT] headers used to request them.
1.1. Purposes
The MDNs defined in this memo are expected to serve several purposes:
(a) Inform human beings of the disposition of messages after
successful delivery, in a manner that is largely independent of
human language;
(b) Allow mail user agents to keep track of the disposition of
messages sent, by associating returned MDNs with earlier message
transmissions;
(c) Convey disposition notification requests and disposition
notifications between Internet Mail and "foreign" mail systems
via a gateway;
(d) Allow "foreign" notifications to be tunneled through a MIME-
capable message system and back into the original messaging
system that issued the original notification, or even to a third
messaging system;
(e) Allow language-independent, yet reasonably precise, indications
of the disposition of a message to be delivered.
1.2. Requirements
These purposes place the following constraints on the notification
protocol:
(a) It must be readable by humans, and must be machine-parsable.
(b) It must provide enough information to allow message senders (or
their user agents) to unambiguously associate an MDN with the
message that was sent and the original recipient address for
which the MDN was issued (if such information is available),
even if the message was forwarded to another recipient address.
(c) It must also be able to describe the disposition of a message
independent of any particular human language or of the
terminology of any particular mail system.
(d) The specification must be extensible in order to accommodate
future requirements.
1.3. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC-KEYWORDS].
All syntax descriptions use the ABNF specified by [RFC-MSGFMT], in
which the lexical tokens (used below) are defined: "atom", "CRLF",
"mailbox", "msg-id", and "text". The following lexical tokens are
defined in the definition of the Content-Type header in [RFC-MIME-
BODY]: "attribute" and "value".
2. Requesting Message Disposition Notifications
Message disposition notifications are requested by including a
Disposition-Notification-To header in the message. Further
information to be used by the recipient’s MUA in generating the MDN
may be provided by also including Original-Recipient and/or
Disposition-Notification-Options headers in the message.
2.1. The Disposition-Notification-To Header
A request for the receiving user agent to issue message disposition
notifications is made by placing a Disposition-Notification-To header
into the message. The syntax of the header is
mdn-request-header = "Disposition-Notification-To" ":"
mailbox *("," mailbox)
The presence of a Disposition-Notification-To header in a message is
merely a request for an MDN. The recipients’ user agents are always
free to silently ignore such a request. Alternatively, an explicit
denial of the request for information about the disposition of the
message may be sent using the "denied" disposition in an MDN.
An MDN MUST NOT itself have a Disposition-Notification-To header. An
MDN MUST NOT be generated in response to an MDN.
A user agent MUST NOT issue more than one MDN on behalf of each
particular recipient. That is, once an MDN has been issued on behalf
of a recipient, no further MDNs may be issued on behalf of that
recipient, even if another disposition is performed on the message.
However, if a message is forwarded, an MDN may have been issued for
the recipient doing the forwarding and the recipient of the forwarded
message may also cause an MDN to be generated.
While Internet standards normally do not specify the behavior of user
interfaces, it is strongly recommended that the user agent obtain the
user’s consent before sending an MDN. This consent could be obtained
for each message through some sort of prompt or dialog box, or
globally through the user’s setting of a preference. The user might
also indicate globally that MDNs are to never be sent or that a
"denied" MDN is always sent in response to a request for an MDN.
MDNs SHOULD NOT be sent automatically if the address in the
Disposition-Notification-To header differs from the address in the
Return-Path header (see [RFC-MSGFMT]). In this case, confirmation
from the user SHOULD be obtained, if possible. If obtaining consent
is not possible (e.g., because the user is not online at the time),
then an MDN SHOULD NOT be sent.
Confirmation from the user SHOULD be obtained (or no MDN sent) if
there is no Return-Path header in the message, or if there is more
than one distinct address in the Disposition-Notification-To header.
The comparison of the addresses should be done using only the addr-
spec (local-part "@" domain) portion, excluding any phrase and route.
The comparison MUST be case-sensitive for the local-part and case-
insensitive for the domain part.
If the message contains more than one Return-Path header, the
implementation may pick one to use for the comparison, or treat the
situation as a failure of the comparison.
The reason for not automatically sending an MDN if the comparison
fails or more than one address is specified is to reduce the
possibility of mail loops and of MDNs being used for mail bombing.
A message that contains a Disposition-Notification-To header SHOULD
also contain a Message-ID header as specified in [RFC-MSGFMT]. This
will permit automatic correlation of MDNs with their original
messages by user agents.
If the request for message disposition notifications for some
recipients and not others is desired, two copies of the message
should be sent, one with a Disposition-Notification-To header and one
without. Many of the other headers of the message (e.g., To, Cc)
will be the same in both copies. The recipients in the respective
message envelopes determine for whom message disposition
notifications are requested and for whom they are not. If desired,
the Message-ID header may be the same in both copies of the message.
Note that there are other situations (e.g., Bcc) in which it is
necessary to send multiple copies of a message with slightly
different headers. The combination of such situations and the need
to request MDNs for a subset of all recipients may result in more
than two copies of a message being sent, some with a Disposition-
Notification-To header and some without.
Messages posted to newsgroups SHOULD NOT have a Disposition-
Notification-To header.
2.2. The Disposition-Notification-Options Header
Future extensions to this specification may require that information
be supplied to the recipient’s MUA for additional control over how
and what MDNs are generated. The Disposition-Notification-Options
header provides an extensible mechanism for such information. The
syntax of this header is as follows:
Disposition-Notification-Options =
"Disposition-Notification-Options" ":"
disposition-notification-parameters
disposition-notification-parameters = parameter *(";" parameter)
parameter = attribute "=" importance "," value *("," value)
importance = "required" / "optional"
An importance of "required" indicates that interpretation of the
parameter is necessary for proper generation of an MDN in response to
this request. If an MUA does not understand the meaning of the
parameter, it MUST NOT generate an MDN with any disposition type
other than "failed" in response to the request. An importance of
"optional" indicates that an MUA that does not understand the meaning
of this parameter MAY generate an MDN in response anyway, ignoring
the value of the parameter.
No parameters are defined in this specification. Parameters may be
defined in the future by later revisions or extensions to this
specification. Parameter attribute names beginning with "X-" will
never be defined as standard names; such names are reserved for
experimental use. MDN parameter names not beginning with "X-" MUST
be registered with the Internet Assigned Numbers Authority (IANA) and
described in a standards-track RFC or an experimental RFC approved by
the IESG. (See Section 10 for a registration form.)
If a required parameter is not understood or contains some sort of
error, the receiving MUA SHOULD issue an MDN with a disposition type
of "failed" (see Section 3.2.6), and include a Failure field (see
Section 3.2.7) that further describes the problem. MDNs with the
disposition type of "failed" and a "Failure" field MAY also be
generated when other types of errors are detected in the parameters
of the Disposition-Notification-Options header.
However, an MDN with a disposition type of "failed" MUST NOT be
generated if the user has indicated a preference that MDNs are not to
be sent. If user consent would be required for an MDN of some other
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-SMTP] and [RFC-DSN-SMTP].
[RFC-DSN-SMTP] is amended as follows: If the ORCPT 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 is as
follows:
original-recipient-header =
"Original-Recipient" ":" address-type ";" generic-address
The address-type and generic-address token are 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-MIME-MEDIA]) 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-MIME-MEDIA]). 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
that will be generated for the fragment. If these headers occur in
the headers of the "inner" or "enclosed" message (using the terms of
[RFC-MIME-MEDIA]), they pertain to an MDN that will be generated for
the reassembled message. Section 5.2.2.1 of [RFC-MIME-MEDIA]) 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 occurrences
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-REPORT]). When
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-REPORT].
(c) The second component of the multipart/report is of content-type
message/disposition-notification, described in section 3.1 of
this document.
(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 MUA 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 disposition 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-MSGFMT] headers that 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
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-MSGFMT] header
"fields". 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-
MSGFMT], 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 that
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-MIME-HEADER].
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:
(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) maintains a registry
of address-type and mta-name-type values, along with descriptions of
the meanings of each, or a reference to one or more specifications
that provide such descriptions. (The "rfc822" address-type is