draft-ietf-appsawg-mdn-3798bis-11.txt   draft-ietf-appsawg-mdn-3798bis-12.txt 
Network Working Group T. Hansen, Ed. Network Working Group T. Hansen, Ed.
Internet-Draft AT&T Laboratories Internet-Draft AT&T Laboratories
Obsoletes: 3798 (if approved) A. Melnikov, Ed. Obsoletes: 3798 (if approved) A. Melnikov, Ed.
Updates: 2046, 3461 (if approved) Isode Ltd Updates: 2046, 3461 (if approved) Isode Ltd
Intended status: Standards Track August 4, 2016 Intended status: Standards Track August 12, 2016
Expires: February 5, 2017 Expires: February 13, 2017
Message Disposition Notification Message Disposition Notification
draft-ietf-appsawg-mdn-3798bis-11.txt draft-ietf-appsawg-mdn-3798bis-12.txt
Abstract Abstract
This memo defines a MIME content-type that may be used by a mail user 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 agent (MUA) or electronic mail gateway to report the disposition of a
message after it has been successfully delivered to a recipient. message after it has been successfully delivered to a recipient.
This content-type is intended to be machine-processable. Additional This content-type is intended to be machine-processable. Additional
message header fields are also defined to permit Message Disposition message header fields are also defined to permit Message Disposition
Notifications (MDNs) to be requested by the sender of a message. The Notifications (MDNs) to be requested by the sender of a message. The
purpose is to extend Internet Mail to support functionality often purpose is to extend Internet Mail to support functionality often
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Because many messages are sent between the Internet and other Because many messages are sent between the Internet and other
messaging systems (such as X.400 or the proprietary "LAN-based" messaging systems (such as X.400 or the proprietary "LAN-based"
systems), the MDN protocol is designed to be useful in a multi- systems), the MDN protocol is designed to be useful in a multi-
protocol messaging environment. To this end, the protocol described protocol messaging environment. To this end, the protocol described
in this memo provides for the carriage of "foreign" addresses, in in this memo provides for the carriage of "foreign" addresses, in
addition to those normally used in Internet Mail. Additional addition to those normally used in Internet Mail. Additional
attributes may also be defined to support "tunneling" of foreign attributes may also be defined to support "tunneling" of foreign
notifications through Internet Mail. notifications through Internet Mail.
This document obsoletes RFC 3798 and updates RFC 2046 and RFC 3461.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 5, 2017. This Internet-Draft will expire on February 13, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 26 skipping to change at page 3, line 28
1. Introduction 1. Introduction
This memo defines a media type [RFC2046] for message disposition This memo defines a media type [RFC2046] for message disposition
notifications (MDNs). An MDN can be used to notify the sender of a notifications (MDNs). An MDN can be used to notify the sender of a
message of any of several conditions that may occur after successful message of any of several conditions that may occur after successful
delivery, such as display of the message contents, printing of the delivery, such as display of the message contents, printing of the
message, deletion (without display) of the message, or the message, deletion (without display) of the message, or the
recipient's refusal to provide MDNs. The "message/disposition- recipient's refusal to provide MDNs. The "message/disposition-
notification" content-type defined herein is intended for use within notification" content-type defined herein is intended for use within
the framework of the "multipart/report" content type defined in RFC- the framework of the "multipart/report" content type defined in RFC-
REPORT [RFC3462]. REPORT [RFC6522].
This memo defines the format of the notifications and the RFC-MSGFMT This memo defines the format of the notifications and the RFC-MSGFMT
[RFC5322] header fields used to request them. [RFC5322] header fields used to request them.
This memo is an update to RFC 3798 and is intended to be published at This memo is an update to RFC 3798 and is intended to be published at
Internet Standard Level. Internet Standard Level.
This memo is currently marked with the 'pre5378Trust200902' IPR
statements until a release has been obtained from all previous
authors and editors of this text.
1.1. Purposes 1.1. Purposes
The MDNs defined in this memo are expected to serve several purposes: The MDNs defined in this memo are expected to serve several purposes:
a. Inform human beings of the disposition of messages after a. Inform human beings of the disposition of messages after
successful delivery, in a manner that is largely independent of successful delivery, in a manner that is largely independent of
human language; human language;
b. Allow mail user agents to keep track of the disposition of b. Allow mail user agents to keep track of the disposition of
messages sent, by associating returned MDNs with earlier message messages sent, by associating returned MDNs with earlier message
skipping to change at page 5, line 47 skipping to change at page 5, line 47
of a recipient, no further MDNs may be issued on behalf of that of a recipient, no further MDNs may be issued on behalf of that
recipient by the same user agent, even if another disposition is recipient by the same user agent, even if another disposition is
performed on the message. However, if a message is forwarded, an MDN performed on the message. However, if a message is forwarded, an MDN
may have been issued for the recipient doing the forwarding and the may have been issued for the recipient doing the forwarding and the
recipient of the forwarded message may also cause an MDN to be recipient of the forwarded message may also cause an MDN to be
generated. generated.
It is also possible that if the same message is being accessed by It is also possible that if the same message is being accessed by
multiple user agents (for example using POP3), then multiple multiple user agents (for example using POP3), then multiple
dispositions might be generated for the same recipient. User agents dispositions might be generated for the same recipient. User agents
SHOULD laverage support in the underlying message access protocol to SHOULD leverage support in the underlying message access protocol to
prevent multiple MDNs from being generated. In particular, when the prevent multiple MDNs from being generated. In particular, when the
user agent is accessing the message using RFC-IMAP [RFC3501], it user agent is accessing the message using RFC-IMAP [RFC3501], it
SHOULD implement the procedures specified in RFC-IMAP-MDN [RFC3503]. SHOULD implement the procedures specified in RFC-IMAP-MDN [RFC3503].
While Internet standards normally do not specify the behavior of user While Internet standards normally do not specify the behavior of user
interfaces, it is strongly recommended that the user agent obtain the interfaces, it is strongly recommended that the user agent obtain the
user's consent before sending an MDN. This consent could be obtained user's consent before sending an MDN. This consent could be obtained
for each message through some sort of prompt or dialog box, or for each message through some sort of prompt or dialog box, or
globally through the user's setting of a preference. The purpose of globally through the user's setting of a preference. The purpose of
obtaining user's consent is to protect user's privacy. If user's obtaining user's consent is to protect user's privacy. The default
consent is obtained through a preference, the default value should be value should be not to send MDNs.
not to send MDNs.
MDNs MUST NOT be sent automatically if the address in the MDNs MUST NOT be sent automatically if the address in the
Disposition-Notification-To header field differs from the address in Disposition-Notification-To header field differs from the address in
the Return-Path header field (see RFC-MSGFMT [RFC5322]). In this the Return-Path header field (see RFC-MSGFMT [RFC5322]). In this
case, confirmation from the user MUST be obtained, if possible. If case, confirmation from the user MUST be obtained, if possible. If
obtaining consent is not possible (e.g., because the user is not obtaining consent is not possible (e.g., because the user is not
online at the time or the client is not an interactive email client), online at the time or the client is not an interactive email client),
then an MDN MUST NOT be sent. then an MDN MUST NOT be sent.
Confirmation from the user MUST be obtained (or no MDN sent) if there Confirmation from the user MUST be obtained (or no MDN sent) if there
is no Return-Path header field in the message, or if there is more is no Return-Path header field in the message, or if there is more
than one distinct address in the Disposition-Notification-To header than one distinct address in the Disposition-Notification-To header
field. field.
The comparison of the addresses is done using only the addr-spec The comparison of the addresses is done using only the addr-spec
(local-part "@" domain) portion, excluding any angle brackets, phrase (local-part "@" domain) portion, excluding any angle brackets, phrase
and route. As prescribed by RFC 5322, the comparison MUST be case- and route. As prescribed by RFC 5322, the comparison is case-
sensitive for the local-part and case-insensitive for the domain sensitive for the local-part and case-insensitive for the domain
part. The local-part comparison SHOULD be done after performing part. The local-part comparison SHOULD be done after performing
local-part canonicalization (i.e. after removing the surrounding local-part canonicalization (i.e. after removing the surrounding
double-quote characters, if any, as well as any escaping "\" double-quote characters, if any, as well as any escaping "\"
characters. (See RFC-MSGFMT [RFC5322] for more details.) characters. (See RFC-MSGFMT [RFC5322] for more details.)
Implementations MAY treat known domain aliases as equivalent for the Implementations MAY treat known domain aliases as equivalent for the
purpose of comparison. purpose of comparison.
Note that use of subaddressing (see [RFC5233]) can result in a Note that use of subaddressing (see [RFC5233]) can result in a
failure to match two local-parts and thus result in possible failure to match two local-parts and thus result in possible
skipping to change at page 7, line 28 skipping to change at page 7, line 25
copies of the message. Note that there are other situations (e.g., 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 Bcc) in which it is necessary to send multiple copies of a message
with slightly different header fields. The combination of such with slightly different header fields. The combination of such
situations and the need to request MDNs for a subset of all situations and the need to request MDNs for a subset of all
recipients may result in more than two copies of a message being recipients may result in more than two copies of a message being
sent, some with a Disposition-Notification-To header field and some sent, some with a Disposition-Notification-To header field and some
without. without.
If it is possible to determine that a recipient is a newsgroup, do If it is possible to determine that a recipient is a newsgroup, do
not include a Disposition-Notification-To header field for that not include a Disposition-Notification-To header field for that
recipient. recipient. Similarly, if an existing message is resent or gatewayed
to a newsgroup, the agent doing resending/gatewaying SHOULD strip the
Disposition-Notification-To header field. See Section 5 for more
discussion. Clients that see an otherwise valid Disposition-
Notification-To header field in a newsgroup message SHOULD NOT
generate an MDN.
2.2. The Disposition-Notification-Options Header 2.2. The Disposition-Notification-Options Header
Extensions to this specification may require that information be Extensions to this specification may require that information be
supplied to the recipient's MUA for additional control over how and supplied to the recipient's MUA for additional control over how and
what MDNs are generated. The Disposition-Notification-Options header what MDNs are generated. The Disposition-Notification-Options header
field provides an extensible mechanism for such information. The field provides an extensible mechanism for such information. The
syntax of this header field is as follows: syntax of this header field is as follows:
Disposition-Notification-Options = Disposition-Notification-Options =
skipping to change at page 8, line 37 skipping to change at page 8, line 37
of an MDN in response to this request. An importance of "optional" of an MDN in response to this request. An importance of "optional"
indicates that an MUA that does not understand the meaning of this indicates that an MUA that does not understand the meaning of this
disposition-notification-parameter MAY generate an MDN in response disposition-notification-parameter MAY generate an MDN in response
anyway, ignoring the value of the disposition-notification-parameter. anyway, ignoring the value of the disposition-notification-parameter.
No disposition-notification-parameter attribute names are defined in No disposition-notification-parameter attribute names are defined in
this specification. Attribute names may be defined in the future by this specification. Attribute names may be defined in the future by
later revisions or extensions to this specification. disposition- later revisions or extensions to this specification. disposition-
notification-parameter attribute names MUST be registered with the notification-parameter attribute names MUST be registered with the
Internet Assigned Numbers Authority (IANA) using "Specification Internet Assigned Numbers Authority (IANA) using "Specification
required" registration policy. Note that a previous version of this required" registration policy. The "X-" prefix has historically been
specification reserved disposition-notification-parameter attribute used to denote unregistered "experimental" protocol elements, that
names beginning with "X-" for experimental use, but they can now be are assumed not to become common use. Deployment experience of this
registered. and other protocols have shown that this assumption is often false.
This document allows the use of the "X-" prefix primarily to allow
the registration of attributes that are already in common use. The
prefix has no meaning for new attributes. Its use in substantially
new attributes may cause confusion and is therefore discouraged.
(See Section 10 for a registration form.) (See Section 10 for a registration form.)
2.3. The Original-Recipient Header Field 2.3. The Original-Recipient Header Field
Since electronic mail addresses may be rewritten while the message is Since electronic mail addresses may be rewritten while the message is
in transit, it is useful for the original recipient address to be in transit, it is useful for the original recipient address to be
made available by the delivering Message Transfer Agent (MTA) made available by the delivering Message Transfer Agent (MTA)
[RFC5598]. The delivering MTA may be able to obtain this information [RFC5598]. The delivering MTA may be able to obtain this information
from the ORCPT parameter of the SMTP RCPT TO command, as defined in from the ORCPT parameter of the SMTP RCPT TO command, as defined in
RFC-SMTP [RFC5321] and RFC-DSN-SMTP [RFC3461]. RFC-SMTP [RFC5321] and RFC-DSN-SMTP [RFC3461].
skipping to change at page 10, line 13 skipping to change at page 10, line 16
that, in addition to the header fields specified there, the three that, in addition to the header fields specified there, the three
header fields described in this specification are to be appended, in header fields described in this specification are to be appended, in
order, to the header fields of the reassembled message. Any order, to the header fields of the reassembled message. Any
occurrences of the three header fields defined here in the header occurrences of the three header fields defined here in the header
fields of the initial enclosing message MUST NOT be copied to the fields of the initial enclosing message MUST NOT be copied to the
reassembled message. reassembled message.
3. Format of a Message Disposition Notification 3. Format of a Message Disposition Notification
A message disposition notification is a MIME message with a top-level A message disposition notification is a MIME message with a top-level
content-type of multipart/report (defined in RFC-REPORT [RFC3462]). content-type of multipart/report (defined in RFC-REPORT [RFC6522]).
When multipart/report content is used to transmit an MDN: When multipart/report content is used to transmit an MDN:
a. The report-type parameter of the multipart/report content is a. The report-type parameter of the multipart/report content is
"disposition-notification". "disposition-notification".
b. The first component of the multipart/report contains a human- b. The first component of the multipart/report contains a human-
readable explanation of the MDN, as described in RFC-REPORT readable explanation of the MDN, as described in RFC-REPORT
[RFC3462]. [RFC6522].
c. The second component of the multipart/report is of content-type c. The second component of the multipart/report is of content-type
message/disposition-notification, described in Section 3.1 of message/disposition-notification, described in Section 3.1 of
this document. this document.
d. If the original message or a portion of the message is to be 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 returned to the sender, it appears as the third component of the
multipart/report. The decision of whether or not to return 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 message or part of the message is up to the MUA generating the
MDN. However, in the case of encrypted messages requesting MDNs, MDN. However, in the case of encrypted messages requesting MDNs,
skipping to change at page 11, line 43 skipping to change at page 11, line 45
Subtype name: disposition-notification Subtype name: disposition-notification
Required parameters: none Required parameters: none
Optional parameters: none Optional parameters: none
Encoding considerations: "7bit" encoding is sufficient and MUST be Encoding considerations: "7bit" encoding is sufficient and MUST be
used to maintain readability when viewed by non- used to maintain readability when viewed by non-
MIME mail readers. MIME mail readers.
Security considerations: discussed in Section 6 of [RFCXXX]. Security considerations: discussed in Section 6 of [RFCXXXX].
Interoperability considerations: none Interoperability considerations: none
Published specification: [RFCXXX]
Published specification: [RFCXXXX]
Applications that use this media type: Mail Transfer Agents and Applications that use this media type: Mail Transfer Agents and
email clients that support multipart/report email clients that support multipart/report
generation and/or parsing. generation and/or parsing.
Fragment identifier considerations: N/A Fragment identifier considerations: N/A
Additional information: Additional information:
Deprecated alias names for this type: N/A Deprecated alias names for this type: N/A
skipping to change at page 20, line 5 skipping to change at page 20, line 5
Disposition modifiers may be defined in the Disposition modifiers may be defined in the
future by later revisions or extensions to this future by later revisions or extensions to this
specification. MDN disposition value names MUST specification. MDN disposition value names MUST
be registered with the Internet Assigned Numbers be registered with the Internet Assigned Numbers
Authority (IANA) using "Specification required" Authority (IANA) using "Specification required"
registration policy. (See Section 10 for a registration policy. (See Section 10 for a
registration form.) MDNs with disposition registration form.) MDNs with disposition
modifier names not understood by the receiving modifier names not understood by the receiving
MUA MAY be silently ignored or placed in the MUA MAY be silently ignored or placed in the
user's mailbox without special interpretation. user's mailbox without special interpretation.
They MUST not cause any error message to be sent They MUST NOT cause any error message to be sent
to the sender of the MDN. to the sender of the MDN.
It is not required that an MUA be able to generate all of the It is not required that an MUA be able to generate all of the
possible values of the Disposition field. possible values of the Disposition field.
A user agent MUST NOT issue more than one MDN on behalf of each 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 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 of a recipient, no further MDNs may be issued on behalf of that
recipient, even if another disposition is performed on the message. recipient, even if another disposition is performed on the message.
However, if a message is forwarded, a "dispatched" MDN MAY be issued However, if a message is forwarded, a "dispatched" MDN MAY be issued
skipping to change at page 21, line 31 skipping to change at page 21, line 31
-- MSA sends message to next MTA. -- MSA sends message to next MTA.
-- Final MTA receives message. -- Final MTA receives message.
-- Final MTA delivers message to recipient's mailbox (possibly -- Final MTA delivers message to recipient's mailbox (possibly
generating a Delivery Status Notification (DSN)). generating a Delivery Status Notification (DSN)).
-- (Recipient's) MUA discovers a new message in recipient's mailbox -- (Recipient's) MUA discovers a new message in recipient's mailbox
and decides whether an MDN should be generated. If the MUA has and decides whether an MDN should be generated. If the MUA has
information that an MDN has been generated for this message, no information that an MDN has already been generated for this
further MDN processing described below is performed. If MUA message, no further MDN processing described below is performed.
decides that no MDN can be generated, no further MDN processing If MUA decides that no MDN can be generated, no further MDN
described below is performed. processing described below is performed.
-- MUA performs automatic processing and might generate corresponding -- MUA performs automatic processing and might generate corresponding
MDNs ("dispatched", "processed" or "deleted" disposition type with MDNs ("dispatched", "processed" or "deleted" disposition type with
"automatic-action" and "MDN-sent-automatically" disposition "automatic-action" and "MDN-sent-automatically" disposition
modes). The MUA remembers that an MDN was generated. modes). The MUA remembers that an MDN was generated.
-- MUA displays list of messages to user. -- MUA displays list of messages to user.
-- User selects a message and requests that some action be performed -- User selects a message and requests that some action be performed
on it. on it.
skipping to change at page 22, line 39 skipping to change at page 22, line 39
DSN-SMTP [RFC3461] permits such information to be carried in the DSN-SMTP [RFC3461] permits such information to be carried in the
envelope if it is available. The Original-Recipient header field envelope if it is available. The Original-Recipient header field
defined in this document provides a way for the MTA to pass the defined in this document provides a way for the MTA to pass the
original recipient address to the MUA. original recipient address to the MUA.
Each sender-specified recipient address may result in more than one Each sender-specified recipient address may result in more than one
MDN. If an MDN is requested for a recipient that is forwarded to MDN. If an MDN is requested for a recipient that is forwarded to
multiple recipients of an "alias" (as defined in RFC-DSN-SMTP multiple recipients of an "alias" (as defined in RFC-DSN-SMTP
[RFC3461], section 6.2.7.3), each of the recipients may issue an MDN. [RFC3461], section 6.2.7.3), each of the recipients may issue an MDN.
Successful distribution of a message to a mailing list exploder Successful distribution of a message to a mailing list exploder or
SHOULD be considered the final disposition of the message. A mailing gateway to Usenet newsgroup SHOULD be considered the final
list exploder MAY issue an MDN with a disposition type of "processed" disposition of the message. A mailing list exploder MAY issue an MDN
and disposition modes of "automatic-action" and "MDN-sent- with a disposition type of "processed" and disposition modes of
automatically" indicating that the message has been forwarded to the "automatic-action" and "MDN-sent-automatically" indicating that the
list. In this case, the request for MDNs is not propagated to the message has been forwarded to the list. In this case, the request
members of the list. for MDNs is not propagated to the members of the list.
Alternatively (if successful distribution of a message to a mailing Alternatively (if successful distribution of a message to a mailing
list exploder is not considered the final disposition of the list exploder/Usenet newsgroup is not considered the final
message), the mailing list exploder can issue no MDN and propagate disposition of the message), the mailing list exploder can issue no
the request for MDNs to all members of the list. The latter behavior MDN and propagate the request for MDNs to all members of the list.
is not recommended for any but small, closely knit lists, as it might
cause large numbers of MDNs to be generated and may cause The latter behavior is not recommended for any but small, closely
confidential subscribers to the list to be revealed. The mailing knit lists, as it might cause large numbers of MDNs to be generated
list exploder can also direct MDNs to itself, correlate them, and and may cause confidential subscribers to the list to be revealed.
produce a report to the original sender of the message. 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 This specification places no restrictions on the processing of MDNs
received by user agents or mailing lists. received by user agents or mailing lists.
6. Security Considerations 6. Security Considerations
The following security considerations apply when using MDNs: The following security considerations apply when using MDNs:
6.1. Forgery 6.1. Forgery
skipping to change at page 23, line 47 skipping to change at page 23, line 48
MDNs may reveal other sensitive information (e.g., when the message MDNs may reveal other sensitive information (e.g., when the message
was read). In this situation, it is acceptable for the MUA to was read). In this situation, it is acceptable for the MUA to
silently ignore requests for MDNs. silently ignore requests for MDNs.
If the Disposition-Notification-To header field is passed on If the Disposition-Notification-To header field is passed on
unmodified when a message is distributed to the subscribers of a unmodified when a message is distributed to the subscribers of a
mailing list, the subscribers to the list may be revealed to the mailing list, the subscribers to the list may be revealed to the
sender of the original message by the generation of MDNs. sender of the original message by the generation of MDNs.
Headers of the original message returned in part 3 of the multipart/ Headers of the original message returned in part 3 of the multipart/
report could reveal confidential information about host names and/or 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. network topology inside a firewall.
Disposition mode (Section 3.2.6.1) can leak information about Disposition mode (Section 3.2.6.1) can leak information about
recipient's MUA configuration, in particular whether MDNs are recipient's MUA configuration, in particular whether MDNs are
acknowledged manually or automatically. If this is a concern, MUAs acknowledged manually or automatically. If this is a concern, MUAs
can return "manual-action/MDN-sent-manually" disposition mode in can return "manual-action/MDN-sent-manually" disposition mode in
generated MDNs. generated MDNs.
An unencrypted MDN could reveal confidential information about an
encrypted message, especially if all or part of the original message
is returned in part 3 of the multipart/report. Encrypted MDNs are
not defined in this specification.
In general, any optional MDN field may be omitted if the Reporting In general, any optional MDN field may be omitted if the Reporting
MUA site or user determines that inclusion of the field would impose MUA site or user determines that inclusion of the field would impose
too great a compromise of site confidentiality. The need for such too great a compromise of site confidentiality. The need for such
confidentiality must be balanced against the utility of the omitted confidentiality must be balanced against the utility of the omitted
information in MDNs. information in MDNs.
In some cases, someone with access to the message stream may use the 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. 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 If the target is known to generate MDN reports, they could add a
disposition-notification-to field containing the envelope from disposition-notification-to field containing the envelope from
skipping to change at page 32, line 38 skipping to change at page 32, line 38
characters from the US-ASCII repertoire, a specification for how characters from the US-ASCII repertoire, a specification for how
they are to be encoded as graphic US-ASCII characters in a they are to be encoded as graphic US-ASCII characters in a
Disposition-Notification-Options header field. Disposition-Notification-Options header field.
d. A reference to a permanent and readily available public d. A reference to a permanent and readily available public
specification that describes the semantics of the extension specification that describes the semantics of the extension
field. field.
11. Acknowledgements 11. Acknowledgements
The contributions of Bruce Lilly, Alfred Hoenes, Barry Leiba and Pete The contributions of Bruce Lilly, Alfred Hoenes, Barry Leiba, Ben
Resnick are gratefully acknowledged for this revision. Campbell and Pete Resnick are gratefully acknowledged for this
revision.
The contributions of Roger Fajman and Greg Vaudreuil to earlier The contributions of Roger Fajman and Greg Vaudreuil to earlier
versions of this document are also gratefully acknowledged. versions of this document are also gratefully acknowledged.
12. References 12. References
12.1. Normative References 12.1. Normative References
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
DOI 10.17487/RFC5321, October 2008, DOI 10.17487/RFC5321, October 2008,
skipping to change at page 33, line 32 skipping to change at page 33, line 32
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, Extensions (MIME) Part Two: Media Types", RFC 2046,
DOI 10.17487/RFC2046, November 1996, DOI 10.17487/RFC2046, November 1996,
<http://www.rfc-editor.org/info/rfc2046>. <http://www.rfc-editor.org/info/rfc2046>.
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
Part Three: Message Header Extensions for Non-ASCII Text", Part Three: Message Header Extensions for Non-ASCII Text",
RFC 2047, DOI 10.17487/RFC2047, November 1996, RFC 2047, DOI 10.17487/RFC2047, November 1996,
<http://www.rfc-editor.org/info/rfc2047>. <http://www.rfc-editor.org/info/rfc2047>.
[RFC3462] Vaudreuil, G., "The Multipart/Report Content Type for the [RFC6522] Kucherawy, M., Ed., "The Multipart/Report Media Type for
Reporting of Mail System Administrative Messages", the Reporting of Mail System Administrative Messages",
RFC 3462, DOI 10.17487/RFC3462, January 2003, STD 73, RFC 6522, DOI 10.17487/RFC6522, January 2012,
<http://www.rfc-editor.org/info/rfc3462>. <http://www.rfc-editor.org/info/rfc6522>.
[RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
Extension for Delivery Status Notifications (DSNs)", Extension for Delivery Status Notifications (DSNs)",
RFC 3461, DOI 10.17487/RFC3461, January 2003, RFC 3461, DOI 10.17487/RFC3461, January 2003,
<http://www.rfc-editor.org/info/rfc3461>. <http://www.rfc-editor.org/info/rfc3461>.
[RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format
for Delivery Status Notifications", RFC 3464, for Delivery Status Notifications", RFC 3464,
DOI 10.17487/RFC3464, January 2003, DOI 10.17487/RFC3464, January 2003,
<http://www.rfc-editor.org/info/rfc3464>. <http://www.rfc-editor.org/info/rfc3464>.
skipping to change at page 35, line 22 skipping to change at page 35, line 22
"X-" fields no longer reserved for experimental use and can now be "X-" fields no longer reserved for experimental use and can now be
registered in compliance with RFC 6648. registered in compliance with RFC 6648.
Fixed the default MTA-name-type used in "MDN-Gateway" to be "dns". Fixed the default MTA-name-type used in "MDN-Gateway" to be "dns".
Strengthen requirements on obtaining user consent in order to protect Strengthen requirements on obtaining user consent in order to protect
user privacy. user privacy.
The values of "dispatched" and "processed" were lost from the ABNF The values of "dispatched" and "processed" were lost from the ABNF
for "disposition-type". for "disposition-type". (Erratum #691)
Because the warning disposition modifier was previously removed, Because the warning disposition modifier was previously removed,
warning-field has also been removed. warning-field has also been removed. (Erratum #692)
The ABNF for ua-name and ua-product included semi-colon, which could The ABNF for ua-name and ua-product included semi-colon, which could
not be distinguished from *text in the production. The ua-name was not be distinguished from *text in the production. The ua-name was
restricted to not include semi-colon. Semi-colon can still appear in restricted to not include semi-colon. Semi-colon can still appear in
the ua-product. the ua-product.
The ABNF did not indicate all places that whitespace was allowable, The ABNF did not indicate all places that whitespace was allowable,
in particular folding whitespace, although all implementations allow in particular folding whitespace, although all implementations allow
whitespace and folding in the header fields just like any other whitespace and folding in the header fields just like any other
RFC5322 [RFC5322]-formatted header field. There were also a number RFC5322 [RFC5322]-formatted header field. There were also a number
 End of changes. 25 change blocks. 
57 lines changed or deleted 62 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/