📄 rfc2298.txt
字号:
Network Working Group R. Fajman
Request for Comments: 2298 National Institutes of Health
Category: Standards Track March 1998
An Extensible Message Format
for Message Disposition Notifications
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 (1998). All Rights Reserved.
Abstract
This memo defines a MIME content-type that may be used by a mail user
agent (UA) or electronic mail gateway to report the disposition of a
message after it has been sucessfully 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 the privacy concerns that 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 ............................................ 2
2. Requesting Message Disposition Notifications ............ 3
3. Format of a Message Disposition Notification ............ 7
4. Timeline of events ...................................... 17
5. Conformance and Usage Requirements ...................... 18
6. Security Considerations ................................. 19
7. Collected Grammar ....................................... 20
8. Guidelines for Gatewaying MDNs .......................... 22
9. Example ................................................. 24
10. IANA Registration Forms ................................. 25
11. Acknowledgments ......................................... 26
12. References .............................................. 26
13. Author's Address ........................................ 27
14. Copyright ............................................... 28
1. Introduction
This memo defines a MIME content-type [5] 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
1892 [7].
This memo defines the format of the notifications and the RFC 822
headers used to request them.
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 2119.
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
succcessful delivery, in a manner which 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, as well as being 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 is 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 accomodate
future requirements.
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 UA in generating the MDN
may be provided by including Original-Recipient and/or Disposition-
Notification-Options headers in the message.
2.1 The Disposition-Notification-To Header
A request that the receiving user agent issue message disposition
notifications is made by placing a Disposition-Notification-To header
into the message. The syntax of the header, using the ABNF of RFC
822 [2], is
mdn-request-header = "Disposition-Notification-To" ":" 1#mailbox
The mailbox token is as specified in RFC 822 [2].
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.
At most one MDN may be issued on behalf of each particular recipient
by their user agent. 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 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 never to 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 822 [2]). 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
possibilities for mail loops and use of MDNs for mail bombing.
A message that contains a Disposition-Notification-To header SHOULD
also contain a Message-ID header as specified in RFC 822 [2]. This
will permit automatic correlation of MDNs with original messages by
user agents.
If it is desired to request message disposition notifications for
some recipients and not others, two copies of the message should be
sent, one with an 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 UA 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, using the ABNF of RFC 822 [2], is
Disposition-Notification-Options =
"Disposition-Notification-Options" ":"
disposition-notification-parameters
disposition-notification-parameters = parameter *(";" parameter)
parameter = attribute "=" importance "," 1#value
importance = "required" / "optional"
The definitions of attribute and value are as in the definition of
the Content-Type header in RFC 2045 [4].
An importance of "required" indicates that interpretation of the
parameter is necessary for proper generation of an MDN in response to
this request. If a UA 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 a UA 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 UA 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 a
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 preferance 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 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
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".
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -