draft-ietf-appsawg-mdn-3798bis-01.txt   draft-ietf-appsawg-mdn-3798bis-02.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: July 23, 2015 January 19, 2015 Expires: September 10, 2015 March 9, 2015
Message Disposition Notification Message Disposition Notification
draft-ietf-appsawg-mdn-3798bis-01.txt draft-ietf-appsawg-mdn-3798bis-02.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 July 23, 2015. This Internet-Draft will expire on September 10, 2015.
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 3, line 10 skipping to change at page 3, line 10
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 . . . . . . . . . . . . . . . . . . . 20 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 . . . . . . . 24 8.2. Gatewaying from MDNs to other mail systems . . . . . . . 25
8.3. Gatewaying of MDN-requests to other mail systems . . . . 25 8.3. Gatewaying of MDN-requests to other mail systems . . . . 25
9. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . 30 Appendix A. Changes from RFC 3798 . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 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,
or the recipient's refusal to provide MDNs. The "message/ or the recipient's refusal to provide MDNs. The "message/
disposition-notification" content-type defined herein is intended for disposition-notification" content-type defined herein is intended for
skipping to change at page 5, line 12 skipping to change at page 5, line 12
d. The specification must be extensible in order to accommodate d. The specification must be extensible in order to accommodate
future requirements. future requirements.
1.3. Terminology 1.3. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-KEYWORDS [9]. document are to be interpreted as described in RFC-KEYWORDS [9].
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: "CRLF", "FWS",
"FWS", "CFWS", "field-name", "mailbox", "msg-id", and "text". The "CFWS", "field-name", "mailbox", "msg-id", and "text". The following
following lexical tokens are defined in the definition of the lexical tokens are defined in RFC-SMTP [1]: "atom". The following
Content-Type header field in RFC-MIME-BODY [3]: "attribute" and lexical tokens are defined in the definition of the Content-Type
"value". header field in RFC-MIME-BODY [3]: "attribute" and "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 containing Disposition-Notification-To header field in the message containing
one or more addresses specifying where dispositions should be sent. one or more addresses specifying where dispositions should be sent.
Further information to be used by the recipient's MUA in generating Further information to be used by the recipient's MUA in generating
the MDN may be provided by also including Original-Recipient and/or 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.
skipping to change at page 5, line 46 skipping to change at page 5, line 46
The presence of a Disposition-Notification-To header field in a The presence of a Disposition-Notification-To header field in a
message is merely a request for an MDN. The recipients' user agents message is merely a request for an MDN. The recipients' user agents
are always free to silently ignore such a request. are always free to silently ignore such a request.
An MDN MUST NOT itself have a Disposition-Notification-To header An MDN MUST NOT itself have a Disposition-Notification-To header
field. An MDN MUST NOT be generated in response to an MDN. field. An MDN MUST NOT be generated in response to an MDN.
A user agent MUST NOT issue more than one MDN on behalf of each A user agent MUST NOT issue more than one MDN on behalf of each
particular recipient. That is, once an MDN has been issued on behalf particular recipient. That is, once an MDN has been issued on behalf
of a recipient, no further MDNs may be issued on behalf of that of a recipient, no further MDNs may be issued on behalf of that
recipient, even if another disposition is performed on the message. recipient by the same user agent, even if another disposition is
However, if a message is forwarded, an MDN may have been issued for performed on the message. However, if a message is forwarded, an MDN
the recipient doing the forwarding and the recipient of the forwarded may have been issued for the recipient doing the forwarding and the
message may also cause an MDN to be generated. recipient of the forwarded message may also cause an MDN to be
generated.
It is also possible that if the same message is being accessed by
multiple user agents (for example using POP3), then multiple
dispositions might be generated for the same recipient. User agents
SHOULD laverage support in the underlying message access protocol to
prevent multiple MDNs from being generated. In particular, when the
user agent is accessing the message using RFC-IMAP [13], it SHOULD
implement the procedures specified in RFC-IMAP-MDN [10].
While Internet standards normally do not specify the behavior of user While Internet standards normally do not specify the behavior of user
interfaces, it is strongly recommended that the user agent obtain the interfaces, it is strongly recommended that the user agent obtain the
user's consent before sending an MDN. This consent could be obtained user's consent before sending an MDN. This consent could be obtained
for each message through some sort of prompt or dialog box, or for each message through some sort of prompt or dialog box, or
globally through the user's setting of a preference. globally through the user's setting of a preference.
MDNs SHOULD NOT be sent automatically if the address in the MDNs SHOULD NOT be sent automatically if the address in the
Disposition-Notification-To header field differs from the address in Disposition-Notification-To header field differs from the address in
the Return-Path header field (see RFC-MSGFMT [2]). In this case, the Return-Path header field (see RFC-MSGFMT [2]). In this case,
skipping to change at page 6, line 30 skipping to change at page 6, line 41
The comparison of the addresses should be done using only the addr- The comparison of the addresses should be done using only the addr-
spec (local-part "@" domain) portion, excluding any angle brackets, spec (local-part "@" domain) portion, excluding any angle brackets,
phrase and route. The comparison MUST be case-sensitive for the phrase and route. The comparison MUST be case-sensitive for the
local-part and case-insensitive for the domain part. The local-part local-part and case-insensitive for the domain part. The local-part
comparison SHOULD be done after performing local-part comparison SHOULD be done after performing local-part
canonicalization (i.e. after removing the surrounding double-quote canonicalization (i.e. after removing the surrounding double-quote
characters, if any, as well as any escaping "\" characters. (See characters, if any, as well as any escaping "\" characters. (See
RFC-MSGFMT [2] for more details.) Implementations MAY treat known RFC-MSGFMT [2] for more details.) Implementations MAY treat known
domain aliases as equivalent for the purpose of comparison. domain aliases as equivalent for the purpose of comparison.
Note that use of subaddressing (see [11]) 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. [[ more work needed here ]]
[[CREF1: (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
skipping to change at page 12, line 27 skipping to change at page 12, line 27
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 ]]
[[CREF2: (Here and elsewhere in the document) It looks like there is [[CREF2: (Here and elsewhere in the document) It looks like there is
emerging consensus that the document should describe 2 grammars: one emerging consensus that the document should describe 2 grammars: one
for "must accept" (which allows CFWS) and another one for "should for "must accept" (which allows CFWS) and another one for "should
generate" (CFWS not allowed, but [FWS] are allowed). A future generate" (CFWS not allowed, but [FWS] are allowed). A future
version of this document will implement this change, unless version of this document will implement this change, unless
objections are voiced. ]] objections are voiced. ]]
[[CREF3: ( I see that address-type and mta-name-type uses atom For these fields, the keyword used in the address-type or MTA-type
instead of *text, which not only permits FWS, but goes further to
allow CFWS. Possibilities include switching to: [FWS] *text [FWS],
or switching to the RFC 5321 definition of atom (1*atext). ) ]] 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
atom = <The version from RFC 5321 (not from RFC 5322) is used in this document.>
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
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.
skipping to change at page 22, line 24 skipping to change at page 22, line 24
MDNs do not provide non-repudiation with proof of delivery. Within MDNs do not provide non-repudiation with proof of delivery. Within
the framework of today's Internet Mail, the MDNs defined in this the framework of today's Internet Mail, the MDNs defined in this
document provide valuable information to the mail user; however, MDNs document provide valuable information to the mail user; however, MDNs
cannot be relied upon as a guarantee that a message was or was not cannot be relied upon as a guarantee that a message was or was not
seen by the recipient. Even if MDNs are not actively forged, they seen by the recipient. Even if MDNs are not actively forged, they
may be lost in transit. The recipient may bypass the MDN issuing may be lost in transit. The recipient may bypass the MDN issuing
mechanism in some manner. mechanism in some manner.
One possible solution for this purpose can be found in RFC-SEC- One possible solution for this purpose can be found in RFC-SEC-
SERVICES [10]. SERVICES [11].
6.4. Mail Bombing 6.4. Mail Bombing
The MDN request mechanism introduces an additional way of mailbombing The MDN request mechanism introduces an additional way of mailbombing
a mailbox. The MDN request notification provides an address to which a mailbox. The MDN request notification provides an address to which
MDN's should be sent. It is possible for an attacking agent to send MDN's should be sent. It is possible for an attacking agent to send
a potentially large set of messages to otherwise unsuspecting third a potentially large set of messages to otherwise unsuspecting third
party recipients with a false "disposition-notification-to:" address. party recipients with a false "disposition-notification-to:" address.
Automatic, or simplistic processing of such requests would result in Automatic, or simplistic processing of such requests would result in
a flood of MDN notifications to the target of the attack. Such an a flood of MDN notifications to the target of the attack. Such an
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 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 CRLF, FWS, CFWS, field-name, mailbox, msg-id, text. The following
definitions of attribute and value are as in the definition of the lexical tokens are defined in RFC-SMTP [1]: atom. (Note that RFC-
Content-Type header field in RFC-MIME-BODY [3]. MSGFMT [2] also defines "atom", but the version from RFC-SMTP [1] is
more restrictive and this more restrictive version is used in this
document) The definitions of attribute and value are as in the
definition of the 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 =
"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] "=" [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 =
skipping to change at page 29, line 42 skipping to change at page 29, line 42
Extension for Delivery Status Notifications (DSNs)", RFC Extension for Delivery Status Notifications (DSNs)", RFC
3461, January 2003. 3461, January 2003.
[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, January
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.
[10] Melnikov, A., "Message Disposition Notification (MDN)
profile for Internet Message Access Protocol (IMAP)", RFC
3503, March 2003.
12.2. Informative References 12.2. Informative References
[10] Hoffman, P., "Enhanced Security Services for S/MIME", RFC [11] Hoffman, P., "Enhanced Security Services for S/MIME", RFC
2634, June 1999. 2634, June 1999.
[11] Murchison, K., "Sieve Email Filtering: Subaddress [12] Murchison, K., "Sieve Email Filtering: Subaddress
Extension", RFC 5233, January 2008. Extension", RFC 5233, January 2008.
[13] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, March 2003.
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 29 skipping to change at page 30, line 32
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 [[CREF3: 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.
[[CREF5: Not sure what to do with this one: (From Bruce) In the case [[CREF4: 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 [[CREF5: 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-
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.
[[CREF7: Not sure what to do with this one: (From Bruce) 3.1.1 [[CREF6: 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. ]]
[[CREF8: I think a couple of clarifications are in order: 1) This
restriction is within a given mail user agent. If the user uses
multiple MUAs, it is possible that multiple MDNs MAY be generated.
2) A mail user agent SHOULD use underlying protocol support when
possible to prevent multiple MDNs from being generated. If
underlying protocol support is not available, the mail user agent
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
implementations DO happen. (From Bruce) 3.2.6.3 prohibition against
multiple MDNs being issued on behalf of each recipient poses some
implementation difficulties: *) While IMAP servers maintain state
that could possibly be used to prevent issuance of multiple MDNs, the
POP protocol has no such provision. Even in the case of IMAP, there
is some ambiguity in the case of shared mailboxes. *) Some MUAs are
known to have extreme difficulty keeping track of which messages have
been seen, let alone responded to. Software version updates, minor
configuration changes (e.g. domain name or IP address change of POP
or IMAP server) are known to "confuse" some MUAs. *) there is no
standardized mechanism for communicating status between multiple MUAs
accessing the same mailbox (except in the case of IMAP, as noted
above). Therefore, if an MDN is sent when a message is viewed (etc.)
using one MUA, a different MUA subsequently being used to view the
same message in the same user's mailbox (either via POP, or from a
flat file mailbox) might have no way to determine that an MDN had
already been sent. This is a fundamental difficulty with the
specified protocol (relaxing "MUST NOT" to "SHOULD NOT" is one
possible way around that difficulty -- otherwise the document
contains a "known technical omission" viz. no defined means of
establishing whether or not an MDN has already been sent for a
particular message. I believe that "known technical omissions" are a
barrier to further Standards Track progress). *) Due to aliases,
forwarding, etc. an original message sent to multiple addresses might
end up as multiple copies in a single recipient's mailbox. It is
unclear whether or not multiple MDNs are permitted in that case (the
Message-ID, if present in the original, will be the same in the
copies, and the "particular recipient" could be interpreted as being
the same, even though the addresses specified in the original message
transport envelope might have appeared to have been distinct to the
originator who requested MDNs. ]]
Authors' Addresses Authors' Addresses
Tony Hansen (editor) Tony Hansen (editor)
AT&T Laboratories AT&T Laboratories
200 Laurel Ave. South 200 Laurel Ave. South
Middletown, NJ 07748 Middletown, NJ 07748
USA USA
Email: tony+rfc3798@maillennium.att.com Email: tony+rfc3798@maillennium.att.com
 End of changes. 23 change blocks. 
71 lines changed or deleted 48 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/