draft-ietf-appsawg-mdn-3798bis-14.txt   draft-ietf-appsawg-mdn-3798bis-15.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 October 16, 2016 Intended status: Standards Track October 20, 2016
Expires: April 19, 2017 Expires: April 23, 2017
Message Disposition Notification Message Disposition Notification
draft-ietf-appsawg-mdn-3798bis-14.txt draft-ietf-appsawg-mdn-3798bis-15.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 2, line 10 skipping to change at page 2, line 10
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 April 19, 2017. This Internet-Draft will expire on April 23, 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 2, line 41 skipping to change at page 2, line 41
1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requesting Message Disposition Notifications . . . . . . . . 5 2. Requesting Message Disposition Notifications . . . . . . . . 5
2.1. The Disposition-Notification-To Header . . . . . . . . . 5 2.1. The Disposition-Notification-To Header . . . . . . . . . 5
2.2. The Disposition-Notification-Options Header . . . . . . . 7 2.2. The Disposition-Notification-Options Header . . . . . . . 7
2.3. The Original-Recipient Header Field . . . . . . . . . . . 8 2.3. The Original-Recipient Header Field . . . . . . . . . . . 8
2.4. Use with the Message/Partial Media Type . . . . . . . . . 9 2.4. Use with the Message/Partial Media Type . . . . . . . . . 9
3. Format of a Message Disposition Notification . . . . . . . . 10 3. Format of a Message Disposition Notification . . . . . . . . 10
3.1. The message/disposition-notification Media Type . . . . . 11 3.1. The message/disposition-notification Media Type . . . . . 11
3.2. Message/disposition-notification Content Fields . . . . . 14 3.2. Message/disposition-notification Content Fields . . . . . 14
3.3. Extension-fields . . . . . . . . . . . . . . . . . . . . 20 3.3. Extension-fields . . . . . . . . . . . . . . . . . . . . 21
4. Timeline of events . . . . . . . . . . . . . . . . . . . . . 20 4. Timeline of events . . . . . . . . . . . . . . . . . . . . . 21
5. Conformance and Usage Requirements . . . . . . . . . . . . . 22 5. Conformance and Usage Requirements . . . . . . . . . . . . . 22
6. Security Considerations . . . . . . . . . . . . . . . . . . . 22 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23
6.1. Forgery . . . . . . . . . . . . . . . . . . . . . . . . . 23 6.1. Forgery . . . . . . . . . . . . . . . . . . . . . . . . . 23
6.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 23 6.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.3. Non-Repudiation . . . . . . . . . . . . . . . . . . . . . 24 6.2.1. Disclosure of Product Information . . . . . . . . . . 25
6.4. Mail Bombing . . . . . . . . . . . . . . . . . . . . . . 24 6.2.2. MUA Fingerprinting . . . . . . . . . . . . . . . . . 25
7. Collected ABNF Grammar . . . . . . . . . . . . . . . . . . . 24 6.3. Non-Repudiation . . . . . . . . . . . . . . . . . . . . . 25
8. Guidelines for Gatewaying MDNs . . . . . . . . . . . . . . . 27 6.4. Mail Bombing . . . . . . . . . . . . . . . . . . . . . . 25
8.1. Gatewaying from other mail systems to MDNs . . . . . . . 27 7. Collected ABNF Grammar . . . . . . . . . . . . . . . . . . . 26
8.2. Gatewaying from MDNs to other mail systems . . . . . . . 27 8. Guidelines for Gatewaying MDNs . . . . . . . . . . . . . . . 28
8.3. Gatewaying of MDN-requests to other mail systems . . . . 28 8.1. Gatewaying from other mail systems to MDNs . . . . . . . 28
9. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 8.2. Gatewaying from MDNs to other mail systems . . . . . . . 29
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 8.3. Gatewaying of MDN-requests to other mail systems . . . . 29
9. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
10.1. Disposition-Notification-Options header field 10.1. Disposition-Notification-Options header field
disposition-notification-parameter names . . . . . . . . 30 disposition-notification-parameter names . . . . . . . . 32
10.2. Disposition modifier names . . . . . . . . . . . . . . . 31 10.2. Disposition modifier names . . . . . . . . . . . . . . . 33
10.3. MDN extension field names . . . . . . . . . . . . . . . 31 10.3. MDN extension field names . . . . . . . . . . . . . . . 33
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
12.1. Normative References . . . . . . . . . . . . . . . . . . 32 12.1. Normative References . . . . . . . . . . . . . . . . . . 34
12.2. Informative References . . . . . . . . . . . . . . . . . 33 12.2. Informative References . . . . . . . . . . . . . . . . . 35
Appendix A. Changes from RFC 3798 . . . . . . . . . . . . . . . 34 Appendix A. Changes from RFC 3798 . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
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
skipping to change at page 15, line 9 skipping to change at page 15, line 9
text-no-semi = %d1-9 / ; "text" characters excluding NUL, CR, text-no-semi = %d1-9 / ; "text" characters excluding NUL, CR,
%d11 / %d12 / %d14-58 / %d60-127 ; LF, or semi-colon %d11 / %d12 / %d14-58 / %d60-127 ; LF, or semi-colon
The Reporting-UA field is defined as follows: The Reporting-UA field is defined as follows:
An MDN describes the disposition of a message after it has been An MDN describes the disposition of a message after it has been
delivered to a recipient. In all cases, the Reporting-UA is the MUA delivered to a recipient. In all cases, the Reporting-UA is the MUA
that performed the disposition described in the MDN. that performed the disposition described in the MDN.
The "Reporting-UA" field contains information about the MUA that
generated the MDN, which is often used by servers to help identify
the scope of reported interoperability problems, to work around or
tailor responses to avoid particular MUA limitations, and for
analytics regarding MUA or operating system use. A MUA SHOULD send a
"Reporting-UA" field unless specifically configured not to do so.
If the reporting MUA consists of more than one component (e.g., a If the reporting MUA consists of more than one component (e.g., a
base program and plug-ins), this may be indicated by including a list base program and plug-ins), this may be indicated by including a list
of product names. of product names.
A reporting MUA SHOULD limit generated product identifiers to what is
necessary to identify the product; a sender MUST NOT generate
advertising or other nonessential information within the product
identifier.
A reporting MUA SHOULD NOT generate a "Reporting-UA" field containing
needlessly fine-grained detail and SHOULD limit the addition of
subproducts by third parties. Overly long and detailed "Reporting-
UA" field values increase the risk of a user being identified against
their wishes ("fingerprinting").
Likewise, implementations are encouraged not to use the product
tokens of other implementations in order to declare compatibility
with them, as this circumvents the purpose of the field. If a MUA
masquerades as a different MUA, recipients can assume that the user
intentionally desires to see responses tailored for that identified
MUA, even if they might not work as well for the actual MUA being
used.
Example: Example:
Reporting-UA: Foomail 97.1 Reporting-UA: Foomail 97.1
This field is optional, but recommended.
3.2.2. The MDN-Gateway field 3.2.2. The MDN-Gateway field
The MDN-Gateway field indicates the name of the gateway or MTA that The MDN-Gateway field indicates the name of the gateway or MTA that
translated a foreign (non-Internet) message disposition notification translated a foreign (non-Internet) message disposition notification
into this MDN. This field MUST appear in any MDN that was translated into this MDN. This field MUST appear in any MDN that was translated
by a gateway from a foreign system into MDN format, and MUST NOT by a gateway from a foreign system into MDN format, and MUST NOT
appear otherwise. appear otherwise.
mdn-gateway-field = "MDN-Gateway" ":" OWS mta-name-type OWS ";" OWS mta-name OWS mdn-gateway-field = "MDN-Gateway" ":" OWS mta-name-type OWS ";" OWS mta-name OWS
skipping to change at page 16, line 30 skipping to change at page 17, line 5
3.2.4. Final-Recipient field 3.2.4. Final-Recipient field
The Final-Recipient field indicates the recipient for which the MDN The Final-Recipient field indicates the recipient for which the MDN
is being issued. This field MUST be present. is being issued. This field MUST be present.
The syntax of the field is as follows: The syntax of the field is as follows:
final-recipient-field = final-recipient-field =
"Final-Recipient" ":" OWS address-type OWS ";" OWS generic-address OWS "Final-Recipient" ":" OWS address-type OWS ";" OWS generic-address OWS
The generic-address subfield of the Final-Recipient field MUST The generic-address subfield of the Final-Recipient field SHOULD
contain the mailbox address of the recipient (from the From header contain the mailbox address of the recipient (which will be the same
field of the MDN) as it was when the MDN was generated by the MUA. as the From header field of the MDN) as it was when the MDN was
generated by the MUA.
One example of when this field might not contain the final
recipient address of the message is when an alias (e.g. "customer-
support@example.com") forwards mail to a specific personal address
(e.g. "bob@example.com"). Bob might want to be able to send MDNs,
but not give away his personal email address. In this case the
Final-Recipient field can be "customer-support@example.com"
instead of "bob@example.com".
The Final-Recipient address may differ from the address originally The Final-Recipient address may differ from the address originally
provided by the sender, because it may have been transformed during provided by the sender, because it may have been transformed during
forwarding and gatewaying into a totally unrecognizable mess. forwarding and gatewaying into a totally unrecognizable mess.
However, in the absence of the optional Original-Recipient field, the However, in the absence of the optional Original-Recipient field, the
Final-Recipient field and any returned content may be the only Final-Recipient field and any returned content may be the only
information available with which to correlate the MDN with a information available with which to correlate the MDN with a
particular message recipient. particular message recipient.
The address-type subfield indicates the type of address expected by The address-type subfield indicates the type of address expected by
skipping to change at page 23, line 31 skipping to change at page 24, line 21
Disposition-Notification-To header field that can trick the recipient Disposition-Notification-To header field that can trick the recipient
to send an MDN. MDN processing should only be invoked once to send an MDN. MDN processing should only be invoked once
authenticity of email message is verified. authenticity of email message is verified.
6.2. Privacy 6.2. Privacy
Another dimension of security is privacy. There may be cases in Another dimension of security is privacy. There may be cases in
which a message recipient does not wish the disposition of messages which a message recipient does not wish the disposition of messages
addressed to him to be known, or is concerned that the sending of addressed to him to be known, or is concerned that the sending of
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, using which email client, which OS was used). In this
silently ignore requests for MDNs. situation, it is acceptable for the MUA to 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, as well as content of the message/disposition-notification report, as well as content of the message/disposition-notification
part could reveal confidential information about host names and/or part could reveal confidential information about host names and/or
network topology inside a firewall. network topology inside a firewall.
skipping to change at page 24, line 18 skipping to change at page 25, line 7
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
address. This risk can be minimized by not sending MDN's address. This risk can be minimized by not sending MDN's
automatically. automatically.
6.2.1. Disclosure of Product Information
The "Reporting-UA" field (Section 3.2.1) User-Agent (Section 5.5.3)
and 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.
However, the source of unique information that is least expected by
users is proactive negotiation, including the Accept-Language header
fields.
6.3. Non-Repudiation 6.3. Non-Repudiation
MDNs do not provide non-repudiation with proof of delivery. Within MDNs do not provide non-repudiation with proof of delivery. Within
the framework of today's Internet Mail, the MDNs defined in this the framework of today's Internet Mail, the MDNs defined in this
document provide valuable information to the mail user; however, MDNs document provide valuable information to the mail user; however, MDNs
cannot be relied upon as a guarantee that a message was or was not 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 seen by the recipient. Even if MDNs are not actively forged, they
may be lost in transit. The recipient may bypass the MDN issuing may be lost in transit. The recipient may bypass the MDN issuing
mechanism in some manner. mechanism in some manner.
 End of changes. 13 change blocks. 
33 lines changed or deleted 90 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/