draft-ietf-appsawg-mdn-3798bis-03.txt   draft-ietf-appsawg-mdn-3798bis-04.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: January 5, 2016 July 4, 2015 Expires: May 31, 2016 November 28, 2015
Message Disposition Notification Message Disposition Notification
draft-ietf-appsawg-mdn-3798bis-03.txt draft-ietf-appsawg-mdn-3798bis-04.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 January 5, 2016. This Internet-Draft will expire on May 31, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 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 . . . . . . . . 9 2.4. Use with the Message/Partial Content Type . . . . . . . . 8
3. Format of a Message Disposition Notification . . . . . . . . 9 3. Format of a Message Disposition Notification . . . . . . . . 9
3.1. The message/disposition-notification content-type . . . . 11 3.1. The message/disposition-notification content-type . . . . 10
3.2. Message/disposition-notification Fields . . . . . . . . . 13 3.2. Message/disposition-notification Fields . . . . . . . . . 12
3.3. Extension-fields . . . . . . . . . . . . . . . . . . . . 18 3.3. Extension-fields . . . . . . . . . . . . . . . . . . . . 18
4. Timeline of events . . . . . . . . . . . . . . . . . . . . . 19 4. Timeline of events . . . . . . . . . . . . . . . . . . . . . 18
5. Conformance and Usage Requirements . . . . . . . . . . . . . 20 5. Conformance and Usage Requirements . . . . . . . . . . . . . 19
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
6.1. Forgery . . . . . . . . . . . . . . . . . . . . . . . . . 21 6.1. Forgery . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 21 6.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 21
6.3. Non-Repudiation . . . . . . . . . . . . . . . . . . . . . 22 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 . . . . . . . 25 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 9. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 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 . . . . . . . . 27
10.2. Disposition modifier names . . . . . . . . . . . . . . . 28 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 . . . . . . . . . . . . . . . . . . . . . . 28
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
12.1. Normative References . . . . . . . . . . . . . . . . . . 29 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 . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
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,
skipping to change at page 6, line 45 skipping to change at page 6, line 45
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 [12]) 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. [[ more work needed here ]] using subaddressing.
[[CREF1: (From Bruce) Of those, the angle bracket issue ought to be
understood, but clarification could benefit implementors, especially
as RFC 5322 defined the Return-Path syntax somewhat peculiarly.
Canonicalization of local-parts and domains should probably be
required prior to comparison, and use of on-the-wire forms should
probably also be specified. DNS equivalence issues might be tricky
for some implementations (e.g. offline reading); perhaps the
specification could use RFC 2119 "MAY" to give implementations leeway
to consider A vs. CNAME and DNS vs domain literal equivalence for
situations where DNS is available to the implementation (I'm not sure
about MX). About the only thing that can be said w.r.t.
subaddressing and subdomains is a caution to sending MUA and address-
rewriting MTA authors that a mismatch might result in no MDN being
produced. ]]
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
fails or more than one address is specified is to reduce the fails or more than one address is specified is to reduce the
possibility of mail loops and of MDNs being used for mail bombing. possibility of mail loops and of MDNs being used for mail bombing.
A message that contains a Disposition-Notification-To header field A message that contains a Disposition-Notification-To header field
skipping to change at page 8, line 10 skipping to change at page 7, line 46
be supplied to the recipient's MUA for additional control over how be supplied to the recipient's MUA for additional control over how
and what MDNs are generated. The Disposition-Notification-Options and what MDNs are generated. The Disposition-Notification-Options
header field provides an extensible mechanism for such information. header field provides an extensible mechanism for such information.
The syntax of this header field is as follows: The 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
disposition-notification-parameter-list = disposition-notification-parameter-list =
disposition-notification-parameter disposition-notification-parameter
*(";" [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"
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.
skipping to change at page 11, line 43 skipping to change at page 11, line 31
disposition-notification-content = [ reporting-ua-field CRLF ] disposition-notification-content = [ 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 )
extension-field = extension-field-name ":" *(FWS / text) extension-field = extension-field-name ":" *([FWS] text)
extension-field-name = field-name extension-field-name = field-name
Note that the order of the above fields is fixed, with the exception Note that the order of the above fields is fixed, with the exception
of the extension fields. of the extension fields.
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
skipping to change at page 12, line 21 skipping to change at page 12, line 9
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. Comments in notification fields may
use the "encoded-word" construct defined in RFC-MIME-HEADER [5]. 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".
[[CREF2: (Here and elsewhere in the document) It looks like there is
emerging consensus that the document should describe 2 grammars: one
for "must accept" (which either allows CFWS or [FWS]) and another one
for "should generate" (CFWS not allowed, but *WSP are allowed). A
future version of this document will implement this change, unless
objections are voiced. ]]
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:
a. An "address-type" specifies the format of a mailbox address. For a. An "address-type" specifies the format of a mailbox address. For
example, Internet Mail addresses use the "rfc822" address-type. example, Internet Mail addresses use the "rfc822" address-type.
address-type = atom address-type = atom
skipping to change at page 13, line 12 skipping to change at page 13, line 4
The Internet Assigned Numbers Authority (IANA) maintains a registry The Internet Assigned Numbers Authority (IANA) maintains a registry
of address-type and mta-name-type values, along with descriptions of of address-type and mta-name-type values, along with descriptions of
the meanings of each, or a reference to one or more specifications the meanings of each, or a reference to one or more specifications
that provide such descriptions. (The "rfc822" address-type is that provide such descriptions. (The "rfc822" address-type is
defined in RFC-DSN-SMTP [7].) Registration forms for address-type defined in RFC-DSN-SMTP [7].) Registration forms for address-type
and mta-name-type appear in RFC-DSN-FORMAT [8]. and mta-name-type appear in RFC-DSN-FORMAT [8].
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 OWS = *WSP ; generators
/ [CFWS] ; parsers
; Optional whitespace. ; Optional whitespace.
; MDN generators SHOULD use "*WSP" ; MDN generators SHOULD use "*WSP"
; (typically a single space or nothing. ; (typically a single space or nothing.
; It SHOULD be nothing at the end of a field). ; It SHOULD be nothing at the end of a field),
; unless an RFC 5322 "comment" is required.
;
; MDN parsers MUST parse it as "[CFWS]". ; 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,
Reporting-UA: pc.example.com; Foomail 97.1 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. [[CREF3: Should ua-name be defined as "*(FWS / of product names.
text-no-semi)"?]]
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 18, line 20 skipping to change at page 18, line 14
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. 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)
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) and described in a standards-track RFC or an experimental RFC
approved by the IESG. (See Section 10 for a registration form.) MDN approved by the IESG. (See Section 10 for a registration form.) MDN
skipping to change at page 22, line 45 skipping to change at page 22, line 37
attack could overrun the capacity of the targeted mailbox and deny attack could overrun the capacity of the targeted mailbox and deny
service. 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 envelope "disposition-notification-to:" address is different from the envelope
MAIL FROM address. See Section 2.1 for further discussion. MAIL FROM address. 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 [2]: NOTE: The following lexical tokens are defined in RFC-MSGFMT [2]:
CRLF, FWS, CFWS, field-name, mailbox, msg-id, text. The following CRLF, FWS, CFWS, field-name, mailbox, msg-id, text, comment. The
lexical tokens are defined in RFC-SMTP [1]: atom. (Note that RFC- following lexical tokens are defined in RFC-SMTP [1]: atom. (Note
MSGFMT [2] also defines "atom", but the version from RFC-SMTP [1] is that RFC-MSGFMT [2] also defines "atom", but the version from RFC-
more restrictive and this more restrictive version is used in this SMTP [1] is more restrictive and this more restrictive version is
document.) The definitions of attribute and value are as in the used in this document.) The definitions of attribute and value are
definition of the Content-Type header field in RFC-MIME-BODY [3]. as in the definition of the Content-Type header field in RFC-MIME-
BODY [3]. "encoded-word" construct defined in RFC-MIME-HEADER [5] is
allowed everywhere where RFC-MSGFMT [2] "comment" is used, for
example in CFWS.
Message header fields: Message header fields:
mdn-request-header = mdn-request-header =
"Disposition-Notification-To" ":" [FWS] "Disposition-Notification-To" ":" [FWS]
mailbox *("," [FWS] mailbox) mailbox *("," [FWS] mailbox)
Disposition-Notification-Options = Disposition-Notification-Options =
"Disposition-Notification-Options" ":" [FWS] "Disposition-Notification-Options" ":" [FWS]
disposition-notification-parameter-list disposition-notification-parameter-list
disposition-notification-parameter-list = disposition-notification-parameter-list =
disposition-notification-parameter disposition-notification-parameter
*(";" [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"
original-recipient-header = original-recipient-header =
"Original-Recipient" ":" [FWS] address-type [FWS] ";" [FWS] generic-address "Original-Recipient" ":" [FWS] address-type [FWS] ";" [FWS] generic-address
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 )
skipping to change at page 23, line 30 skipping to change at page 23, line 25
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 OWS = *WSP ; generators
/ [CFWS] ; parsers
; Optional whitespace. ; Optional whitespace.
; MDN generators SHOULD use "*WSP" ; MDN generators SHOULD use "*WSP"
; (typically a single space or nothing). ; (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]". ; 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 =
"Original-Recipient" ":" OWS address-type OWS ";" OWS generic-address OWS "Original-Recipient" ":" OWS address-type OWS ";" OWS generic-address OWS
generic-address = *text generic-address = *text
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
original-message-id-field = "Original-Message-ID" ":" OWS msg-id OWS original-message-id-field = "Original-Message-ID" ":" OWS msg-id OWS
skipping to change at page 24, line 14 skipping to change at page 24, line 14
[ OWS "/" OWS disposition-modifier [ OWS "/" OWS disposition-modifier
*( OWS "," OWS disposition-modifier ) ] OWS *( OWS "," OWS disposition-modifier ) ] OWS
disposition-mode = action-mode OWS "/" OWS sending-mode disposition-mode = action-mode OWS "/" OWS sending-mode
action-mode = "manual-action" / "automatic-action" action-mode = "manual-action" / "automatic-action"
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) 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
disposition notifications between the Internet and another electronic disposition notifications between the Internet and another electronic
mail system. Specific MDN gateway requirements for a particular pair mail system. Specific MDN gateway requirements for a particular pair
of mail systems may be defined by other documents. of mail systems may be defined by other documents.
skipping to change at page 29, line 10 skipping to change at page 29, line 10
acknowledged for this revision. 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
[1] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, [1] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
October 2008. DOI 10.17487/RFC5321, October 2008,
<http://www.rfc-editor.org/info/rfc5321>.
[2] Resnick, P., Ed., "Internet Message Format", RFC 5322, [2] Resnick, P., Ed., "Internet Message Format", RFC 5322,
October 2008. DOI 10.17487/RFC5322, October 2008,
<http://www.rfc-editor.org/info/rfc5322>.
[3] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [3] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996. Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
<http://www.rfc-editor.org/info/rfc2045>.
[4] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [4] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, Extensions (MIME) Part Two: Media Types", RFC 2046,
November 1996. DOI 10.17487/RFC2046, November 1996,
<http://www.rfc-editor.org/info/rfc2046>.
[5] Moore, K., "MIME (Multipurpose Internet Mail Extensions) [5] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
Part Three: Message Header Extensions for Non-ASCII Text", Part Three: Message Header Extensions for Non-ASCII Text",
RFC 2047, November 1996. RFC 2047, DOI 10.17487/RFC2047, November 1996,
<http://www.rfc-editor.org/info/rfc2047>.
[6] Vaudreuil, G., "The Multipart/Report Content Type for the [6] Vaudreuil, G., "The Multipart/Report Content Type for the
Reporting of Mail System Administrative Messages", RFC Reporting of Mail System Administrative Messages",
3462, January 2003. RFC 3462, DOI 10.17487/RFC3462, January 2003,
<http://www.rfc-editor.org/info/rfc3462>.
[7] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service [7] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
Extension for Delivery Status Notifications (DSNs)", RFC Extension for Delivery Status Notifications (DSNs)",
3461, January 2003. RFC 3461, DOI 10.17487/RFC3461, January 2003,
<http://www.rfc-editor.org/info/rfc3461>.
[8] Moore, K. and G. Vaudreuil, "An Extensible Message Format [8] Moore, K. and G. Vaudreuil, "An Extensible Message Format
for Delivery Status Notifications", RFC 3464, January for Delivery Status Notifications", RFC 3464,
2003. DOI 10.17487/RFC3464, January 2003,
<http://www.rfc-editor.org/info/rfc3464>.
[9] Bradner, S., "Key words for use in RFCs to Indicate [9] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[10] Melnikov, A., "Message Disposition Notification (MDN) [10] Melnikov, A., "Message Disposition Notification (MDN)
profile for Internet Message Access Protocol (IMAP)", RFC profile for Internet Message Access Protocol (IMAP)",
3503, March 2003. RFC 3503, DOI 10.17487/RFC3503, March 2003,
<http://www.rfc-editor.org/info/rfc3503>.
12.2. Informative References 12.2. Informative References
[11] Hoffman, P., "Enhanced Security Services for S/MIME", RFC [11] Hoffman, P., Ed., "Enhanced Security Services for S/MIME",
2634, June 1999. RFC 2634, DOI 10.17487/RFC2634, June 1999,
<http://www.rfc-editor.org/info/rfc2634>.
[12] Murchison, K., "Sieve Email Filtering: Subaddress [12] Murchison, K., "Sieve Email Filtering: Subaddress
Extension", RFC 5233, January 2008. Extension", RFC 5233, DOI 10.17487/RFC5233, January 2008,
<http://www.rfc-editor.org/info/rfc5233>.
[13] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION [13] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, March 2003. 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,
<http://www.rfc-editor.org/info/rfc3501>.
Appendix A. Changes from RFC 3798 Appendix A. Changes from RFC 3798
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 and not be distinguished from *text in the production. The ua-name was
ua-product definitions were restricted to not include semi-colon. restricted to not include semi-colon. Semi-colon can still appear in
the ua-product.
The ABNF did not indicate all places that whitespace was allowable, The ABNF did not indicate all places that whitespace was allowable,
in particular folding whitespace, although all implementations allow in particular folding whitespace, although all implementations allow
whitespace and folding in the header fields just like any other whitespace and folding in the header fields just like any other
RFC5322 [2]-formatted header field. There were also a number of RFC5322 [2]-formatted header field. There were also a number of
places in the ABNF that inconsistently permitted comments and 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
main text. main text.
[[CREF4: Shouldn't the places we use *text and *text-no-semi allow
FWS? ]]
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.
[[CREF5: Not sure what to do with this one: (From Bruce) In the case [[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 of the message header fields, RFC 2822 also specifies minimum and
maximum counts for each header field, and similar guidance would maximum counts for each header field, and similar guidance would
clarify 3798 (e.g. are multiple Disposition-Notification-Options clarify 3798 (e.g. are multiple Disposition-Notification-Options
fields permitted in a single message header, and if so, what fields permitted in a single message header, and if so, what
semantics apply?). ]] semantics apply?). ]]
[[CREF6: Not sure what to do with this one: (From Bruce) Note also
that RFC 2045 is itself based on RFC 822 rather than 2822, so the
issue of where CFWS is permitted or prohibited should probably be
clearly specified where "attribute" and "value" are used. Note
further that the RFC 2045 definitions are clarified by errata and
modified by RFC 2231, and by RFC 2231 errata. Finally, note that RFC
2231 has provisions for continuation of long parameter values (where
there would otherwise be problems with the maximum line length
specifications of RFCs 822 and 2822), specification of language and
charset, and provision for compatible handling of non-ASCII text,
none of which are provided for in the RFC 3798 disposition-
notification parameters. It might be a good idea to think about that
now, as a future change would almost certainly reset the document
status to "Proposed". ]]
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.
[[CREF7: Not sure what to do with this one: (From Bruce) 3.1.1 [[CREF2: Not sure what to do with this one: (From Bruce) 3.1.1
explicitly mentions use of RFC 2047 encoded-words in comments explicitly mentions use of RFC 2047 encoded-words in comments
(however, as noted above there is no explicit provision for (however, as noted above there is no explicit provision for
comments), but fails to mention the other contexts in which encoded- 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 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 display name of a name-addr mailbox in Disposition-Notification-To
(therefore, the discussion of encoded-words should probably be moved (therefore, the discussion of encoded-words should probably be moved
earlier in the document, prior to the specification of Disposition- earlier in the document, prior to the specification of Disposition-
Notification-To]), and in unstructured text (i.e. every instance of Notification-To]), and in unstructured text (i.e. every instance of
*text in the ABNF). In particular, use of encoded-words might be *text in the ABNF). In particular, use of encoded-words might be
highly desirable in the following places: *) the ua-product portion highly desirable in the following places: *) the ua-product portion
 End of changes. 44 change blocks. 
95 lines changed or deleted 80 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/