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,
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 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 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
This document specifies three types of parameters that must be
registered with the Internet Assigned Numbers Authority (IANA).
The forms below are for use when registering a new parameter name for
the Disposition-Notification-Options header, 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, 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 parameter names
A registration for a Disposition-Notification-Options header
parameter name MUST include the following information:
(a) The proposed parameter name.
(b) The syntax for parameter values, specified using BNF, ABNF,
regular expressions, or other non-ambiguous language.
(c) If 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.
(d) A reference to a standards track RFC or experimental RFC
approved by the IESG that describes the semantics of the
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 standards track RFC or experimental RFC
approved by the IESG 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.
(d) A reference to a standards track RFC or experimental RFC
approved by the IESG that describes the semantics of the
extension field.
11. Acknowledgments
This document is an updated version of the original document written
by Roger Fajman. His contributions to the definition of Message
Disposition Notifications are greatly appreciated.
RFC 2298 was based on the Delivery Status Notifications document
[RFC-DSN-FORMAT] by Keith Moore and Greg Vaudreuil. Contributions
were made by members of the IETF Receipt Working Group, including
Harald Alvestrand, Ian Bell, Urs Eppenberger, Claus Andri Faerber,
Ned Freed, Jim Galvin, Carl Hage, Mike Lake, Keith Moore, Paul
Overell, Pete Resnick, and Chuck Shih.
12. References
12.1. Normative References
[RFC-SMTP] Klensin, J., Ed., "Simple Mail Transfer Protocol",
RFC 2821, April 2001.
[RFC-MSGFMT] Resnick, P., Ed., "Internet Message Format", RFC
2822, April 2001.
[RFC-MIME-BODY] Freed, N. and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) Part One: Format of Internet
Message Bodies", RFC 2045, November 1996.
[RFC-MIME-MEDIA] Freed, N. and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) Part Two: Media Types", RFC
2046, November 1996.
[RFC-MIME-HEADER] Moore, K., "MIME (Multipurpose Internet Mail
Extensions) Part Three: Message Header Extensions
for Non-ASCII Text", RFC 2047, November 1996.
[RFC-REPORT] Vaudreuil, G., "The Multipart/Report Content Type
for the Reporting of Mail System Administrative
Messages", RFC 3462, January 2003.
[RFC-DSN-SMTP] Moore, K., "Simple Mail Transfer Protocol (SMTP)
Service Extension for Delivery Status
Notifications", RFC 3461, January 2003.
[RFC-DSN-FORMAT] Moore, K., and G. Vaudreuil, "An Extensible Format
for Delivery Status Notifications (DSNs)", RFC
3464, January 2003.
[RFC-KEYWORDS] Bradner, S., "Key Words for Use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
12.2. Informative References
[SEC-SERVICES] Hoffman, P., Ed., "Enhanced Security Services for
S/MIME", RFC 2634, June 1999.
Appendix A - Changes from RFC 2298
The document has new editors.
The dispositions "denied", and "failed" were removed from the
document reflecting the lack of implementation or usage at this time.
The disposition modifiers "warning", "superseded", "expired",
"mailbox-terminated" have not seen actual implementation. They have
been deleted from this document. The extension modifier, as of yet
unused, has been retained for future extension.
General editorial cleanups include spelling, grammar, and consistency
in usage of terms.
The document has modified BNF for disposition notification options to
eliminate the need for dummy values where not otherwise needed.
Authors’ Addresses
Tony Hansen
AT&T Laboratories
Middletown, NJ 07748
USA
Voice: +1-732-420-8934
EMail: tony+rfc3798@maillennium.att.com
Gregory M. Vaudreuil
Lucent Technologies
7291 Williamson Rd
Dallas, TX 75214
USA
Voice: +1 214 823 9325
EMail: GregV@ieee.org
Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.