draft-ietf-appsawg-mdn-3798bis-05.txt   draft-ietf-appsawg-mdn-3798bis-06.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.
Intended status: Standards Track Isode Ltd Intended status: Standards Track Isode Ltd
Expires: June 4, 2016 December 2, 2015 Expires: July 27, 2016 January 24, 2016
Message Disposition Notification Message Disposition Notification
draft-ietf-appsawg-mdn-3798bis-05.txt draft-ietf-appsawg-mdn-3798bis-06.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 4 skipping to change at page 2, line 4
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 June 4, 2016. This Internet-Draft will expire on July 27, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 43 skipping to change at page 2, line 43
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Purposes . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Purposes . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
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 Content Type . . . . . . . . 8 2.4. Use with the Message/Partial Content Type . . . . . . . . 9
3. Format of a Message Disposition Notification . . . . . . . . 9 3. Format of a Message Disposition Notification . . . . . . . . 9
3.1. The message/disposition-notification content-type . . . . 10 3.1. The message/disposition-notification content-type . . . . 11
3.2. Message/disposition-notification Fields . . . . . . . . . 12 3.2. Message/disposition-notification Fields . . . . . . . . . 13
3.3. Extension-fields . . . . . . . . . . . . . . . . . . . . 18 3.3. Extension-fields . . . . . . . . . . . . . . . . . . . . 18
4. Timeline of events . . . . . . . . . . . . . . . . . . . . . 18 4. Timeline of events . . . . . . . . . . . . . . . . . . . . . 19
5. Conformance and Usage Requirements . . . . . . . . . . . . . 19 5. Conformance and Usage Requirements . . . . . . . . . . . . . 20
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
6.1. Forgery . . . . . . . . . . . . . . . . . . . . . . . . . 20 6.1. Forgery . . . . . . . . . . . . . . . . . . . . . . . . . 21
6.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 20 6.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 21
6.3. Non-Repudiation . . . . . . . . . . . . . . . . . . . . . 21 6.3. Non-Repudiation . . . . . . . . . . . . . . . . . . . . . 22
6.4. Mail Bombing . . . . . . . . . . . . . . . . . . . . . . 22 6.4. Mail Bombing . . . . . . . . . . . . . . . . . . . . . . 22
7. Collected ABNF Grammar . . . . . . . . . . . . . . . . . . . 22 7. Collected ABNF Grammar . . . . . . . . . . . . . . . . . . . 22
8. Guidelines for Gatewaying MDNs . . . . . . . . . . . . . . . 24 8. Guidelines for Gatewaying MDNs . . . . . . . . . . . . . . . 24
8.1. Gatewaying from other mail systems to MDNs . . . . . . . 24 8.1. Gatewaying from other mail systems to MDNs . . . . . . . 24
8.2. Gatewaying from MDNs to other mail systems . . . . . . . 24 8.2. Gatewaying from MDNs to other mail systems . . . . . . . 25
8.3. Gatewaying of MDN-requests to other mail systems . . . . 25 8.3. Gatewaying of MDN-requests to other mail systems . . . . 25
9. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 9. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
10.1. Disposition-Notification-Options header field 10.1. Disposition-Notification-Options header field
disposition-notification-parameter names . . . . . . . . 27 disposition-notification-parameter names . . . . . . . . 28
10.2. Disposition modifier names . . . . . . . . . . . . . . . 27 10.2. Disposition modifier names . . . . . . . . . . . . . . . 28
10.3. MDN extension field names . . . . . . . . . . . . . . . 28 10.3. MDN extension field names . . . . . . . . . . . . . . . 28
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
12.1. Normative References . . . . . . . . . . . . . . . . . . 28 12.1. Normative References . . . . . . . . . . . . . . . . . . 29
12.2. Informative References . . . . . . . . . . . . . . . . . 29 12.2. Informative References . . . . . . . . . . . . . . . . . 30
Appendix A. Changes from RFC 3798 . . . . . . . . . . . . . . . 30 Appendix A. Changes from RFC 3798 . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction 1. Introduction
This memo defines a RFC-MIME-MEDIA [4] content-type for message This memo defines a RFC-MIME-MEDIA [4] content-type for message
disposition notifications (MDNs). An MDN can be used to notify the disposition notifications (MDNs). An MDN can be used to notify the
sender of a message of any of several conditions that may occur after sender of a message of any of several conditions that may occur after
successful delivery, such as display of the message contents, successful delivery, such as display of the message contents,
printing of the message, deletion (without display) of the message, printing of the message, deletion (without display) of the message,
or the recipient's refusal to provide MDNs. The "message/ or the recipient's refusal to provide MDNs. The "message/
disposition-notification" content-type defined herein is intended for disposition-notification" content-type defined herein is intended for
skipping to change at page 5, line 33 skipping to change at page 5, line 33
Disposition-Notification-Options header fields in the message. Disposition-Notification-Options header fields in the message.
2.1. The Disposition-Notification-To Header 2.1. The Disposition-Notification-To Header
A request for the receiving user agent to issue message disposition A request for the receiving user agent to issue message disposition
notifications is made by placing a Disposition-Notification-To header notifications is made by placing a Disposition-Notification-To header
field into the message. The syntax of the header field is field into the message. The syntax of the header field is
mdn-request-header = "Disposition-Notification-To" ":" mailbox-list CRLF mdn-request-header = "Disposition-Notification-To" ":" mailbox-list CRLF
A Disposition-Notification-To header field can appear at most once in
a message.
The presence of a Disposition-Notification-To header field in a The presence of a Disposition-Notification-To header field in a
message is merely a request for an MDN. The recipients' user agents message is merely a request for an MDN. The recipients' user agents
are always free to silently ignore such a request. are always free to silently ignore such a request.
An MDN MUST NOT itself have a Disposition-Notification-To header An MDN MUST NOT itself have a Disposition-Notification-To header
field. An MDN MUST NOT be generated in response to an MDN. field. An MDN MUST NOT be generated in response to an MDN.
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
skipping to change at page 6, line 5 skipping to change at page 6, line 10
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 laverage 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 [13], it SHOULD user agent is accessing the message using RFC-IMAP [12], it SHOULD
implement the procedures specified in RFC-IMAP-MDN [10]. implement the procedures specified in RFC-IMAP-MDN [10].
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. globally through the user's setting of a preference.
MDNs SHOULD NOT be sent automatically if the address in the MDNs SHOULD 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
skipping to change at page 6, line 36 skipping to change at page 6, line 41
The comparison of the addresses should be done using only the addr- The comparison of the addresses should be done using only the addr-
spec (local-part "@" domain) portion, excluding any angle brackets, spec (local-part "@" domain) portion, excluding any angle brackets,
phrase and route. The comparison MUST be case-sensitive for the phrase and route. The comparison MUST be case-sensitive for the
local-part and case-insensitive for the domain part. The local-part local-part and case-insensitive for the domain part. The local-part
comparison SHOULD be done after performing local-part comparison SHOULD be done after performing local-part
canonicalization (i.e. after removing the surrounding double-quote canonicalization (i.e. after removing the surrounding double-quote
characters, if any, as well as any escaping "\" characters. (See characters, if any, as well as any escaping "\" characters. (See
RFC-MSGFMT [2] for more details.) Implementations MAY treat known RFC-MSGFMT [2] for more details.) Implementations MAY treat known
domain aliases as equivalent for the purpose of comparison. domain aliases as equivalent for the purpose of comparison.
Note that use of subaddressing (see [12]) can result in a failure to Note that use of subaddressing (see [13]) can result in a failure to
match two local-parts and thus result in possible suppression of the match two local-parts and thus result in possible suppression of the
MDN. This document doesn't recommend special handling for this case, MDN. This document doesn't recommend special handling for this case,
as the receiving MUA can't reliably know whether or not the sender is as the receiving MUA can't reliably know whether or not the sender is
using subaddressing. using subaddressing.
If the message contains more than one Return-Path header field, the If the message contains more than one Return-Path header field, the
implementation may pick one to use for the comparison, or treat the implementation may pick one to use for the comparison, or treat the
situation as a failure of the comparison. situation as a failure of the comparison.
The reason for not automatically sending an MDN if the comparison The reason for not automatically sending an MDN if the comparison
skipping to change at page 7, line 28 skipping to change at page 7, line 35
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.
Messages posted to newsgroups SHOULD NOT have a Disposition- Messages posted to newsgroups SHOULD NOT have a Disposition-
Notification-To header field. Notification-To header field.
2.2. The Disposition-Notification-Options Header 2.2. The Disposition-Notification-Options Header
Future extensions to this specification may require that information Extensions to this specification may require that information be
be supplied to the recipient's MUA for additional control over how supplied to the recipient's MUA for additional control over how and
and what MDNs are generated. The Disposition-Notification-Options what MDNs are generated. The Disposition-Notification-Options header
header field provides an extensible mechanism for such information. field provides an extensible mechanism for such information. The
The syntax of this header field is as follows: syntax of this header field is as follows:
Disposition-Notification-Options = Disposition-Notification-Options =
"Disposition-Notification-Options" ":" [FWS] "Disposition-Notification-Options" ":" [FWS]
disposition-notification-parameter-list disposition-notification-parameter-list CRLF
disposition-notification-parameter-list = disposition-notification-parameter-list =
disposition-notification-parameter disposition-notification-parameter
*([FWS] ";" [FWS] disposition-notification-parameter) *([FWS] ";" [FWS] disposition-notification-parameter)
disposition-notification-parameter = attribute [FWS] "=" disposition-notification-parameter = attribute [FWS] "="
[FWS] importance [FWS] "," [FWS] value *([FWS] "," [FWS] value) [FWS] importance [FWS] "," [FWS] value *([FWS] "," [FWS] value)
importance = "required" / "optional" importance = "required" / "optional"
attribute = atom attribute = atom
value = word value = word
A Disposition-Notification-Options header field can appear at most
once in a message.
An importance of "required" indicates that interpretation of the An importance of "required" indicates that interpretation of the
disposition-notification-parameter is necessary for proper generation disposition-notification-parameter is necessary for proper generation
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 beginning with "X-" will never notification-parameter attribute names beginning with "X-" will never
be defined as standard names; such names are reserved for be defined as standard names; such names are reserved for
experimental use. disposition-notification-parameter attribute names experimental use. disposition-notification-parameter attribute names
not beginning with "X-" MUST be registered with the Internet Assigned not beginning with "X-" MUST be registered with the Internet Assigned
Numbers Authority (IANA) and described in a standards-track RFC or an Numbers Authority (IANA) using "Specification required" registration
experimental RFC approved by the IESG. [[ more work needed here ]] policy.
(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 MTA. The delivering MTA may be able made available by the delivering MTA. The delivering MTA may be able
to obtain this information from the ORCPT parameter of the SMTP RCPT to obtain this information from the ORCPT parameter of the SMTP RCPT
TO command, as defined in RFC-SMTP [1] and RFC-DSN-SMTP [7]. TO command, as defined in RFC-SMTP [1] and RFC-DSN-SMTP [7].
RFC-DSN-SMTP [7] is amended as follows: If the ORCPT information is RFC-DSN-SMTP [7] is amended as follows: If the ORCPT information is
available, the delivering MTA SHOULD insert an Original-Recipient available, the delivering MTA SHOULD insert an Original-Recipient
header field at the beginning of the message (along with the Return- header field at the beginning of the message (along with the Return-
Path header field). The delivering MTA MAY delete any other Path header field). The delivering MTA MAY delete any other
Original-Recipient header fields that occur in the message. The Original-Recipient header fields that occur in the message. The
syntax of this header field is as follows: syntax of this header field is as follows:
original-recipient-header = original-recipient-header =
"Original-Recipient" ":" [FWS] address-type [FWS] ";" [FWS] generic-address "Original-Recipient" ":" OWS address-type OWS ";" OWS generic-address OWS
OWS = [CFWS]
; Optional whitespace.
; MDN generators SHOULD use "*WSP"
; (typically a single space or nothing.
; It SHOULD be nothing at the end of a field),
; unless an RFC 5322 "comment" is required.
;
; MDN parsers MUST parse it as "[CFWS]".
The address-type and generic-address token are as specified in the The address-type and generic-address token are as specified in the
description of the Original-Recipient field in Section 3.2.3. description of the Original-Recipient field in Section 3.2.3.
The purpose of carrying the original recipient information and The purpose of carrying the original recipient information and
returning it in the MDN is to permit automatic correlation of MDNs returning it in the MDN is to permit automatic correlation of MDNs
with the original message on a per-recipient basis. with the original message on a per-recipient basis.
2.4. Use with the Message/Partial Content Type 2.4. Use with the Message/Partial Content Type
skipping to change at page 11, line 43 skipping to change at page 12, line 14
3.1.1. General conventions for fields 3.1.1. General conventions for fields
Since these fields are defined according to the rules of RFC-MSGFMT Since these fields are defined according to the rules of RFC-MSGFMT
[2], the same conventions for continuation lines and comments apply. [2], the same conventions for continuation lines and comments apply.
Notification fields may be continued onto multiple lines by beginning Notification fields may be continued onto multiple lines by beginning
each additional line with a SPACE or HTAB. Text that appears in each additional line with a SPACE or HTAB. Text that appears in
parentheses is considered a comment and not part of the contents of parentheses is considered a comment and not part of the contents of
that notification field. Field names are case-insensitive, so the that notification field. Field names are case-insensitive, so the
names of notification fields may be spelled in any combination of names of notification fields may be spelled in any combination of
upper and lower case letters. Comments in notification fields may upper and lower case letters. [2] comments in notification fields
use the "encoded-word" construct defined in RFC-MIME-HEADER [5]. may use the "encoded-word" construct defined in RFC-MIME-HEADER [5].
3.1.2. "*-type" subfields 3.1.2. "*-type" subfields
Several fields consist of a "-type" subfield, followed by a semi- Several fields consist of a "-type" subfield, followed by a semi-
colon, followed by "*text". colon, followed by "*text".
For these fields, the keyword used in the address-type or MTA-type For these fields, the keyword used in the address-type or MTA-type
subfield indicates the expected format of the address or MTA-name subfield indicates the expected format of the address or MTA-name
that follows. that follows.
The "-type" subfields are defined as follows: The "-type" subfields are defined as follows:
skipping to change at page 12, line 39 skipping to change at page 13, line 14
3.2. Message/disposition-notification Fields 3.2. Message/disposition-notification Fields
3.2.1. The Reporting-UA field 3.2.1. The Reporting-UA field
reporting-ua-field = "Reporting-UA" ":" OWS ua-name OWS [ ";" OWS ua-product OWS ] reporting-ua-field = "Reporting-UA" ":" OWS ua-name OWS [ ";" OWS ua-product OWS ]
ua-name = *text-no-semi ua-name = *text-no-semi
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
OWS = *WSP ; generators
/ [CFWS] ; parsers
; Optional whitespace.
; MDN generators SHOULD use "*WSP"
; (typically a single space or nothing.
; It SHOULD be nothing at the end of a field),
; unless an RFC 5322 "comment" is required.
;
; MDN parsers MUST parse it as "[CFWS]".
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. This field is
optional, but recommended. For Internet Mail user agents, it is optional, but recommended. For Internet Mail user agents, it is
recommended that this field contain both: the DNS name of the recommended that this field contain both: the DNS name of the
particular instance of the MUA that generated the MDN, and the name particular instance of the MUA that generated the MDN, and the name
of the product. For example, of the product. For example,
skipping to change at page 17, line 19 skipping to change at page 17, line 28
Only the extension disposition modifiers is defined: Only the extension disposition modifiers is defined:
disposition-modifier-extension disposition-modifier-extension
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. Disposition value names beginning specification. Disposition value names beginning
with "X-" will never be defined as standard with "X-" will never be defined as standard
values; such names are reserved for experimental values; such names are reserved for experimental
use. MDN disposition value names NOT beginning use. MDN disposition value names NOT beginning
with "X-" MUST be registered with the Internet with "X-" MUST be registered with the Internet
Assigned Numbers Authority (IANA) and described Assigned Numbers Authority (IANA) using
in a standards-track RFC or an experimental RFC "Specification required" registration policy.
approved by the IESG. (See Section 10 for a (See Section 10 for a registration form.) MDNs
registration form.) MDNs with disposition with disposition modifier names not understood by
modifier names not understood by the receiving the receiving MUA MAY be silently ignored or
MUA MAY be silently ignored or placed in the placed in the user's mailbox without special
user's mailbox without special interpretation. interpretation. They MUST not cause any error
They MUST not cause any error message to be sent message to be sent to the sender of the MDN.
to the sender of the MDN.
If an MUA developer does not wish to register the meanings of such If an MUA developer does not wish to register the meanings of such
disposition modifier extensions, "X-" modifiers may be used for this disposition modifier extensions, "X-" modifiers may be used for this
purpose. To avoid name collisions, the name of the MUA purpose. To avoid name collisions, the name of the MUA
implementation should follow the "X-", (e.g., "X-Foomail-"). implementation should follow the "X-", (e.g., "X-Foomail-").
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
skipping to change at page 18, line 8 skipping to change at page 18, line 17
3.2.7. Failure and Error Fields 3.2.7. Failure and Error Fields
The Failure and Error fields are used to supply additional The Failure and Error fields are used to supply additional
information in the form of text messages when the "failure" information in the form of text messages when the "failure"
disposition type or "error" disposition modifier appear. The syntax disposition type or "error" disposition modifier appear. The syntax
is as follows: is as follows:
failure-field = "Failure" ":" *([FWS] text) failure-field = "Failure" ":" *([FWS] text)
error-field = "Error" ":" *([FWS] text) error-field = "Error" ":" *([FWS] text)
Note that syntax of these header fields doesn't include comments, so
"encoded-word" construct defined in RFC-MIME-HEADER [5] can't be used
to convey non ASCII text. Application that need to convey non ASCII
text in these fields should consider implementing message/global-
disposition-notification media type specified in [15] instead of this
specification.
3.3. Extension-fields 3.3. Extension-fields
Additional MDN fields may be defined in the future by later revisions Additional MDN fields may be defined in the future by later revisions
or extensions to this specification. Extension-field names beginning or extensions to this specification. Extension-field names beginning
with "X-" will never be defined as standard fields; such names are with "X-" will never be defined as standard fields; such names are
reserved for experimental use. MDN field names NOT beginning with reserved for experimental use. MDN field names NOT beginning with
"X-" MUST be registered with the Internet Assigned Numbers Authority "X-" MUST be registered with the Internet Assigned Numbers Authority
(IANA) and described in a standards-track RFC or an experimental RFC (IANA) using "Specification required" registration policy. (See
approved by the IESG. (See Section 10 for a registration form.) MDN Section 10 for a registration form.) MDN Extension-fields may be
Extension-fields may be defined for the following reasons: defined for the following reasons:
a. To allow additional information from foreign disposition reports a. To allow additional information from foreign disposition reports
to be tunneled through Internet MDNs. The names of such MDN to be tunneled through Internet MDNs. The names of such MDN
fields should begin with an indication of the foreign environment fields should begin with an indication of the foreign environment
name (e.g., X400-Physical-Forwarding-Address). name (e.g., X400-Physical-Forwarding-Address).
b. To allow transmission of diagnostic information that is specific b. To allow transmission of diagnostic information that is specific
to a particular mail user agent (MUA). The names of such MDN to a particular mail user agent (MUA). The names of such MDN
fields should begin with an indication of the MUA implementation fields should begin with an indication of the MUA implementation
that produced the MDN (e.g., Foomail-information). that produced the MDN (e.g., Foomail-information).
skipping to change at page 22, line 32 skipping to change at page 23, line 5
NOTE: The following lexical tokens are defined in RFC-MSGFMT [2]: NOTE: The following lexical tokens are defined in RFC-MSGFMT [2]:
CRLF, FWS, CFWS, field-name, mailbox-list, msg-id, text, comment, CRLF, FWS, CFWS, field-name, mailbox-list, msg-id, text, comment,
word. The following lexical tokens are defined in RFC-SMTP [1]: word. The following lexical tokens are defined in RFC-SMTP [1]:
atom. (Note that RFC-MSGFMT [2] also defines "atom", but the version atom. (Note that RFC-MSGFMT [2] also defines "atom", but the version
from RFC-SMTP [1] is more restrictive and this more restrictive from RFC-SMTP [1] is more restrictive and this more restrictive
version is used in this document.) "encoded-word" construct defined version is used in this document.) "encoded-word" construct defined
in RFC-MIME-HEADER [5] is allowed everywhere where RFC-MSGFMT [2] in RFC-MIME-HEADER [5] is allowed everywhere where RFC-MSGFMT [2]
"comment" is used, for example in CFWS. "comment" is used, for example in CFWS.
OWS = [CFWS]
; Optional whitespace.
; MDN generators SHOULD use "*WSP"
; (typically a single space or nothing.
; It SHOULD be nothing at the end of a field),
; unless an RFC 5322 "comment" is required.
;
; MDN parsers MUST parse it as "[CFWS]".
Message header fields: Message header fields:
mdn-request-header = mdn-request-header =
"Disposition-Notification-To" ":" mailbox-list CRLF "Disposition-Notification-To" ":" mailbox-list CRLF
Disposition-Notification-Options = Disposition-Notification-Options =
"Disposition-Notification-Options" ":" [FWS] "Disposition-Notification-Options" ":" [FWS]
disposition-notification-parameter-list CRLF disposition-notification-parameter-list CRLF
disposition-notification-parameter-list = disposition-notification-parameter-list =
disposition-notification-parameter disposition-notification-parameter
*([FWS] ";" [FWS] disposition-notification-parameter) *([FWS] ";" [FWS] disposition-notification-parameter)
disposition-notification-parameter = attribute [FWS] "=" [FWS] disposition-notification-parameter = attribute [FWS] "=" [FWS]
importance [FWS] "," [FWS] value *([FWS] "," [FWS] value) importance [FWS] "," [FWS] value *([FWS] "," [FWS] value)
importance = "required" / "optional" importance = "required" / "optional"
attribute = atom attribute = atom
value = word value = word
original-recipient-header = original-recipient-header =
"Original-Recipient" ":" [FWS] address-type [FWS] ";" [FWS] generic-address "Original-Recipient" ":" OWS address-type OWS ";" OWS generic-address OWS CRLF
Report content: Report content:
disposition-notification-content = disposition-notification-content =
[ reporting-ua-field CRLF ] [ reporting-ua-field CRLF ]
[ mdn-gateway-field CRLF ] [ mdn-gateway-field CRLF ]
[ original-recipient-field CRLF ] [ original-recipient-field CRLF ]
final-recipient-field CRLF final-recipient-field CRLF
[ original-message-id-field CRLF ] [ original-message-id-field CRLF ]
disposition-field CRLF disposition-field CRLF
*( failure-field CRLF ) *( failure-field CRLF )
*( error-field CRLF ) *( error-field CRLF )
*( extension-field CRLF ) *( extension-field CRLF )
OWS = *WSP ; generators
/ [CFWS] ; parsers
; Optional whitespace.
; MDN generators SHOULD use "*WSP"
; (typically a single space or nothing.
; It SHOULD be nothing at the end of a field),
; unless an RFC 5322 "comment" is required.
;
; MDN parsers MUST parse it as "[CFWS]".
address-type = atom address-type = atom
mta-name-type = atom mta-name-type = atom
reporting-ua-field = "Reporting-UA" ":" OWS ua-name OWS [ ";" OWS ua-product OWS ] reporting-ua-field = "Reporting-UA" ":" OWS ua-name OWS [ ";" OWS ua-product OWS ]
ua-name = *text-no-semi ua-name = *text-no-semi
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
mdn-gateway-field = "MDN-Gateway" ":" OWS mta-name-type OWS ";" OWS mta-name mdn-gateway-field = "MDN-Gateway" ":" OWS mta-name-type OWS ";" OWS mta-name
mta-name = *text mta-name = *text
original-recipient-field = original-recipient-field =
skipping to change at page 26, line 43 skipping to change at page 27, line 40
--RAA14128.773615765/example.com --RAA14128.773615765/example.com
content-type: message/rfc822 content-type: message/rfc822
[original message optionally goes here] [original message optionally goes here]
--RAA14128.773615765/example.com-- --RAA14128.773615765/example.com--
10. IANA Considerations 10. IANA Considerations
This document specifies three types of parameters that must be This document specifies three types of parameters that must be
registered with the Internet Assigned Numbers Authority (IANA). registered with the Internet Assigned Numbers Authority (IANA). All
of them use [14] "Specification required" IANA registration policy.
The forms below are for use when registering a new disposition- The forms below are for use when registering a new disposition-
notification-parameter name for the Disposition-Notification-Options notification-parameter name for the Disposition-Notification-Options
header field, a new disposition modifier name, or a new MDN extension header field, a new disposition modifier name, or a new MDN extension
field. Each piece of information required by a registration form may field. Each piece of information required by a registration form may
be satisfied either by providing the information on the form itself, be satisfied either by providing the information on the form itself,
or by including a reference to a published, publicly available or by including a reference to a published, publicly available
specification that includes the necessary information. IANA MAY specification that includes the necessary information. IANA MAY
reject registrations because of incomplete registration forms or reject registrations because of incomplete registration forms or
incomplete specifications. incomplete specifications.
skipping to change at page 27, line 28 skipping to change at page 28, line 26
b. The syntax for disposition-notification-parameter values, b. The syntax for disposition-notification-parameter values,
specified using BNF, ABNF, regular expressions, or other non- specified using BNF, ABNF, regular expressions, or other non-
ambiguous language. ambiguous language.
c. If disposition-notification-parameter values are not composed c. If disposition-notification-parameter values are not composed
entirely of graphic characters from the US-ASCII repertoire, a entirely of graphic characters from the US-ASCII repertoire, a
specification for how they are to be encoded as graphic US-ASCII specification for how they are to be encoded as graphic US-ASCII
characters in a Disposition-Notification-Options header field. characters in a Disposition-Notification-Options header field.
d. A reference to a standards track RFC or experimental RFC approved d. A reference to a permanent and readily available public
by the IESG that describes the semantics of the disposition- specification that describes the semantics of the disposition-
notification-parameter values. notification-parameter values.
10.2. Disposition modifier names 10.2. Disposition modifier names
A registration for a disposition-modifier name (used in the A registration for a disposition-modifier name (used in the
Disposition field of a message/disposition-notification) MUST include Disposition field of a message/disposition-notification) MUST include
the following information: the following information:
a. The proposed disposition-modifier name. a. The proposed disposition-modifier name.
b. A reference to a standards track RFC or experimental RFC approved b. A reference to a permanent and readily available public
by the IESG that describes the semantics of the disposition specification that describes the semantics of the disposition
modifier. modifier.
10.3. MDN extension field names 10.3. MDN extension field names
A registration for an MDN extension-field name MUST include the A registration for an MDN extension-field name MUST include the
following information: following information:
a. The proposed extension field name. a. The proposed extension field name.
b. The syntax for extension values, specified using BNF, ABNF, b. The syntax for extension values, specified using BNF, ABNF,
regular expressions, or other non-ambiguous language. regular expressions, or other non-ambiguous language.
c. If extension-field values are not composed entirely of graphic c. If extension-field values are not composed entirely of graphic
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 standards track RFC or experimental RFC approved d. A reference to a permanent and readily available public
by the IESG that describes the semantics of the extension field. specification that describes the semantics of the extension
field.
11. Acknowledgements 11. Acknowledgements
The contributions of Bruce Lilly, Alfred Hoenes and Pete Resnick are The contributions of Bruce Lilly, Alfred Hoenes and Pete Resnick are
gratefully acknowledged for this 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
skipping to change at page 29, line 46 skipping to change at page 30, line 41
profile for Internet Message Access Protocol (IMAP)", profile for Internet Message Access Protocol (IMAP)",
RFC 3503, DOI 10.17487/RFC3503, March 2003, RFC 3503, DOI 10.17487/RFC3503, March 2003,
<http://www.rfc-editor.org/info/rfc3503>. <http://www.rfc-editor.org/info/rfc3503>.
12.2. Informative References 12.2. Informative References
[11] Hoffman, P., Ed., "Enhanced Security Services for S/MIME", [11] Hoffman, P., Ed., "Enhanced Security Services for S/MIME",
RFC 2634, DOI 10.17487/RFC2634, June 1999, RFC 2634, DOI 10.17487/RFC2634, June 1999,
<http://www.rfc-editor.org/info/rfc2634>. <http://www.rfc-editor.org/info/rfc2634>.
[12] Murchison, K., "Sieve Email Filtering: Subaddress [12] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,
<http://www.rfc-editor.org/info/rfc3501>.
[13] Murchison, K., "Sieve Email Filtering: Subaddress
Extension", RFC 5233, DOI 10.17487/RFC5233, January 2008, Extension", RFC 5233, DOI 10.17487/RFC5233, January 2008,
<http://www.rfc-editor.org/info/rfc5233>. <http://www.rfc-editor.org/info/rfc5233>.
[13] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION [14] Narten, T. and H. Alvestrand, "Guidelines for Writing an
4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
<http://www.rfc-editor.org/info/rfc3501>. DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.
[15] Hansen, T., Ed., Newman, C., and A. Melnikov,
"Internationalized Delivery Status and Disposition
Notifications", RFC 6533, DOI 10.17487/RFC6533, February
2012, <http://www.rfc-editor.org/info/rfc6533>.
Appendix A. Changes from RFC 3798 Appendix A. Changes from RFC 3798
Changeg IANA registration for different subregistries to
"Specification Required" to match what is already used by IANA.
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".
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.
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.
skipping to change at page 30, line 36 skipping to change at page 31, line 44
Extension-field was defined in the collected grammar but not in the Extension-field was defined in the collected grammar but not in the
main text. main text.
The comparison of mailboxes in Disposition-Notification-To to the The comparison of mailboxes in Disposition-Notification-To to the
Return-Path addr-spec was clarified. Return-Path addr-spec was clarified.
The use of the grammar production "parameter" was confusing with the The use of the grammar production "parameter" was confusing with the
RFC2045 [3] production of the same name, as well as other uses of the RFC2045 [3] production of the same name, as well as other uses of the
same term. These have been clarified. same term. These have been clarified.
[[CREF1: Not sure what to do with this one: (From Bruce) In the case
of the message header fields, RFC 2822 also specifies minimum and
maximum counts for each header field, and similar guidance would
clarify 3798 (e.g. are multiple Disposition-Notification-Options
fields permitted in a single message header, and if so, what
semantics apply?). ]]
A clarification was added on the extent of the 7bit nature of MDNs. A clarification was added on the extent of the 7bit nature of MDNs.
Uses of the terms "may" and "might" were clarified. Uses of the terms "may" and "might" were clarified.
A clarification was added on the order of the fields in the message/ A clarification was added on the order of the fields in the message/
disposition-notification content. disposition-notification content.
[[CREF2: Not sure what to do with this one: (From Bruce) 3.1.1
explicitly mentions use of RFC 2047 encoded-words in comments
(however, as noted above there is no explicit provision for
comments), but fails to mention the other contexts in which encoded-
words may be used, viz. in an RFC [2]822 "phrase" (e.g. in the
display name of a name-addr mailbox in Disposition-Notification-To
(therefore, the discussion of encoded-words should probably be moved
earlier in the document, prior to the specification of Disposition-
Notification-To]), and in unstructured text (i.e. every instance of
*text in the ABNF). In particular, use of encoded-words might be
highly desirable in the following places: *) the ua-product portion
of the Reporting-UA field; *) the generic-address part of the
Original-Recipient and Final-Recipient fields; *) the (unstructured)
field bodies of Error, Failure, and Warning fields; in structured
extension fields where the context (per RFC 2047) is appropriate in
unstructured extension fields; *) in X- extension fields (see RFC
2047 for related X- message header fields). In cases where the field
syntax is shared with DSN fields, some coordination with the RFC 346x
authors might be desirable. ]]
Authors' Addresses Authors' Addresses
Tony Hansen (editor) Tony Hansen (editor)
AT&T Laboratories AT&T Laboratories
200 Laurel Ave. South 200 Laurel Ave. South
Middletown, NJ 07748 Middletown, NJ 07748
USA USA
Email: tony+rfc3798@maillennium.att.com Email: tony+rfc3798@maillennium.att.com
 End of changes. 38 change blocks. 
104 lines changed or deleted 103 lines changed or added

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