draft-ietf-appsawg-mdn-3798bis-12.txt   draft-ietf-appsawg-mdn-3798bis-13.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 12, 2016 Intended status: Standards Track October 16, 2016
Expires: February 13, 2017 Expires: April 19, 2017
Message Disposition Notification Message Disposition Notification
draft-ietf-appsawg-mdn-3798bis-12.txt draft-ietf-appsawg-mdn-3798bis-13.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. This document obsoletes RFC 3798, moving it to Internet Standard. It
also updates RFC 2046 (message/partial Media Type handling) and RFC
3461 (Original-Recipient header field generation requirement).
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 13, 2017. This Internet-Draft will expire on April 19, 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 6, line 9 skipping to change at page 6, line 9
dispositions might be generated for the same recipient. User agents dispositions might be generated for the same recipient. User agents
SHOULD leverage 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 user might
obtaining user's consent is to protect user's privacy. The default also indicate globally that MDNs are to never be sent. The purpose
value should be not to send MDNs. of obtaining user's consent is to protect user's privacy. The
default value should be 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
skipping to change at page 15, line 17 skipping to change at page 15, line 17
ua-product = *([FWS] text) ua-product = *([FWS] text)
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. This field is that performed the disposition described in the MDN.
optional, but recommended. For Internet Mail user agents, it is
recommended that this field contain both: the DNS name of the
particular instance of the MUA that generated the MDN, and the name
of the product. For example,
Reporting-UA: pc.example.com; Foomail 97.1
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.
Example:
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 20, line 19 skipping to change at page 20, line 19
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
for the recipient doing the forwarding and the recipient of the for the recipient doing the forwarding and the recipient of the
forwarded message may also cause an MDN to be generated. forwarded message may also cause an MDN to be generated.
3.2.7. Failure and Error Fields 3.2.7. Error Field
The Failure and Error fields are used to supply additional
information in the form of text messages when the "error" disposition
modifier appear. The syntax is as follows:
failure-field = "Failure" ":" *([FWS] text) The Error field is used to supply additional information in the form
of text messages when the "error" disposition modifier appear. The
syntax is as follows:
error-field = "Error" ":" *([FWS] text) error-field = "Error" ":" *([FWS] text)
Note that syntax of these header fields doesn't include comments, so Note that syntax of these header fields doesn't include comments, so
"encoded-word" construct defined in RFC-MIME-HEADER [RFC2047] can't "encoded-word" construct defined in RFC-MIME-HEADER [RFC2047] can't
be used to convey non ASCII text. Application that need to convey be used to convey non ASCII text. Application that need to convey
non ASCII text in these fields should consider implementing message/ non ASCII text in these fields should consider implementing message/
global-disposition-notification media type specified in [RFC6533] global-disposition-notification media type specified in [RFC6533]
instead of this specification. instead of this specification.
skipping to change at page 23, line 33 skipping to change at page 23, line 30
make automatic use of MDNs should take appropriate precautions to make automatic use of MDNs should take appropriate precautions to
minimize the potential damage from denial-of-service attacks. minimize the potential damage from denial-of-service attacks.
Security threats related to forged MDNs include the sending of: Security threats related to forged MDNs include the sending of:
a. A falsified disposition notification when the indicated a. A falsified disposition notification when the indicated
disposition of the message has not actually occurred, disposition of the message has not actually occurred,
b. Unsolicited MDNs b. Unsolicited MDNs
Similarly, a forged spam or phishing email message can contain
Disposition-Notification-To header field that can trick the recipient
to send an MDN. MDN processing should only be invoked once
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). 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
skipping to change at page 24, line 21 skipping to change at page 24, line 23
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
address along with a source route. The source route is ignored in address. This risk can be minimized by not sending MDN's
the comparison so the addresses will always match. But if the source automatically.
route is honored when the notification is sent, it could direct the
message to some other destination. This risk can be minimized by not
sending MDN's automatically.
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.
skipping to change at page 27, line 15 skipping to change at page 27, line 15
sending-mode = "MDN-sent-manually" / "MDN-sent-automatically" sending-mode = "MDN-sent-manually" / "MDN-sent-automatically"
disposition-type = "displayed" / "deleted" / "dispatched" / disposition-type = "displayed" / "deleted" / "dispatched" /
"processed" "processed"
disposition-modifier = "error" / disposition-modifier-extension disposition-modifier = "error" / disposition-modifier-extension
disposition-modifier-extension = atom disposition-modifier-extension = atom
failure-field = "Failure" ":" *([FWS] text)
error-field = "Error" ":" *([FWS] text) error-field = "Error" ":" *([FWS] text)
extension-field = extension-field-name ":" *([FWS] text) extension-field = extension-field-name ":" *([FWS] text)
extension-field-name = field-name extension-field-name = field-name
8. Guidelines for Gatewaying MDNs 8. Guidelines for Gatewaying MDNs
NOTE: This section provides non-binding recommendations for the NOTE: This section provides non-binding recommendations for the
construction of mail gateways that wish to provide semi-transparent construction of mail gateways that wish to provide semi-transparent
skipping to change at page 35, line 21 skipping to change at page 35, line 21
notification. notification.
"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.
Removed discussion of using source routes with MDNs, as source route
is a deprecated Email feature.
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". (Erratum #691) 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. (Erratum #692) 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.
Removed recommendation to include the MUA DNS host name in the
"Reporting-UA" MDN field.
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
of places in the ABNF that inconsistently permitted comments and of places in the ABNF that inconsistently permitted comments and
whitespace in one leg of the production and not another. The ABNF whitespace in one leg of the production and not another. The ABNF
now specifies FWS and CFWS in several places that should have already now specifies FWS and CFWS in several places that should have already
been specified by the grammar. been specified by the grammar.
Extension-field was defined in the collected grammar but not in the Extension-field was defined in the collected grammar but not in the
 End of changes. 14 change blocks. 
28 lines changed or deleted 35 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/