draft-ietf-appsawg-mdn-3798bis-00.txt   draft-ietf-appsawg-mdn-3798bis-01.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: March 15, 2015 September 11, 2014 Expires: July 23, 2015 January 19, 2015
Message Disposition Notification Message Disposition Notification
draft-ietf-appsawg-mdn-3798bis-00.txt draft-ietf-appsawg-mdn-3798bis-01.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 March 15, 2015. This Internet-Draft will expire on July 23, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 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
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 42 skipping to change at page 2, line 42
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 . . . . . . . . . . . . . . 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 . . . . . . . . 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 . . . . 11 3.1. The message/disposition-notification content-type . . . . 11
3.2. Message/disposition-notification Fields . . . . . . . . . 13 3.2. Message/disposition-notification Fields . . . . . . . . . 13
3.3. Extension-fields . . . . . . . . . . . . . . . . . . . . 18 3.3. Extension-fields . . . . . . . . . . . . . . . . . . . . 18
4. Timeline of events . . . . . . . . . . . . . . . . . . . . . 19 4. Timeline of events . . . . . . . . . . . . . . . . . . . . . 19
5. Conformance and Usage Requirements . . . . . . . . . . . . . 20 5. Conformance and Usage Requirements . . . . . . . . . . . . . 20
6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
6.1. Forgery . . . . . . . . . . . . . . . . . . . . . . . . . 21 6.1. Forgery . . . . . . . . . . . . . . . . . . . . . . . . . 21
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 Grammar . . . . . . . . . . . . . . . . . . . . . . 22 7. Collected 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 . . . . . . . 24
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 . . . . . . . . . . . . . . . . . 29
Appendix A. Changes from RFC 3798 . . . . . . . . . . . . . . . 29 Appendix A. Changes from RFC 3798 . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 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/
skipping to change at page 5, line 21 skipping to change at page 5, line 21
All syntax descriptions use the ABNF specified by RFC-MSGFMT [2], in All syntax descriptions use the ABNF specified by RFC-MSGFMT [2], in
which the lexical tokens (used below) are defined: "atom", "CRLF", which the lexical tokens (used below) are defined: "atom", "CRLF",
"FWS", "CFWS", "field-name", "mailbox", "msg-id", and "text". The "FWS", "CFWS", "field-name", "mailbox", "msg-id", and "text". The
following lexical tokens are defined in the definition of the following lexical tokens are defined in the definition of the
Content-Type header field in RFC-MIME-BODY [3]: "attribute" and Content-Type header field in RFC-MIME-BODY [3]: "attribute" and
"value". "value".
2. Requesting Message Disposition Notifications 2. Requesting Message Disposition Notifications
Message disposition notifications are requested by including a Message disposition notifications are requested by including a
Disposition-Notification-To header field in the message. Further Disposition-Notification-To header field in the message containing
information to be used by the recipient's MUA in generating the MDN one or more addresses specifying where dispositions should be sent.
may be provided by also including Original-Recipient and/or Further information to be used by the recipient's MUA in generating
the MDN may be provided by also including Original-Recipient and/or
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" ":" [FWS] mdn-request-header = "Disposition-Notification-To" ":" [FWS]
mailbox *("," [FWS] mailbox) mailbox *("," [FWS] mailbox)
skipping to change at page 6, line 22 skipping to change at page 6, line 23
online at the time), then an MDN SHOULD NOT be sent. online at the time), then an MDN SHOULD NOT be sent.
Confirmation from the user SHOULD be obtained (or no MDN sent) if Confirmation from the user SHOULD be obtained (or no MDN sent) if
there is no Return-Path header field in the message, or if there is there is no Return-Path header field in the message, or if there is
more than one distinct address in the Disposition-Notification-To more than one distinct address in the Disposition-Notification-To
header field. header field.
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. [[ more work local-part and case-insensitive for the domain part. The local-part
needed here ]] comparison SHOULD be done after performing local-part
canonicalization (i.e. after removing the surrounding double-quote
[[CREF1: (From Bruce) the domains might differ, yet refer to the same characters, if any, as well as any escaping "\" characters. (See
place (equivalent MX mail exchangers, A vs. CNAME DNS records, DNS RFC-MSGFMT [2] for more details.) Implementations MAY treat known
names vs. domain literals, etc.) These are not addressed in 3798. domain aliases as equivalent for the purpose of comparison.
]]
[[CREF2: (From Bruce) local-parts and domains might differ as literal
text, but be equivalent when put in canonical form. The issues are
discussed in RFC 3696 -- but beware -- 3696 has a number of errors;
refer to RFC 5322 for the actual quoting and escaping rules. ]]
[[CREF3: (From Bruce) internationalization issues might further
compound comparison issues between local-parts and domains
(specifying that the on-the-wire forms must be compared might
suffice) ]]
[[CREF4: (From Bruce) there exist some conventions (not standardized Note that use of subaddressing (see [11]) can result in a failure to
as far as I know) regarding subaddressing applied to local parts, match two local-parts and thus result in possible suppression of the
e.g. as in tony+rfc3798@maillennium.att.com (that example also MDN. This document doesn't recommend special handling for this case,
illustrates an issue regarding subdomains) ]] as the receiving MUA can't reliably know whether or not the sender is
using subaddressing. [[ more work needed here ]]
[[CREF5: (From Bruce) Of those, the angle bracket issue ought to be [[CREF1: (From Bruce) Of those, the angle bracket issue ought to be
understood, but clarification could benefit implementors, especially understood, but clarification could benefit implementors, especially
as RFC 5322 defined the Return-Path syntax somewhat peculiarly. as RFC 5322 defined the Return-Path syntax somewhat peculiarly.
Canonicalization of local-parts and domains should probably be Canonicalization of local-parts and domains should probably be
required prior to comparison, and use of on-the-wire forms should required prior to comparison, and use of on-the-wire forms should
probably also be specified. DNS equivalence issues might be tricky probably also be specified. DNS equivalence issues might be tricky
for some implementations (e.g. offline reading); perhaps the for some implementations (e.g. offline reading); perhaps the
specification could use RFC 2119 "MAY" to give implementations leeway specification could use RFC 2119 "MAY" to give implementations leeway
to consider A vs. CNAME and DNS vs domain literal equivalence for to consider A vs. CNAME and DNS vs domain literal equivalence for
situations where DNS is available to the implementation (I'm not sure 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. about MX). About the only thing that can be said w.r.t.
skipping to change at page 8, line 5 skipping to change at page 8, line 5
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 Future extensions to this specification may require that information
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] disposition-notification-parameter)
disposition-notification-parameter = attribute [FWS] "=" disposition-notification-parameter = attribute [FWS] "="
[FWS] importance "," [FWS] value *("," [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.
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) and described in a standards-track RFC or an
experimental RFC approved by the IESG. [[ more work needed here ]] experimental RFC approved by the IESG. [[ more work needed here ]]
(See Section 10 for a registration form.) (See Section 10 for a registration form.)
2.3. The Original-Recipient Header 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" ":" address-type ";" generic-address "Original-Recipient" ":" [FWS] address-type [FWS] ";" [FWS] generic-address
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 46 skipping to change at page 11, line 46
[ 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 ":" *(CFWS / text) extension-field = extension-field-name ":" *(CFWS / text)
extension-field-name = field-name extension-field-name = field-name
[[ more work needed here ]] Note that the order of the above fields is fixed, with the exception
of the extension fields.
[[CREF6: Is this wording okay ? ]] Note that the order of the above
fields is fixed.
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. 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". [[ more work needed here ]] colon, followed by "*text". [[ more work needed here ]]
[[CREF7: ( Shouldn't this allow FWS somehow? Alexey: yes!) ]] [[CREF2: (Here and elsewhere in the document) It looks like there is
[[CREF8: ( I see that address-type and mta-name-type uses atom emerging consensus that the document should describe 2 grammars: one
for "must accept" (which allows CFWS) and another one for "should
generate" (CFWS not allowed, but [FWS] are allowed). A future
version of this document will implement this change, unless
objections are voiced. ]]
[[CREF3: ( I see that address-type and mta-name-type uses atom
instead of *text, which not only permits FWS, but goes further to instead of *text, which not only permits FWS, but goes further to
allow CFWS. ) ]] For these fields, the keyword used in the address- allow CFWS. Possibilities include switching to: [FWS] *text [FWS],
type or MTA-type subfield indicates the expected format of the or switching to the RFC 5321 definition of atom (1*atext). ) ]] For
address or MTA-name that follows. these fields, the keyword used in the address-type or MTA-type
subfield indicates the expected format of the address or MTA-name
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
[[ more work needed here ]]
[[CREF9: This is not *text ]]
b. An "MTA-name-type" specifies the format of a mail transfer agent b. An "MTA-name-type" specifies the format of a mail transfer agent
name. For example, for an SMTP server on an Internet host, the name. For example, for an SMTP server on an Internet host, the
MTA name is the domain name of that host, and the "dns" MTA-name- MTA name is the domain name of that host, and the "dns" MTA-name-
type is used. type is used.
mta-name-type = atom mta-name-type = atom
[[ more work needed here ]]
[[CREF10: This is not *text ]]
Values for address-type and mta-name-type are case-insensitive. Values for address-type and mta-name-type are case-insensitive.
Thus, address-type values of "RFC822" and "rfc822" are equivalent. Thus, address-type values of "RFC822" and "rfc822" are equivalent.
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].
skipping to change at page 14, line 25 skipping to change at page 14, line 22
no Original-Recipient header field in the message, then the Original- no Original-Recipient header field in the message, then the Original-
Recipient field MUST be omitted, unless the same information is Recipient field MUST be omitted, unless the same information is
reliably available some other way. If there is an Original-Recipient reliably available some other way. If there is an Original-Recipient
header field in the original message (or original recipient header field in the original message (or original recipient
information is reliably available some other way), then the Original- information is reliably available some other way), then the Original-
Recipient field must be supplied. If there is more than one Recipient field must be supplied. If there is more than one
Original-Recipient header field in the message, the MUA may choose Original-Recipient header field in the message, the MUA may choose
the one to use, or act as if no Original-Recipient header field is the one to use, or act as if no Original-Recipient header field is
present. present.
original-recipient-field = original-recipient-field =
"Original-Recipient" ":" address-type ";" generic-address "Original-Recipient" ":" [FWS] address-type [FWS] ";" [FWS] generic-address
generic-address = *text generic-address = *text
The address-type field indicates the type of the original recipient The address-type field indicates the type of the original recipient
address. If the message originated within the Internet, the address- address. If the message originated within the Internet, the address-
type field will normally be "rfc822", and the address will be type field will normally be "rfc822", and the address will be
according to the syntax specified in RFC-MSGFMT [2]. The value according to the syntax specified in RFC-MSGFMT [2]. The value
"unknown" should be used if the Reporting MUA cannot determine the "unknown" should be used if the Reporting MUA cannot determine the
type of the original recipient address from the message envelope. type of the original recipient address from the message envelope.
This address is the same as that provided by the sender and can be This address is the same as that provided by the sender and can be
used to automatically correlate MDN reports with original messages on used to automatically correlate MDN reports with original messages on
a per recipient basis. a per recipient basis.
3.2.4. Final-Recipient field 3.2.4. Final-Recipient field
The Final-Recipient field indicates the recipient for which the MDN The Final-Recipient field indicates the recipient for which the MDN
is being issued. This field MUST be present. is being issued. This field MUST be present.
The syntax of the field is as follows: The syntax of the field is as follows:
final-recipient-field = final-recipient-field =
"Final-Recipient" ":" address-type ";" generic-address "Final-Recipient" ":" [FWS] address-type [FWS] ";" [FWS] generic-address
The generic-address subfield of the Final-Recipient field MUST The generic-address subfield of the Final-Recipient field MUST
contain the mailbox address of the recipient (from the From header contain the mailbox address of the recipient (from the From header
field of the MDN) as it was when the MDN was generated by the MUA. field of the MDN) as it was when the MDN was generated by the MUA.
The Final-Recipient address may differ from the address originally The Final-Recipient address may differ from the address originally
provided by the sender, because it may have been transformed during provided by the sender, because it may have been transformed during
forwarding and gatewaying into a totally unrecognizable mess. forwarding and gatewaying into a totally unrecognizable mess.
However, in the absence of the optional Original-Recipient field, the However, in the absence of the optional Original-Recipient field, the
Final-Recipient field and any returned content may be the only Final-Recipient field and any returned content may be the only
information available with which to correlate the MDN with a information available with which to correlate the MDN with a
particular message recipient. particular message recipient.
The address-type subfield indicates the type of address expected by The address-type subfield indicates the type of address expected by
the reporting MTA in that context. Recipient addresses obtained via the reporting MTA in that context. Recipient addresses obtained via
SMTP will normally be of address-type "rfc822". SMTP will normally be of address-type "rfc822".
Since mailbox addresses (including those used in the Internet) may be Since mailbox addresses (including those used in the Internet) may be
skipping to change at page 23, line 5 skipping to change at page 22, line 49
"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 Grammar 7. Collected Grammar
NOTE: The following lexical tokens are defined in RFC-MSGFMT [2]: NOTE: The following lexical tokens are defined in RFC-MSGFMT [2]:
atom, CRLF, FWS, CFWS, field-name, mailbox, msg-id, text. The atom, CRLF, FWS, CFWS, field-name, mailbox, msg-id, text. The
definitions of attribute and value are as in the definition of the definitions of attribute and value are as in the definition of the
Content-Type header field in RFC-MIME-BODY [3]. Content-Type header field in RFC-MIME-BODY [3].
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" ":" [FWS] Disposition-Notification-Options =
disposition-notification-parameter-list "Disposition-Notification-Options" ":" [FWS]
disposition-notification-parameter-list = disposition-notification-parameter-list
disposition-notification-parameter disposition-notification-parameter-list =
*(";" [FWS] disposition-notification-parameter) disposition-notification-parameter
disposition-notification-parameter = attribute [FWS] "=" [FWS] *(";" [FWS] disposition-notification-parameter)
importance "," [FWS] value *("," [FWS] value) disposition-notification-parameter = attribute [FWS] "=" [FWS]
importance = "required" / "optional" importance [FWS] "," [FWS] value *([FWS] "," [FWS] value)
original-recipient-header = importance = "required" / "optional"
"Original-Recipient" ":" address-type ";" generic-address original-recipient-header =
Report content: "Original-Recipient" ":" [FWS] address-type [FWS] ";" [FWS] generic-address
disposition-notification-content = Report content:
[ reporting-ua-field CRLF ] disposition-notification-content =
[ mdn-gateway-field CRLF ] [ reporting-ua-field CRLF ]
[ original-recipient-field CRLF ] [ mdn-gateway-field CRLF ]
final-recipient-field CRLF [ original-recipient-field CRLF ]
[ original-message-id-field CRLF ] final-recipient-field CRLF
disposition-field CRLF [ original-message-id-field CRLF ]
*( failure-field CRLF ) disposition-field CRLF
*( error-field CRLF ) *( failure-field CRLF )
*( extension-field CRLF ) *( error-field CRLF )
address-type = atom *( extension-field CRLF )
mta-name-type = atom address-type = atom
reporting-ua-field = "Reporting-UA" ":" ua-name [ ";" ua-product ] mta-name-type = atom
ua-name = *text-no-semi reporting-ua-field = "Reporting-UA" ":" ua-name [ ";" ua-product ]
ua-product = *text-no-semi ua-name = *text-no-semi
text-no-semi = %d1-9 / ; text characters excluding NUL, CR, ua-product = *text-no-semi
%d11 / %d12 / %d14-58 / %d60-127 ; LF, or semi-colon text-no-semi = %d1-9 / ; text characters excluding NUL, CR,
mdn-gateway-field = "MDN-Gateway" ":" mta-name-type ";" mta-name %d11 / %d12 / %d14-58 / %d60-127 ; LF, or semi-colon
mta-name = *text mdn-gateway-field = "MDN-Gateway" ":" mta-name-type ";" mta-name
original-recipient-field = mta-name = *text
"Original-Recipient" ":" address-type ";" generic-address original-recipient-field =
generic-address = *text "Original-Recipient" ":" [FWS] address-type [FWS] ";" [FWS] generic-address
final-recipient-field = generic-address = *text
"Final-Recipient" ":" address-type ";" generic-address final-recipient-field =
original-message-id-field = "Original-Message-ID" ":" msg-id "Final-Recipient" ":" [FWS] address-type [FWS] ";" [FWS] generic-address
disposition-field = original-message-id-field = "Original-Message-ID" ":" msg-id
"Disposition" ":" [FWS] disposition-mode ";" disposition-field =
[FWS] disposition-type "Disposition" ":" [FWS] disposition-mode ";"
[ "/" disposition-modifier [FWS] disposition-type
*( "," disposition-modifier ) ] [ "/" disposition-modifier
disposition-mode = action-mode "/" [FWS] sending-mode *( "," disposition-modifier ) ]
action-mode = "manual-action" / "automatic-action" disposition-mode = action-mode "/" [FWS] sending-mode
sending-mode = "MDN-sent-manually" / "MDN-sent-automatically" action-mode = "manual-action" / "automatic-action"
disposition-type = "displayed" / "deleted" / "dispatched" / sending-mode = "MDN-sent-manually" / "MDN-sent-automatically"
"processed" disposition-type = "displayed" / "deleted" / "dispatched" /
disposition-modifier = [FWS] "processed"
("error" / disposition-modifier-extension) disposition-modifier = [FWS]
disposition-modifier-extension = atom ("error" / disposition-modifier-extension)
failure-field = "Failure" ":" *text disposition-modifier-extension = atom
error-field = "Error" ":" *text failure-field = "Failure" ":" *text
extension-field = extension-field-name ":" *text error-field = "Error" ":" *text
extension-field-name = field-name extension-field = extension-field-name ":" *text
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.
8.1. Gatewaying from other mail systems to MDNs 8.1. Gatewaying from other mail systems to MDNs
skipping to change at page 29, line 9 skipping to change at page 29, line 9
The contributions of Bruce Lilly and Alfred Hoenes are gratefully The contributions of Bruce Lilly and Alfred Hoenes are gratefully
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 2821, [1] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
April 2001. October 2008.
[2] Resnick, P., Ed., "Internet Message Format", RFC 5322, [2] Resnick, P., Ed., "Internet Message Format", RFC 5322,
October 2008. October 2008.
[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, November 1996.
[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,
skipping to change at page 29, line 47 skipping to change at page 29, line 47
2003. 2003.
[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, March 1997.
12.2. Informative References 12.2. Informative References
[10] Hoffman, P., "Enhanced Security Services for S/MIME", RFC [10] Hoffman, P., "Enhanced Security Services for S/MIME", RFC
2634, June 1999. 2634, June 1999.
[11] Murchison, K., "Sieve Email Filtering: Subaddress
Extension", RFC 5233, January 2008.
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 and
skipping to change at page 30, line 24 skipping to change at page 30, line 29
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.
[[CREF11: Shouldn't the places we use *text and *text-no-semi allow [[CREF4: Shouldn't the places we use *text and *text-no-semi allow
FWS? ]] 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.
[[CREF12: Not sure what to do with this one: (From Bruce) In the case [[CREF5: 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?). ]]
[[CREF13: Not sure what to do with this one: (From Bruce) Note also [[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 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 issue of where CFWS is permitted or prohibited should probably be
clearly specified where "attribute" and "value" are used. Note clearly specified where "attribute" and "value" are used. Note
further that the RFC 2045 definitions are clarified by errata and further that the RFC 2045 definitions are clarified by errata and
modified by RFC 2231, and by RFC 2231 errata. Finally, note that RFC modified by RFC 2231, and by RFC 2231 errata. Finally, note that RFC
2231 has provisions for continuation of long parameter values (where 2231 has provisions for continuation of long parameter values (where
there would otherwise be problems with the maximum line length there would otherwise be problems with the maximum line length
specifications of RFCs 822 and 2822), specification of language and specifications of RFCs 822 and 2822), specification of language and
charset, and provision for compatible handling of non-ASCII text, charset, and provision for compatible handling of non-ASCII text,
none of which are provided for in the RFC 3798 disposition- none of which are provided for in the RFC 3798 disposition-
skipping to change at page 31, line 4 skipping to change at page 31, line 9
further that the RFC 2045 definitions are clarified by errata and further that the RFC 2045 definitions are clarified by errata and
modified by RFC 2231, and by RFC 2231 errata. Finally, note that RFC modified by RFC 2231, and by RFC 2231 errata. Finally, note that RFC
2231 has provisions for continuation of long parameter values (where 2231 has provisions for continuation of long parameter values (where
there would otherwise be problems with the maximum line length there would otherwise be problems with the maximum line length
specifications of RFCs 822 and 2822), specification of language and specifications of RFCs 822 and 2822), specification of language and
charset, and provision for compatible handling of non-ASCII text, charset, and provision for compatible handling of non-ASCII text,
none of which are provided for in the RFC 3798 disposition- none of which are provided for in the RFC 3798 disposition-
notification parameters. It might be a good idea to think about that notification parameters. It might be a good idea to think about that
now, as a future change would almost certainly reset the document now, as a future change would almost certainly reset the document
status to "Proposed". ]] 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.
[[CREF14: Not sure what to do with this one: (From Bruce) 3.1.1 [[CREF7: 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
of the Reporting-UA field; *) the generic-address part of the of the Reporting-UA field; *) the generic-address part of the
Original-Recipient and Final-Recipient fields; *) the (unstructured) Original-Recipient and Final-Recipient fields; *) the (unstructured)
field bodies of Error, Failure, and Warning fields; in structured field bodies of Error, Failure, and Warning fields; in structured
extension fields where the context (per RFC 2047) is appropriate in extension fields where the context (per RFC 2047) is appropriate in
unstructured extension fields; *) in X- extension fields (see RFC unstructured extension fields; *) in X- extension fields (see RFC
2047 for related X- message header fields). In cases where the field 2047 for related X- message header fields). In cases where the field
syntax is shared with DSN fields, some coordination with the RFC 346x syntax is shared with DSN fields, some coordination with the RFC 346x
authors might be desirable. ]] authors might be desirable. ]]
[[CREF15: I think a couple of clarifications are in order: 1) This [[CREF8: I think a couple of clarifications are in order: 1) This
restriction is within a given mail user agent. If the user uses restriction is within a given mail user agent. If the user uses
multiple MUAs, it is possible that multiple MDNs MAY be generated. multiple MUAs, it is possible that multiple MDNs MAY be generated.
2) A mail user agent SHOULD use underlying protocol support when 2) A mail user agent SHOULD use underlying protocol support when
possible to prevent multiple MDNs from being generated. If possible to prevent multiple MDNs from being generated. If
underlying protocol support is not available, the mail user agent underlying protocol support is not available, the mail user agent
MUST use local knowledge to prevent multiple MDNs. I don't think we MUST use local knowledge to prevent multiple MDNs. I don't think we
need to worry about the case of an MUA error; accidents and bad need to worry about the case of an MUA error; accidents and bad
implementations DO happen. (From Bruce) 3.2.6.3 prohibition against implementations DO happen. (From Bruce) 3.2.6.3 prohibition against
multiple MDNs being issued on behalf of each recipient poses some multiple MDNs being issued on behalf of each recipient poses some
implementation difficulties: *) While IMAP servers maintain state implementation difficulties: *) While IMAP servers maintain state
 End of changes. 32 change blocks. 
130 lines changed or deleted 126 lines changed or added

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