draft-ietf-appsawg-mdn-3798bis-15.txt   draft-ietf-appsawg-mdn-3798bis-16.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 20, 2016 Intended status: Standards Track December 1, 2016
Expires: April 23, 2017 Expires: June 4, 2017
Message Disposition Notification Message Disposition Notification
draft-ietf-appsawg-mdn-3798bis-15.txt draft-ietf-appsawg-mdn-3798bis-16.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 23, 2017. This Internet-Draft will expire on June 4, 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 10, line 35 skipping to change at page 10, line 35
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,
encrypted message text MUST be returned, if it is returned at if the original message or a portion thereof is returned, it MUST
all, only in its original encrypted form. be in its original encrypted form.
NOTE: For message disposition notifications gatewayed from foreign NOTE: For message disposition notifications gatewayed from foreign
systems, the header fields of the original message may not be systems, the header fields of the original message may not be
available. In this case, the third component of the MDN may be available. In this case, the third component of the MDN may be
omitted, or it may contain "simulated" RFC-MSGFMT [RFC5322] header omitted, or it may contain "simulated" RFC-MSGFMT [RFC5322] header
fields that contain equivalent information. In particular, it is fields that contain equivalent information. In particular, it is
very desirable to preserve the subject and date fields from the very desirable to preserve the subject and date fields from the
original message. original message.
The MDN MUST be addressed (in both the message header field and the The MDN MUST be addressed (in both the message header field and the
skipping to change at page 12, line 31 skipping to change at page 12, line 31
File extension(s): .disposition-notification File extension(s): .disposition-notification
Macintosh file type code(s): The 'TEXT' type Macintosh file type code(s): The 'TEXT' type
code is suggested as files of this type are code is suggested as files of this type are
typically used for diagnostic purposes and typically used for diagnostic purposes and
suitable for analysis in a text editor. A suitable for analysis in a text editor. A
uniform type identifier (UTI) of "public.utf8- uniform type identifier (UTI) of "public.utf8-
email-message-header" is suggested. This type email-message-header" is suggested. This type
conforms to "public.plain-text". conforms to "public.plain-text".
Person & email address to contact for further information: See the Person & email address to contact for further information: ART Area
Authors' Addresses section of [RFCXXXX] Mailing List <art@ietf.org>
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: This media type contains textual data in the Restrictions on usage: This media type contains textual data in the
US-ASCII charset, which is always 7-bit. US-ASCII charset, which is always 7-bit.
Author: See the Authors' Addresses section of [RFCXXXX] Author: See the Authors' Addresses section of [RFCXXXX]
Change controller: IETF Change controller: IETF
skipping to change at page 25, line 23 skipping to change at page 25, line 23
to try all potential holes regardless of the apparent software to try all potential holes regardless of the apparent software
versions being used. Also note that the "Reporting-UA" field doesn't versions being used. Also note that the "Reporting-UA" field doesn't
provide any new information in comparison to the "User-Agent" and/or provide any new information in comparison to the "User-Agent" and/or
(undocumented) "X-Mailer" header fields used by many MUAs. (undocumented) "X-Mailer" header fields used by many MUAs.
6.2.2. MUA Fingerprinting 6.2.2. MUA Fingerprinting
The "Reporting-UA" field (Section 3.2.1) might contain enough The "Reporting-UA" field (Section 3.2.1) might contain enough
information to uniquely identify a specific device, usually when information to uniquely identify a specific device, usually when
combined with other characteristics, particularly if the user agent combined with other characteristics, particularly if the user agent
sends excessive details about the user's system or extensions. sends excessive details about the user's system or extensions. Even
However, the source of unique information that is least expected by when the guidance in Section 3.2.1 is followed to avoid
users is proactive negotiation, including the Accept-Language header fingerprinting, other sources of unique information may still be
fields. present, such as 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.
skipping to change at page 25, line 49 skipping to change at page 25, line 49
SERVICES [RFC2634]. SERVICES [RFC2634].
6.4. Mail Bombing 6.4. Mail Bombing
The MDN request mechanism introduces an additional way of mailbombing The MDN request mechanism introduces an additional way of mailbombing
a mailbox. The MDN request notification provides an address to which a mailbox. The MDN request notification provides an address to which
MDN's should be sent. It is possible for an attacking agent to send MDN's should be sent. It is possible for an attacking agent to send
a potentially large set of messages to otherwise unsuspecting third a potentially large set of messages to otherwise unsuspecting third
party recipients with a false "disposition-notification-to:" address. party recipients with a false "disposition-notification-to:" address.
Automatic, or simplistic processing of such requests would result in Automatic, or simplistic processing of such requests would result in
a flood of MDN notifications to the target of the attack. Such an a flood of MDN notifications to the target of the attack.
attack could overrun the capacity of the targeted mailbox and deny Additionally, as generated MDN notifications can include full content
service. of messages that caused them and thus they can be bigger than such
messages, they can be used for bandwidth amplification attacks. Such
an attack could overrun the storage capacity of the targeted mailbox
and/or of the mail transport system, and deny service.
For that reason, MDN's SHOULD NOT be sent automatically where the For that reason, MDN's SHOULD NOT be sent automatically where the
"disposition-notification-to:" address is different from the SMTP "disposition-notification-to:" address is different from the SMTP
"MAIL FROM" address (which is carried in the Return-Path header "MAIL FROM" address (which is carried in the Return-Path header
field). See Section 2.1 for further discussion. field). See Section 2.1 for further discussion.
7. Collected ABNF Grammar 7. Collected ABNF Grammar
NOTE: The following lexical tokens are defined in RFC-MSGFMT NOTE: The following lexical tokens are defined in RFC-MSGFMT
[RFC5322]: CRLF, FWS, CFWS, field-name, mailbox-list, msg-id, text, [RFC5322]: CRLF, FWS, CFWS, field-name, mailbox-list, msg-id, text,
skipping to change at page 33, line 39 skipping to change at page 33, line 39
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, Ben The contributions of Bruce Lilly, Alfred Hoenes, Barry Leiba, Ben
Campbell and Pete Resnick are gratefully acknowledged for this Campbell, Pete Resnick, Donald Eastlake and Alissa Cooper are
revision. 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,
 End of changes. 8 change blocks. 
17 lines changed or deleted 20 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/