draft-ietf-eai-rfc5337bis-dsn-01.txt   draft-ietf-eai-rfc5337bis-dsn-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: 5337 (if approved) C. Newman Obsoletes: 5337 (if approved) C. Newman
Updates: 3461, 3462, 3464, 3798 Sun Microsystems Updates: 3461, 3462, 3464, 3798 Sun Microsystems
(if approved) A. Melnikov (if approved) A. Melnikov
Intended status: Standards Track Isode Ltd Intended status: Standards Track Isode Ltd
Expires: April 28, 2011 October 25, 2010 Expires: October 3, 2011 April 1, 2011
Internationalized Delivery Status and Disposition Notifications Internationalized Delivery Status and Disposition Notifications
draft-ietf-eai-rfc5337bis-dsn-01 draft-ietf-eai-rfc5337bis-dsn-02
Abstract Abstract
Delivery status notifications (DSNs) are critical to the correct Delivery status notifications (DSNs) are critical to the correct
operation of an email system. However, the existing Draft Standards operation of an email system. However, the existing Draft Standards
(RFC 3461, RFC 3462, RFC 3464) are presently limited to US-ASCII text (RFC 3461, RFC 3462, RFC 3464) are presently limited to US-ASCII text
in the machine-readable portions of the protocol. This specification in the machine-readable portions of the protocol. This specification
adds a new address type for international email addresses so an adds a new address type for international email addresses so an
original recipient address with non-US-ASCII characters can be original recipient address with non-US-ASCII characters can be
correctly preserved even after downgrading. This also provides correctly preserved even after downgrading. This also provides
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 28, 2011. This Internet-Draft will expire on October 3, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 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 30 skipping to change at page 2, line 30
3. UTF-8 Address Type . . . . . . . . . . . . . . . . . . . . . . 3 3. UTF-8 Address Type . . . . . . . . . . . . . . . . . . . . . . 3
4. UTF-8 Delivery Status Notifications . . . . . . . . . . . . . 6 4. UTF-8 Delivery Status Notifications . . . . . . . . . . . . . 6
4.1. Additional Requirements on SMTP Servers . . . . . . . . . 9 4.1. Additional Requirements on SMTP Servers . . . . . . . . . 9
5. UTF-8 Message Disposition Notifications . . . . . . . . . . . 9 5. UTF-8 Message Disposition Notifications . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6.1. UTF-8 Mail Address Type Registration . . . . . . . . . . . 11 6.1. UTF-8 Mail Address Type Registration . . . . . . . . . . . 11
6.2. Update to 'smtp' Diagnostic Type Registration . . . . . . 12 6.2. Update to 'smtp' Diagnostic Type Registration . . . . . . 12
6.3. message/global-headers . . . . . . . . . . . . . . . . . . 12 6.3. message/global-headers . . . . . . . . . . . . . . . . . . 12
6.4. message/global-delivery-status . . . . . . . . . . . . . . 13 6.4. message/global-delivery-status . . . . . . . . . . . . . . 13
6.5. message/global-disposition-notification . . . . . . . . . 14 6.5. message/global-disposition-notification . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16
8.2. Informative References . . . . . . . . . . . . . . . . . . 17 8.2. Informative References . . . . . . . . . . . . . . . . . . 17
Appendix A. Changes Since ... . . . . . . . . . . . . . . . . . . 18 Appendix A. Changes Since ... . . . . . . . . . . . . . . . . . . 18
A.1. Changes Since -00 . . . . . . . . . . . . . . . . . . . . 18 A.1. Changes Since -00 . . . . . . . . . . . . . . . . . . . . 18
A.2. Changes Since RFC 5337 . . . . . . . . . . . . . . . . . . 18 A.2. Changes Since RFC 5337 . . . . . . . . . . . . . . . . . . 18
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 18 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
skipping to change at page 3, line 19 skipping to change at page 3, line 19
Headers [I-D.ietf-eai-rfc5335bis], it is sometimes necessary to Headers [I-D.ietf-eai-rfc5335bis], it is sometimes necessary to
return that message or generate a Message Disposition Notification return that message or generate a Message Disposition Notification
(MDN) [RFC3798]. As a message sent to multiple recipients can (MDN) [RFC3798]. As a message sent to multiple recipients can
generate a status and disposition notification for each recipient, it generate a status and disposition notification for each recipient, it
is helpful if a client can correlate these notifications based on the is helpful if a client can correlate these notifications based on the
recipient address it provided; thus, preservation of the original recipient address it provided; thus, preservation of the original
recipient is important. This specification describes how to preserve recipient is important. This specification describes how to preserve
the original recipient and updates the MDN and DSN formats to support the original recipient and updates the MDN and DSN formats to support
the new address types. the new address types.
NOTE: The only issue for which there is (as yet) no consensus yet is NOTE: While this specification updates the experimental versions of
whether to change the name of the Address Type from "UTF-8" to this protocol by removing certain constructs (e.g., the "<addr
something different, such as "UTF8", to reflect the fact that the <addr>>" address syntax is no longer permitted), the name of the
"<addr <addr>>" address syntax is no longer permitted. Address Type "UTF-8" and the media type names message/global,
message/global-delivery-status and message/global-headers have not
NOTE: There was discussion of whether to change the media type names been changed.
from message/global, message/global-delivery-status and message/
global-headers to something else. The apparent consensus was to not
change those names.
2. Conventions Used in This Document 2. Conventions Used in This Document
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 [RFC2119]. document are to be interpreted as described in [RFC2119].
The formal syntax use the Augmented Backus-Naur Form (ABNF) [RFC5234] The formal syntax use the Augmented Backus-Naur Form (ABNF) [RFC5234]
notation including the core rules defined in Appendix B of RFC 5234 notation including the core rules defined in Appendix B of RFC 5234
[RFC5234] and the UTF-8 syntax rules in Section 4 of [RFC3629]. [RFC5234] and the UTF-8 syntax rules in Section 4 of [RFC3629].
skipping to change at page 5, line 8 skipping to change at page 5, line 6
When the ORCPT parameter is placed in a message/ When the ORCPT parameter is placed in a message/
global-delivery-status Original-Recipient field, the 'utf-8-addr- global-delivery-status Original-Recipient field, the 'utf-8-addr-
xtext' form of the UTF-8 address type SHOULD be converted to the xtext' form of the UTF-8 address type SHOULD be converted to the
'utf-8-address' form (see the ABNF below) by removing the 'unitext' 'utf-8-address' form (see the ABNF below) by removing the 'unitext'
encoding. However, if an address is labeled with the UTF-8 address encoding. However, if an address is labeled with the UTF-8 address
type but does not conform to utf-8 syntax, then it MUST be copied type but does not conform to utf-8 syntax, then it MUST be copied
into the message/global-delivery-status field without alteration. into the message/global-delivery-status field without alteration.
The ability to encode characters with the EmbeddedUnicodeChar The ability to encode characters with the EmbeddedUnicodeChar
encodings should be viewed as a transitional mechanism. It is hoped encodings should be viewed as a transitional mechanism and avoided
that as systems lacking support for UTF8SMTP become less common over when possible. It is hoped that as systems lacking support for
time, these encodings can eventually be phased out. UTF8SMTP become less common over time, these encodings can eventually
be phased out.
In the ABNF below, all productions not defined in this document are In the ABNF below, all productions not defined in this document are
defined in Appendix B of [RFC5234], in Section 4 of [RFC3629], or in defined in Appendix B of [RFC5234], in Section 4 of [RFC3629], or in
[RFC3464]. [RFC3464].
utf-8-type-addr = "utf-8;" utf-8-enc-addr utf-8-type-addr = "utf-8;" utf-8-enc-addr
utf-8-address = uMailbox [ 1*WSP "<" Mailbox ">" ] utf-8-address = uMailbox [ 1*WSP "<" Mailbox ">" ]
; uMailbox is defined in [I-D.ietf-eai-rfc5336bis]. ; uMailbox is defined in [I-D.ietf-eai-rfc5336bis].
; Mailbox is defined in [RFC5321]. ; Mailbox is defined in [RFC5321].
skipping to change at page 8, line 29 skipping to change at page 8, line 29
[ last-attempt-date-field CRLF ] [ last-attempt-date-field CRLF ]
[ will-retry-until-field CRLF ] [ will-retry-until-field CRLF ]
*( extension-field CRLF ) *( extension-field CRLF )
; All fields except for "original-recipient-field", ; All fields except for "original-recipient-field",
; "final-recipient-field", "diagnostic-code-field" ; "final-recipient-field", "diagnostic-code-field"
; and "extension-field" remain unchanged from ; and "extension-field" remain unchanged from
; the definition in RFC 3464. ; the definition in RFC 3464.
generic-address =/ utf-8-enc-addr generic-address =/ utf-8-enc-addr
; Only allowed with the "utf-8" address-type. ; Only allowed with the "utf-8" address-type.
; Updates Section 3.2.3 of RFC3798
; ;
; This indirectly updates "original-recipient-field" ; This indirectly updates "original-recipient-field"
; and "final-recipient-field" ; and "final-recipient-field"
diagnostic-code-field = diagnostic-code-field =
"Diagnostic-Code" ":" diagnostic-type ";" *text-fixed "Diagnostic-Code" ":" diagnostic-type ";" *text-fixed
localized-diagnostic-text-field = localized-diagnostic-text-field =
"Localized-Diagnostic" ":" Language-Tag ";" *utf8-text "Localized-Diagnostic" ":" Language-Tag ";" *utf8-text
; "Language-Tag" is a language tag as defined in [LANGTAGS]. ; "Language-Tag" is a language tag as defined in [LANGTAGS].
extension-field =/ extension-field-name ":" *utf8-text extension-field =/ extension-field-name ":" *utf8-text
; Updates Section 7 of RFC3798
text-fixed = %d1-9 / ; Any US-ASCII character except for NUL, text-fixed = %d1-9 / ; Any US-ASCII character except for NUL,
%d11 / ; CR and LF %d11 / ; CR and LF
%d12 / ; See note above about <text-fixed> %d12 / ; See note above about <text-fixed>
%d14-127 %d14-127
utf8-text = text-fixed / UTF8-non-ascii utf8-text = text-fixed / UTF8-non-ascii
UTF8-non-ascii = UTF8-2 / UTF8-3 / UTF8-4 UTF8-non-ascii = UTF8-2 / UTF8-3 / UTF8-4
The second type, used for returning the content, is message/global The second type, used for returning the content, is message/global
which is similar to message/rfc822, except it contains a message with which is similar to message/rfc822, except it contains a message with
UTF-8 headers. This media type is described in UTF-8 headers. This media type is described in
[I-D.ietf-eai-rfc5335bis]. [I-D.ietf-eai-rfc5335bis].
The third type, used for returning the headers, is message/ The third type, used for returning the headers, is message/
global-headers and contains only the UTF-8 header fields of a message global-headers and contains only the UTF-8 header fields of a message
(all lines prior to the first blank line in a UTF8SMTP message). (all lines prior to the first blank line in a UTF8SMTP message).
Unlike message/global, this body part provides no difficulties for Unlike message/global, this body part provides no difficulties for
the present infrastructure. the present infrastructure.
skipping to change at page 11, line 33 skipping to change at page 11, line 33
(c) If addresses of this type are not composed entirely of graphic (c) If addresses of this type are not composed entirely of graphic
characters from the US-ASCII repertoire, a specification for how characters from the US-ASCII repertoire, a specification for how
they are to be encoded as graphic US-ASCII characters in a DSN they are to be encoded as graphic US-ASCII characters in a DSN
Original-Recipient or Final-Recipient DSN field. Original-Recipient or Final-Recipient DSN field.
This address type has 3 forms (as defined in Section 3): utf-8- This address type has 3 forms (as defined in Section 3): utf-8-
addr-xtext, utf-8-addr-unitext, and utf-8-address. Only the addr-xtext, utf-8-addr-unitext, and utf-8-address. Only the
first form is 7-bit safe. first form is 7-bit safe.
The utf-8-address form MUST NOT be used The utf-8-address form MUST NOT be used:
1. in the ORCPT parameter when the SMTP server doesn't advertise 1. in the ORCPT parameter when the SMTP server doesn't advertise
support for UTF8SMTP; support for UTF8SMTP;
2. or the SMTP server supports UTF8SMTP, but the address contains 2. or the SMTP server supports UTF8SMTP, but the address contains
US-ASCII characters not permitted in the ORCPT parameter (e.g., US-ASCII characters not permitted in the ORCPT parameter (e.g.,
the ORCPT parameter forbids SP and the = characters); the ORCPT parameter forbids SP and the = characters);
3. or in a 7-bit transport environment including a message/ 3. or in a 7-bit transport environment including a message/
delivery-status Original-Recipient or Final-Recipient field. delivery-status Original-Recipient or Final-Recipient field.
The utf-8-addr-xtext form MUST be used instead in the first and the The utf-8-addr-xtext form MUST be used instead in the first and the
third case; the utf-8-addr-unitext form MUST be used in the second third case; the utf-8-addr-unitext form MUST be used in the second
case. The utf-8-address form MAY be used in the ORCPT parameter when case.
the SMTP server also advertises support for UTF8SMTP and the address The utf-8-address form MAY be used in the ORCPT parameter when the
SMTP server also advertises support for UTF8SMTP and the address
doesn't contain any US-ASCII characters not permitted in the ORCPT doesn't contain any US-ASCII characters not permitted in the ORCPT
parameter; in a message/global-delivery-status Original-Recipient or parameter; in a message/global-delivery-status Original-Recipient or
Final-Recipient DSN field; or in an Original-Recipient header field Final-Recipient DSN field; or in an Original-Recipient header field
[RFC3798] if the message is a UTF8SMTP message. [RFC3798] if the message is a UTF8SMTP message.
In addition, the utf-8-addr-unitext form can be used anywhere where In addition, the utf-8-addr-unitext form can be used anywhere where
the utf-8-address form is allowed. the utf-8-address form is allowed.
6.2. Update to 'smtp' Diagnostic Type Registration 6.2. Update to 'smtp' Diagnostic Type Registration
The mail diagnostic type registry was created by [RFC3464] and The mail diagnostic type registry was created by [RFC3464] and
updated by [RFC5337]. The registration for the 'smtp' diagnostic updated by [RFC5337]. The registration for the 'smtp' diagnostic
type should be updated to reference RFC XXXX in addition to [RFC3464] type should be updated to reference RFC XXXX in addition to [RFC3464]
skipping to change at page 17, line 34 skipping to change at page 17, line 40
[RFC5322] Resnick, P., Ed., "Internet Message [RFC5322] Resnick, P., Ed., "Internet Message
Format", RFC 5322, October 2008. Format", RFC 5322, October 2008.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF [RFC5234] Crocker, D. and P. Overell, "Augmented BNF
for Syntax Specifications: ABNF", STD 68, for Syntax Specifications: ABNF", STD 68,
RFC 5234, January 2008. RFC 5234, January 2008.
[I-D.ietf-eai-rfc5335bis] Yang, A. and S. Steele, "Internationalized [I-D.ietf-eai-rfc5335bis] Yang, A. and S. Steele, "Internationalized
Email Headers", Email Headers",
draft-ietf-eai-rfc5335bis-03 (work in draft-ietf-eai-rfc5335bis-10 (work in
progress), October 2010. progress), March 2011.
[I-D.ietf-eai-rfc5336bis] Yao, J. and W. MAO, "SMTP Extension for [I-D.ietf-eai-rfc5336bis] Yao, J. and W. MAO, "SMTP Extension for
Internationalized Email Address", Internationalized Email Address",
draft-ietf-eai-rfc5336bis-04 (work in draft-ietf-eai-rfc5336bis-08 (work in
progress), October 2010. progress), March 2011.
8.2. Informative References 8.2. Informative References
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose [RFC2045] Freed, N. and N. Borenstein, "Multipurpose
Internet Mail Extensions (MIME) Part One: Internet Mail Extensions (MIME) Part One:
Format of Internet Message Bodies", Format of Internet Message Bodies",
RFC 2045, November 1996. RFC 2045, November 1996.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose [RFC2046] Freed, N. and N. Borenstein, "Multipurpose
Internet Mail Extensions (MIME) Part Two: Internet Mail Extensions (MIME) Part Two:
Media Types", RFC 2046, November 1996. Media Types", RFC 2046, November 1996.
[RFC5337] Newman, C. and A. Melnikov, [RFC5337] Newman, C. and A. Melnikov,
"Internationalized Delivery Status and "Internationalized Delivery Status and
Disposition Notifications", RFC 5337, Disposition Notifications", RFC 5337,
skipping to change at page 18, line 25 skipping to change at page 18, line 32
Appendix A. Changes Since ... Appendix A. Changes Since ...
A.1. Changes Since -00 A.1. Changes Since -00
Incorporated changes from draft-ietf-eai-dsnbis-01. Incorporated changes from draft-ietf-eai-dsnbis-01.
Fixed description of utf-8-addr-xtext and utf-8-addr-unitext. Fixed description of utf-8-addr-xtext and utf-8-addr-unitext.
Other minor corrections. Other minor corrections.
Incorporated comments by Apps Area reviewers.
A.2. Changes Since RFC 5337 A.2. Changes Since RFC 5337
Made minor changes to move from Experimental to Standards Track. Made changes to move from Experimental to Standards Track. The most
significant was the removal of an embedded alternative ASCII address
within a utf-8-address.
Minor ABNF changes and errata suggested by Alfred Hoenes. ABNF changes and errata suggested by Alfred Hoenes.
Minor changes to MIME type references. Minor changes to MIME type references.
Other minor corrections. Other minor corrections.
Appendix B. Acknowledgements Appendix B. Acknowledgements
Many thanks for input provided by Pete Resnick, James Galvin, Ned Many thanks for input provided by Pete Resnick, James Galvin, Ned
Freed, John Klensin, Harald Alvestrand, Frank Ellermann, SM, Alfred Freed, John Klensin, Harald Alvestrand, Frank Ellermann, SM, Alfred
Hoenes, Kazunori Fujiwara, and members of the EAI WG to help solidify Hoenes, Kazunori Fujiwara, and members of the EAI WG to help solidify
skipping to change at page 19, line 4 skipping to change at page 19, line 14
Authors' Addresses Authors' Addresses
Tony Hansen (editor) Tony Hansen (editor)
AT&T Laboratories AT&T Laboratories
200 Laurel Ave. 200 Laurel Ave.
Middletown, NJ 07748 Middletown, NJ 07748
USA USA
EMail: tony+eaidsn@maillennium.att.com EMail: tony+eaidsn@maillennium.att.com
Chris Newman Chris Newman
Sun Microsystems Sun Microsystems
800 Royal Oaks 800 Royal Oaks
Monrovia, CA 91016-6347 Monrovia, CA 91016-6347
US US
EMail: chris.newman@sun.com EMail: chris.newman@oracle.com
Alexey Melnikov Alexey Melnikov
Isode Ltd Isode Ltd
5 Castle Business Village 5 Castle Business Village
36 Station Road 36 Station Road
Hampton, Middlesex TW12 2BX Hampton, Middlesex TW12 2BX
UK UK
EMail: Alexey.Melnikov@isode.com EMail: Alexey.Melnikov@isode.com
 End of changes. 21 change blocks. 
28 lines changed or deleted 35 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/