draft-ietf-eai-rfc5337bis-dsn-02.txt   draft-ietf-eai-rfc5337bis-dsn-03.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: October 3, 2011 April 1, 2011 Expires: January 13, 2012 July 12, 2011
Internationalized Delivery Status and Disposition Notifications Internationalized Delivery Status and Disposition Notifications
draft-ietf-eai-rfc5337bis-dsn-02 draft-ietf-eai-rfc5337bis-dsn-03
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 October 3, 2011. This Internet-Draft will expire on January 13, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 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
skipping to change at page 2, line 21 skipping to change at page 2, line 21
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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . 3
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 . . . . . . . . . . . . . 7
4.1. Additional Requirements on SMTP Servers . . . . . . . . . 9 4.1. Additional Requirements on SMTP Servers . . . . . . . . . 10
5. UTF-8 Message Disposition Notifications . . . . . . . . . . . 9 5. UTF-8 Message Disposition Notifications . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
6.1. UTF-8 Mail Address Type Registration . . . . . . . . . . . 11 6.1. UTF-8 Mail Address Type Registration . . . . . . . . . . . 12
6.2. Update to 'smtp' Diagnostic Type Registration . . . . . . 12 6.2. Update to 'smtp' Diagnostic Type Registration . . . . . . 13
6.3. message/global-headers . . . . . . . . . . . . . . . . . . 12 6.3. message/global-headers . . . . . . . . . . . . . . . . . . 14
6.4. message/global-delivery-status . . . . . . . . . . . . . . 13 6.4. message/global-delivery-status . . . . . . . . . . . . . . 15
6.5. message/global-disposition-notification . . . . . . . . . 14 6.5. message/global-disposition-notification . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 8.1. Normative References . . . . . . . . . . . . . . . . . . . 18
8.2. Informative References . . . . . . . . . . . . . . . . . . 17 8.2. Informative References . . . . . . . . . . . . . . . . . . 19
Appendix A. Changes Since ... . . . . . . . . . . . . . . . . . . 18 Appendix A. Changes Since ... . . . . . . . . . . . . . . . . . . 19
A.1. Changes Since -00 . . . . . . . . . . . . . . . . . . . . 18 A.1. Changes Since -00 . . . . . . . . . . . . . . . . . . . . 20
A.2. Changes Since RFC 5337 . . . . . . . . . . . . . . . . . . 18 A.2. Changes Since RFC 5337 . . . . . . . . . . . . . . . . . . 20
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 18 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
When an email message is transmitted using the UTF8SMTP When an email message is transmitted using the UTF8SMTP
[I-D.ietf-eai-rfc5336bis] extension and Internationalized Email [I-D.ietf-eai-rfc5336bis] extension and Internationalized Email
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
skipping to change at page 3, line 32 skipping to change at page 3, line 32
Address Type "UTF-8" and the media type names message/global, Address Type "UTF-8" and the media type names message/global,
message/global-delivery-status and message/global-headers have not message/global-delivery-status and message/global-headers have not
been changed. been changed.
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)
notation including the core rules defined in Appendix B of RFC 5234 [RFC5234] notation including the core rules defined in Appendix B of
[RFC5234] and the UTF-8 syntax rules in Section 4 of [RFC3629]. RFC 5234 [RFC5234] and the UTF-8 syntax rules in Section 4 of
[RFC3629].
3. UTF-8 Address Type 3. UTF-8 Address Type
An Extensible Message Format for Delivery Status Notifications An Extensible Message Format for Delivery Status Notifications
[RFC3464] defines the concept of an address type. The address format [RFC3464] defines the concept of an address type. The address format
introduced in Internationalized Email Headers introduced in Internationalized Email Headers
[I-D.ietf-eai-rfc5335bis] is a new address type. The syntax for the [I-D.ietf-eai-rfc5335bis] is a new address type. The syntax for the
new address type in the context of status notifications is specified new address type in the context of status notifications is specified
at the end of this section. at the end of this section.
skipping to change at page 5, line 17 skipping to change at page 5, line 17
when possible. It is hoped that as systems lacking support for when possible. It is hoped that as systems lacking support for
UTF8SMTP become less common over time, these encodings can eventually UTF8SMTP become less common over time, these encodings can eventually
be phased out. 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 = Mailbox
; uMailbox is defined in [I-D.ietf-eai-rfc5336bis].
; Mailbox is defined in [RFC5321]. ; Mailbox as defined in [I-D.ietf-eai-rfc5336bis].
utf-8-enc-addr = utf-8-addr-xtext / utf-8-enc-addr = utf-8-addr-xtext /
utf-8-addr-unitext / utf-8-addr-unitext /
utf-8-address utf-8-address
utf-8-addr-xtext = 1*(QCHAR / EmbeddedUnicodeChar) utf-8-addr-xtext = 1*(QCHAR / EmbeddedUnicodeChar)
; 7bit form of utf-8-addr-unitext. ; 7bit form of utf-8-addr-unitext.
; Safe for use in the ORCPT [RFC3461] ; Safe for use in the ORCPT [RFC3461]
; parameter even when UTF8SMTP SMTP ; parameter even when UTF8SMTP SMTP
; extension is not advertised. ; extension is not advertised.
utf-8-addr-unitext = 1*(QUCHAR / EmbeddedUnicodeChar) utf-8-addr-unitext = 1*(QUCHAR / EmbeddedUnicodeChar)
; MUST follow utf-8-address ABNF when ; MUST follow utf-8-address ABNF when
; dequoted. ; dequoted.
; Safe for using in the ORCPT [RFC3461] ; Safe for using in the ORCPT [RFC3461]
; parameter when UTF8SMTP SMTP extension ; parameter when UTF8SMTP SMTP extension
; is also advertised. ; is also advertised.
QCHAR = %x21-2a / %x2c-3c / %x3e-5b / %x5d-7e QCHAR = %x21-2a / %x2c-3c / %x3e-5b / %x5d-7e
; US-ASCII printable characters except ; US-ASCII printable characters except
; CTLs, SP, '\', '+', '='. ; CTLs, SP, '\', '+', '='.
QUCHAR = QCHAR / UTF8-2 / UTF8-3 / UTF8-4 QUCHAR = QCHAR / UTF8-2 / UTF8-3 / UTF8-4
; US-ASCII printable characters except ; US-ASCII printable characters except
; CTLs, SP, '\', '+' and '=', plus ; CTLs, SP, '\', '+' and '=', plus
; other Unicode characters encoded in UTF-8 ; other Unicode characters encoded in UTF-8
EmbeddedUnicodeChar = %x5C.78 "{" HEXPOINT "}" EmbeddedUnicodeChar = %x5C.78 "{" HEXPOINT "}"
; starts with "\x" ; starts with "\x"
HEXPOINT = ( ( "0"/"1" ) %x31-39 ) / "10" / "20" / HEXPOINT = ( ( "0"/"1" ) %x31-39 ) / "10" / "20" /
"2B" / "3D" / "7F" / ; all xtext-specials "2B" / "3D" / "7F" / ; all xtext-specials
"5C" / (HEXDIG8 HEXDIG) / ; 2 digit forms "5C" / (HEXDIG8 HEXDIG) / ; 2 digit forms
( NZHEXDIG 2(HEXDIG) ) / ; 3 digit forms ( NZHEXDIG 2(HEXDIG) ) / ; 3 digit forms
( NZDHEXDIG 3(HEXDIG) ) / ; 4 digit forms excluding ( NZDHEXDIG 3(HEXDIG) ) / ; 4 digit forms excluding
( "D" %x30-37 2(HEXDIG) ) / ; ... surrogate ( "D" %x30-37 2(HEXDIG) ) / ; ... surrogate
( NZHEXDIG 4(HEXDIG) ) / ; 5 digit forms ( NZHEXDIG 4(HEXDIG) ) / ; 5 digit forms
( "10" 4*HEXDIG ) ; 6 digit forms ( "10" 4*HEXDIG ) ; 6 digit forms
; represents either "\" or a Unicode code point outside ; represents either "\" or a Unicode code point outside
; the US-ASCII repertoire ; the US-ASCII repertoire
HEXDIG8 = %x38-39 / "A" / "B" / "C" / "D" / "E" / "F" HEXDIG8 = %x38-39 / "A" / "B" / "C" / "D" / "E" / "F"
; HEXDIG excluding 0-7 ; HEXDIG excluding 0-7
NZHEXDIG = %x31-39 / "A" / "B" / "C" / "D" / "E" / "F" NZHEXDIG = %x31-39 / "A" / "B" / "C" / "D" / "E" / "F"
; HEXDIG excluding "0" ; HEXDIG excluding "0"
NZDHEXDIG = %x31-39 / "A" / "B" / "C" / "E" / "F" NZDHEXDIG = %x31-39 / "A" / "B" / "C" / "E" / "F"
; HEXDIG excluding "0" and "D" ; HEXDIG excluding "0" and "D"
4. UTF-8 Delivery Status Notifications 4. UTF-8 Delivery Status Notifications
A traditional delivery status notification [RFC3464] comes in a A traditional delivery status notification [RFC3464] comes in a
three-part multipart/report [RFC3462] container, where the first part three-part multipart/report [RFC3462] container, where the first part
is human-readable text describing the error, the second part is a is human-readable text describing the error, the second part is a
7-bit-only message/delivery-status, and the optional third part is 7-bit-only message/delivery-status, and the optional third part is
used for content (message/rfc822) or header (text/rfc822-headers) used for content (message/rfc822) or header (text/rfc822-headers)
return. As the present DSN format does not permit returning of return. As the present DSN format does not permit returning of
skipping to change at page 9, line 40 skipping to change at page 10, line 45
MIME [RFC2046] regarding use of Content-Transfer-Encoding in new MIME [RFC2046] regarding use of Content-Transfer-Encoding in new
"message" subtypes. This specification explicitly allows use of "message" subtypes. This specification explicitly allows use of
Content-Transfer-Encoding in message/global-headers and message/ Content-Transfer-Encoding in message/global-headers and message/
global-delivery-status. This is not believed to be problematic as global-delivery-status. This is not believed to be problematic as
these new media types are intended primarily for use by newer systems these new media types are intended primarily for use by newer systems
with full support for 8-bit MIME and UTF-8 headers. with full support for 8-bit MIME and UTF-8 headers.
4.1. Additional Requirements on SMTP Servers 4.1. Additional Requirements on SMTP Servers
If an SMTP server that advertises both UTF8SMTP and DSN needs to If an SMTP server that advertises both UTF8SMTP and DSN needs to
return an undeliverable UTF8SMTP message, then it MUST NOT downgrade return an undeliverable UTF8SMTP message, then it has two choices for
[RFC5504] the UTF8SMTP message when generating the corresponding encapsulating the UTF8SMTP message when generating the corresponding
multipart/report. If the return path SMTP server does not support multipart/report:
UTF8SMTP, then the undeliverable body part and headers MUST be
encoded using a 7-bit Content-Transfer-Encoding such as "base64" or If the return path SMTP server does not support UTF8SMTP, then the
"quoted-printable" [RFC2045], as detailed in Section 4. Otherwise, undeliverable body part and headers MUST be encoded using a 7-bit
"8bit" Content-Transfer-Encoding can be used. Content-Transfer-Encoding such as "base64" or "quoted-printable"
[RFC2045], as detailed in Section 4.
Otherwise, "8bit" Content-Transfer-Encoding can be used.
5. UTF-8 Message Disposition Notifications 5. UTF-8 Message Disposition Notifications
Message Disposition Notifications [RFC3798] have a similar design and Message Disposition Notifications [RFC3798] have a similar design and
structure to DSNs. As a result, they use the same basic return structure to DSNs. As a result, they use the same basic return
format. When generating an MDN for a UTF-8 header message, the third format. When generating an MDN for a UTF-8 header message, the third
part of the multipart/report contains the returned content (message/ part of the multipart/report contains the returned content (message/
global) or header (message/global-headers), same as for DSNs. The global) or header (message/global-headers), same as for DSNs. The
second part of the multipart/report uses a new media type, message/ second part of the multipart/report uses a new media type, message/
global-disposition-notification, which has the syntax of message/ global-disposition-notification, which has the syntax of message/
skipping to change at page 17, line 38 skipping to change at page 19, line 17
[RFC5321] Klensin, J., "Simple Mail Transfer [RFC5321] Klensin, J., "Simple Mail Transfer
Protocol", RFC 5321, October 2008. Protocol", RFC 5321, October 2008.
[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., Steele, S., and N. Freed,
Email Headers", "Internationalized Email Headers",
draft-ietf-eai-rfc5335bis-10 (work in draft-ietf-eai-rfc5335bis-11 (work in
progress), March 2011. progress), July 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",
draft-ietf-eai-rfc5336bis-08 (work in draft-ietf-eai-rfc5336bis-11 (work in
progress), March 2011. progress), July 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 26 skipping to change at page 20, line 7
[RFC5504] Fujiwara, K. and Y. Yoneya, "Downgrading [RFC5504] Fujiwara, K. and Y. Yoneya, "Downgrading
Mechanism for Email Address Mechanism for Email Address
Internationalization", RFC 5504, Internationalization", RFC 5504,
March 2009. March 2009.
Appendix A. Changes Since ... Appendix A. Changes Since ...
A.1. Changes Since -00 A.1. Changes Since -00
NOTE TO RFC EDITOR: Remove this section for publication.
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. Incorporated comments by Apps Area reviewers.
References to Downgrade and uMailbox removed/fixed.
A.2. Changes Since RFC 5337 A.2. Changes Since RFC 5337
Made changes to move from Experimental to Standards Track. The most Made changes to move from Experimental to Standards Track. The most
significant was the removal of an embedded alternative ASCII address significant was the removal of an embedded alternative ASCII address
within a utf-8-address. within a utf-8-address, and reflections of the ABNF changes in
[I-D.ietf-eai-rfc5336bis].
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
 End of changes. 42 change blocks. 
43 lines changed or deleted 80 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/