draft-ietf-eai-frmwrk-4952bis-03.txt   draft-ietf-eai-frmwrk-4952bis-04.txt 
Email Address Internationalization J. Klensin Email Address Internationalization J. Klensin
(EAI) (EAI)
Internet-Draft Y. Ko Internet-Draft Y. Ko
Obsoletes: RFCs 4952, 5504, 5825 ICU Obsoletes: RFCs 4952, 5504, 5825 ICU
(if approved) August 16, 2010 (if approved) August 20, 2010
Intended status: Informational Intended status: Informational
Expires: February 17, 2011 Expires: February 21, 2011
Overview and Framework for Internationalized Email Overview and Framework for Internationalized Email
draft-ietf-eai-frmwrk-4952bis-03 draft-ietf-eai-frmwrk-4952bis-04
Abstract Abstract
Full use of electronic mail throughout the world requires that, Full use of electronic mail throughout the world requires that
subject to other constraints, people be able to use close variations (subject to other constraints) people be able to use close variations
on their own names, written correctly in their own languages and on their own names (written correctly in their own languages and
scripts, as mailbox names in email addresses. This document scripts) as mailbox names in email addresses. This document
introduces a series of specifications that define mechanisms and introduces a series of specifications that define mechanisms and
protocol extensions needed to fully support internationalized email protocol extensions needed to fully support internationalized email
addresses. These changes include an SMTP extension and extension of addresses. These changes include an SMTP extension and extension of
email header syntax to accommodate UTF-8 data. The document set also email header syntax to accommodate UTF-8 data. The document set also
includes discussion of key assumptions and issues in deploying fully includes discussion of key assumptions and issues in deploying fully
internationalized email. This document is an update of RFC 4952 that internationalized email. This document is an update of RFC 4952; it
reflects additional issues identified since that document was reflects additional issues identified since that document was
published. published.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 February 17, 2011. This Internet-Draft will expire on February 21, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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 12 skipping to change at page 3, line 12
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Role of This Specification . . . . . . . . . . . . . . . . . . 4 2. Role of This Specification . . . . . . . . . . . . . . . . . . 4
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5
4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Mail User and Mail Transfer Agents . . . . . . . . . . . . 6 4.1. Mail User and Mail Transfer Agents . . . . . . . . . . . . 6
4.2. Address Character Sets . . . . . . . . . . . . . . . . . . 6 4.2. Address Character Sets . . . . . . . . . . . . . . . . . . 7
4.3. User Types . . . . . . . . . . . . . . . . . . . . . . . . 7 4.3. User Types . . . . . . . . . . . . . . . . . . . . . . . . 7
4.4. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.4. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.5. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . 8 4.5. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . 8
4.6. Conventional Message and Internationalized Message . . . . 8 4.6. Conventional Message and Internationalized Message . . . . 8
4.7. Undeliverable Messages and Notification . . . . . . . . . 8 4.7. Undeliverable Messages, Notification, and Delivery
5. Overview of the Approach and Document Plan . . . . . . . . . . 8 Receipts . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Overview of the Approach and Document Plan . . . . . . . . . . 9
6. Review of Experimental Results . . . . . . . . . . . . . . . . 9 6. Review of Experimental Results . . . . . . . . . . . . . . . . 9
7. Overview of Protocol Extensions and Changes . . . . . . . . . 10 7. Overview of Protocol Extensions and Changes . . . . . . . . . 10
7.1. SMTP Extension for Internationalized Email Address . . . . 10 7.1. SMTP Extension for Internationalized Email Address . . . . 10
7.2. Transmission of Email Header Fields in UTF-8 Encoding . . 11 7.2. Transmission of Email Header Fields in UTF-8 Encoding . . 11
7.3. SMTP Service Extension for DSNs . . . . . . . . . . . . . 12 7.3. SMTP Service Extension for DSNs . . . . . . . . . . . . . 12
8. Downgrading before and after SMTP Transactions . . . . . . . . 12 8. Downgrading before and after SMTP Transactions . . . . . . . . 12
8.1. Downgrading before or during Message Submission . . . . . 13 8.1. Downgrading before or during Message Submission . . . . . 13
8.2. Downgrading or Other Processing After Final SMTP 8.2. Downgrading or Other Processing After Final SMTP
Delivery . . . . . . . . . . . . . . . . . . . . . . . . . 14 Delivery . . . . . . . . . . . . . . . . . . . . . . . . . 14
9. Downgrading in Transit . . . . . . . . . . . . . . . . . . . . 14 9. Downgrading in Transit . . . . . . . . . . . . . . . . . . . . 14
10. User Interface and Configuration Issues . . . . . . . . . . . 15 10. User Interface and Configuration Issues . . . . . . . . . . . 15
10.1. Choices of Mailbox Names and Unicode Normalization . . . . 15 10.1. Choices of Mailbox Names and Unicode Normalization . . . . 15
11. Additional Issues . . . . . . . . . . . . . . . . . . . . . . 16 11. Additional Issues . . . . . . . . . . . . . . . . . . . . . . 16
11.1. Impact on URIs and IRIs . . . . . . . . . . . . . . . . . 16 11.1. Impact on URIs and IRIs . . . . . . . . . . . . . . . . . 16
11.2. Use of Email Addresses as Identifiers . . . . . . . . . . 16 11.2. Use of Email Addresses as Identifiers . . . . . . . . . . 16
11.3. Encoded Words, Signed Messages, and Downgrading . . . . . 17 11.3. Encoded Words, Signed Messages, and Downgrading . . . . . 17
11.4. LMTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 11.4. LMTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
11.5. Other Uses of Local Parts . . . . . . . . . . . . . . . . 17 11.5. Other Uses of Local Parts . . . . . . . . . . . . . . . . 18
11.6. Non-Standard Encapsulation Formats . . . . . . . . . . . . 18 11.6. Non-Standard Encapsulation Formats . . . . . . . . . . . . 18
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
13. Security Considerations . . . . . . . . . . . . . . . . . . . 18 13. Security Considerations . . . . . . . . . . . . . . . . . . . 18
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
15.1. Normative References . . . . . . . . . . . . . . . . . . . 20 15.1. Normative References . . . . . . . . . . . . . . . . . . . 20
15.2. Informative References . . . . . . . . . . . . . . . . . . 22 15.2. Informative References . . . . . . . . . . . . . . . . . . 22
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 25 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 26
A.1. Changes between -00 and -01 . . . . . . . . . . . . . . . 25 A.1. Changes between -00 and -01 . . . . . . . . . . . . . . . 26
A.2. Changes between -01 and -02 . . . . . . . . . . . . . . . 26 A.2. Changes between -01 and -02 . . . . . . . . . . . . . . . 26
A.3. Changes between -02 and -03 . . . . . . . . . . . . . . . 27 A.3. Changes between -02 and -03 . . . . . . . . . . . . . . . 27
A.4. Changes between -02 and -03 . . . . . . . . . . . . . . . 28
1. Introduction 1. Introduction
Note in Draft and to RFC Editor: The keyword represented in this Note in Draft and to RFC Editor: The keyword represented in this
document by "UTF8SMTPbis" (and in the XML source by &EAISMTPkeyword;) document by "UTF8SMTPbis" (and in the XML source by &EAISMTPkeyword;)
is a placeholder. The actual keyword will be assigned when the is a placeholder. The actual keyword will be assigned when the
standards track SMTP extension in this series [RFC5336bis-SMTP] is standards track SMTP extension in this series [RFC5336bis-SMTP] is
approved for publication and should be substituted here. This approved for publication and should be substituted here. This
paragraph should be treated as normative reference to that SMTP paragraph should be treated as normative reference to that SMTP
extension draft, creating a reference hold until it is approved by extension draft, creating a reference hold until it is approved by
skipping to change at page 4, line 35 skipping to change at page 4, line 35
message header fields to accommodate non-ASCII data. However, it message header fields to accommodate non-ASCII data. However, it
does not permit the use of email addresses that include non-ASCII does not permit the use of email addresses that include non-ASCII
characters. Without the extensions defined here, or some equivalent characters. Without the extensions defined here, or some equivalent
set, the only way to incorporate non-ASCII characters in any part of set, the only way to incorporate non-ASCII characters in any part of
email addresses is to use RFC 2047 coding to embed them in what RFC email addresses is to use RFC 2047 coding to embed them in what RFC
5322 [RFC5322] calls the "display name" (known as a "name phrase" or 5322 [RFC5322] calls the "display name" (known as a "name phrase" or
by other terms elsewhere) of the relevant header fields. Information by other terms elsewhere) of the relevant header fields. Information
coded into the display name is invisible in the message envelope and, coded into the display name is invisible in the message envelope and,
for many purposes, is not part of the address at all. for many purposes, is not part of the address at all.
This document is an update of RFC 4952 [RFC4952] that reflects This document is an update of RFC 4952 [RFC4952]; it reflects
additional issues, shared terminology, and some architectural changes additional issues, shared terminology, and some architectural changes
identified since that document was published. identified since that document was published.
The pronouns "he" and "she" are used interchangeably to indicate a The pronouns "he" and "she" are used interchangeably to indicate a
human of indeterminate gender. human of indeterminate gender.
The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED",
and "MAY" in this document are to be interpreted as described in RFC and "MAY" in this document are to be interpreted as described in RFC
2119 [RFC2119]. 2119 [RFC2119].
skipping to change at page 5, line 18 skipping to change at page 5, line 18
of the documents and the relationships among them appear in Section 5 of the documents and the relationships among them appear in Section 5
and a discussion of what was learned from the Experimental protocols and a discussion of what was learned from the Experimental protocols
and their implementations appears in Section 6. and their implementations appears in Section 6.
Taken together, these specifications provide the details for a way to Taken together, these specifications provide the details for a way to
implement and support internationalized email. The document itself implement and support internationalized email. The document itself
describes how the various elements of email internationalization fit describes how the various elements of email internationalization fit
together and the relationships among the primary specifications together and the relationships among the primary specifications
associated with message transport, header formats, and handling. associated with message transport, header formats, and handling.
This document, and others that comprise the collection described
above, assume a reasonable familiarity with the basic Internet
electronic mail specifications and terminology [RFC5321][RFC5322] and
the MIME [RFC2045] and 8BITMIME [RFC1652] ones as well. While not
strictly required to implement this specification, a general
familiarity with the terminology and functions of IDNA
[RFC5890][RFC5891] [RFC5892][RFC5893] [RFC5894] are also assumed.
3. Problem Statement 3. Problem Statement
Internationalizing Domain Names in Applications (IDNA) [RFC5890] Internationalizing Domain Names in Applications (IDNA) [RFC5890]
permits internationalized domain names, but deployment has not yet permits internationalized domain names, but deployment has not yet
reached most users. One of the reasons for this is that we do not reached most users. One of the reasons for this is that we do not
yet have fully internationalized naming schemes. Domain names are yet have fully internationalized naming schemes. Domain names are
just one of the various names and identifiers that are required to be just one of the various names and identifiers that are required to be
internationalized. In many contexts, until more of those identifiers internationalized. In many contexts, until more of those identifiers
are internationalized, internationalized domain names alone have are internationalized, internationalized domain names alone have
little value. little value.
skipping to change at page 6, line 11 skipping to change at page 6, line 19
adequate, a workaround-based approach may result in an assortment of adequate, a workaround-based approach may result in an assortment of
implementations with different sets of patches and workarounds having implementations with different sets of patches and workarounds having
been applied with consequent user confusion about what is actually been applied with consequent user confusion about what is actually
usable and supported. Instead, we need to build a fully usable and supported. Instead, we need to build a fully
internationalized email environment, focusing on permitting efficient internationalized email environment, focusing on permitting efficient
communication among those who share a language or other community. communication among those who share a language or other community.
That, in turn, implies changes to the mail header environment to That, in turn, implies changes to the mail header environment to
permit the full range of Unicode characters where that makes sense, permit the full range of Unicode characters where that makes sense,
an SMTP Extension to permit UTF-8 [RFC3629] [RFC5198] mail addressing an SMTP Extension to permit UTF-8 [RFC3629] [RFC5198] mail addressing
and delivery of those extended header fields, support for and delivery of those extended header fields, support for
internationalized delivery and service notifications [RFC3461] internationalization of delivery and service notifications [RFC3461]
[RFC3464], and (finally) a requirement for support of the 8BITMIME [RFC3464], and (finally) a requirement for support of the 8BITMIME
SMTP Extension [RFC1652] so that all of these can be transported SMTP Extension [RFC1652] so that all of these can be transported
through the mail system without having to overcome the limitation through the mail system without having to overcome the limitation
that header fields do not have content-transfer-encodings. that header fields do not have content-transfer-encodings.
4. Terminology 4. Terminology
This document assumes a reasonable understanding of the protocols and This document assumes a reasonable understanding of the protocols and
terminology of the core email standards as documented in [RFC5321] terminology of the core email standards as documented in [RFC5321]
and [RFC5322]. and [RFC5322].
skipping to change at page 7, line 29 skipping to change at page 7, line 37
all "all-ASCII" addresses and the set of all "non-ASCII" addresses all "all-ASCII" addresses and the set of all "non-ASCII" addresses
are mutually exclusive. The set of all addresses permitted when are mutually exclusive. The set of all addresses permitted when
UTF8SMTPbis appears is the union of these two sets. UTF8SMTPbis appears is the union of these two sets.
4.3. User Types 4.3. User Types
An "ASCII user" (i) exclusively uses email addresses that contain An "ASCII user" (i) exclusively uses email addresses that contain
ASCII characters only, and (ii) cannot generate recipient addresses ASCII characters only, and (ii) cannot generate recipient addresses
that contain non-ASCII characters. that contain non-ASCII characters.
An "i18mail user" has one or more non-ASCII email addresses. Such a An "i18mail user" has one or more non-ASCII email addresses, or is
user may have ASCII addresses too; if the user has more than one able to generate recipient addresses that contain non-ASCII
email account and a corresponding address, or more than one alias for characters. Such a user may have ASCII addresses too; if the user
the same address, he or she has some method to choose which address has more than one email account and a corresponding address, or more
to use on outgoing email. Note that under this definition, it is not than one alias for the same address, he or she has some method to
possible to tell from an ASCII address if the owner of that address choose which address to use on outgoing email. Note that under this
is an i18mail user or not. (A non-ASCII address implies a belief definition, it is not possible to tell from an ASCII address if the
that the owner of that address is an i18mail user.) There is no such owner of that address is an i18mail user or not. (A non-ASCII
thing as an "i18mail message"; the term applies only to users and address implies a belief that the owner of that address is an i18mail
their agents and capabilities. In particular, the use of non-ASCII user.) There is no such thing as an "i18mail message"; the term
message content is an integral part of the MIME specifications applies only to users and their agents and capabilities. In
[RFC2045] and does not require these extensions (although it is particular, the use of non-ASCII message content is an integral part
compatible with them). of the MIME specifications [RFC2045] and does not require these
extensions (although it is compatible with them).
4.4. Messages 4.4. Messages
A "message" is sent from one user (sender) using a particular email A "message" is sent from one user (sender) using a particular email
address to one or more other recipient email addresses (often address to one or more other recipient email addresses (often
referred to just as "users" or "recipient users"). referred to just as "users" or "recipient users").
4.5. Mailing Lists 4.5. Mailing Lists
A "mailing list" is a mechanism whereby a message may be distributed A "mailing list" is a mechanism whereby a message may be distributed
skipping to change at page 8, line 33 skipping to change at page 8, line 39
o A conventional message is one that does not use any extension o A conventional message is one that does not use any extension
defined in the SMTP extension document [RFC5336] or in the defined in the SMTP extension document [RFC5336] or in the
UTF8header specification [RFC5335], and is strictly conformant to UTF8header specification [RFC5335], and is strictly conformant to
RFC 5322 [RFC5322]. RFC 5322 [RFC5322].
o An internationalized message is a message utilizing one or more of o An internationalized message is a message utilizing one or more of
the extensions defined in this set of specifications, so that it the extensions defined in this set of specifications, so that it
is no longer conformant to the traditional specification of an is no longer conformant to the traditional specification of an
email message or its transport. email message or its transport.
4.7. Undeliverable Messages and Notification 4.7. Undeliverable Messages, Notification, and Delivery Receipts
As specified in RFC 5321, a message that is undeliverable for some As specified in RFC 5321, a message that is undeliverable for some
reason is expected to result in notification to the sender. This can reason is expected to result in notification to the sender. This can
occur in either of two ways. One, typically called "Rejection", occur in either of two ways. One, typically called "Rejection",
occurs when an SMTP server returns a reply code indicating a fatal occurs when an SMTP server returns a reply code indicating a fatal
error (a "5yz" code) or persistently returns a temporary failure error (a "5yz" code) or persistently returns a temporary failure
error (a "4yz" code). The other involves accepting the message error (a "4yz" code). The other involves accepting the message
during SMTP processing and then generating a message to the sender, during SMTP processing and then generating a message to the sender,
typically known as a "Non-delivery Notification" or "NDN". Current typically known as a "Non-delivery Notification" or "NDN". Current
practice often favors rejection over NDNs because of the reduced practice often favors rejection over NDNs because of the reduced
likelihood that the generation of NDNs will be used as a spamming likelihood that the generation of NDNs will be used as a spamming
technique. The latter, NDN, case is unavoidable if an intermediate technique. The latter, NDN, case is unavoidable if an intermediate
MTA accepts a message that is then rejected by the next-hop server. MTA accepts a message that is then rejected by the next-hop server.
A sender may also explicitly request message receipts [RFC3461] that
raise the same issues for these internationalization extensions as
NDNs.
5. Overview of the Approach and Document Plan 5. Overview of the Approach and Document Plan
This set of specifications changes both SMTP and the character This set of specifications changes both SMTP and the character
encoding of email message headers to permit non-ASCII characters to encoding of email message headers to permit non-ASCII characters to
be represented directly. Each important component of the work is be represented directly. Each important component of the work is
described in a separate document. The document set, whose members described in a separate document. The document set, whose members
are described below, also contains informational documents whose are described below, also contains informational documents whose
purpose is to provide implementation suggestions and guidance for the purpose is to provide implementation suggestions and guidance for the
protocols. protocols.
skipping to change at page 11, line 38 skipping to change at page 11, line 46
the user will inevitably, if only occasionally, see them rather than the user will inevitably, if only occasionally, see them rather than
"native" characters and will find that discomfiting or astonishing. "native" characters and will find that discomfiting or astonishing.
Similarly, if different codings are used for mail transport and Similarly, if different codings are used for mail transport and
message bodies, the user is particularly likely to be surprised, if message bodies, the user is particularly likely to be surprised, if
only as a consequence of the long-established "things leak" only as a consequence of the long-established "things leak"
principle. The only practical way to avoid these sources of principle. The only practical way to avoid these sources of
discomfort, in both the medium and the longer term, is to have the discomfort, in both the medium and the longer term, is to have the
encodings used in transport be as similar to the encodings used in encodings used in transport be as similar to the encodings used in
message headers and message bodies as possible. message headers and message bodies as possible.
When email local parts are internationalized, it seems clear that When email local parts are internationalized, they should be
they should be accompanied by arrangements for the message headers to accompanied by arrangements for the message headers to be in the
be in the fully internationalized form. That form should presumably fully internationalized form. That form should presumably use UTF-8
use UTF-8 rather than ASCII as the base character set for the rather than ASCII as the base character set for the contents of
contents of header fields (protocol elements such as the header field header fields (protocol elements such as the header field names
names themselves are unchanged and remain entirely in ASCII). For themselves are unchanged and remain entirely in ASCII). For
transition purposes and compatibility with legacy systems, this can transition purposes and compatibility with legacy systems, this can
done by extending the traditional MIME encoding models for non-ASCII done by extending the traditional MIME encoding models for non-ASCII
characters in headers [RFC2045] [RFC2231]. However, the target is characters in headers [RFC2045] [RFC2231]. However, the target is
fully internationalized message headers, as discussed in fully internationalized message headers, as discussed in
[RFC5335bis-Hdrs] and not an extended and painful transition. [RFC5335bis-Hdrs] and not an extended and painful transition.
7.3. SMTP Service Extension for DSNs 7.3. SMTP Service Extension for DSNs
The existing Draft Standard Delivery status notifications (DSNs) The existing Draft Standard Delivery status notifications (DSNs)
specification [RFC3461] is limited to ASCII text in the machine specification [RFC3461] is limited to ASCII text in the machine
skipping to change at page 13, line 5 skipping to change at page 13, line 10
transmission chain does not. It is important to note that most cases transmission chain does not. It is important to note that most cases
of that situation with forward-pointing addresses will be the result of that situation with forward-pointing addresses will be the result
of configuration errors: especially if it hosts non-ASCII addresses, of configuration errors: especially if it hosts non-ASCII addresses,
a final delivery MTA that accepts these extensions should not be a final delivery MTA that accepts these extensions should not be
configured with lower-preference MX hosts that do not. When the only configured with lower-preference MX hosts that do not. When the only
non-ASCII address being transmitted is backward-pointing (e.g., in an non-ASCII address being transmitted is backward-pointing (e.g., in an
SMTP MAIL command), recipient configuration can not help in general. SMTP MAIL command), recipient configuration can not help in general.
On the other hand, alternate, all-ASCII, addresses for senders are On the other hand, alternate, all-ASCII, addresses for senders are
those most likely to be authoritatively known by the submission those most likely to be authoritatively known by the submission
environment or the sender herself. Consequently, if an intermediate environment or the sender herself. Consequently, if an intermediate
SMTP relay that is transmitting a message that requires these SMTP relay that requires these extensions then discovers that the
extensions and discovers that the next system in the chain does not next system in the chain does not support them, it will have little
support them, it will have little choice other than to reject or choice other than to reject or return the message.
return the message.
As discussed above, downgrading to an ASCII-only form may occur As discussed above, downgrading to an ASCII-only form may occur
before or during the initial message submission. It might also occur before or during the initial message submission. It might also occur
after the delivery to the final delivery MTA in order to accommodate after the delivery to the final delivery MTA in order to accommodate
messages stores or IMAP or POP servers or clients that have different messages stores or IMAP or POP servers or clients that have different
capabilities than the delivery MTA. These two cases are discussed in capabilities than the delivery MTA. These two cases are discussed in
the subsections below. the subsections below.
8.1. Downgrading before or during Message Submission 8.1. Downgrading before or during Message Submission
skipping to change at page 13, line 50 skipping to change at page 14, line 6
including changing backward-pointing addresses, contacting the including changing backward-pointing addresses, contacting the
intended recipient out of band for an alternate address, consulting intended recipient out of band for an alternate address, consulting
appropriate directories, arranging for translation of both addresses appropriate directories, arranging for translation of both addresses
and message content into a different language, and so on. While it and message content into a different language, and so on. While it
is natural to think of message downgrading as optimally being a is natural to think of message downgrading as optimally being a
fully-automated process, we should not underestimate the capabilities fully-automated process, we should not underestimate the capabilities
of a user of at least moderate intelligence who wishes to communicate of a user of at least moderate intelligence who wishes to communicate
with another such user. with another such user.
In this context, one can easily imagine modifications to message In this context, one can easily imagine modifications to message
submission servers (as described in [RFC4409]) so that they would submission servers (as described in RFC 4409 [RFC4409]) so that they
perform downgrading, or perhaps even upgrading, operations, receiving would perform downgrading operations or perhaps even upgrading ones.
messages with one or more of the internationalization extensions Such operations would permit receiving messages with one or more of
discussed here and adapting the outgoing message, as needed, to the internationalization extensions discussed here and adapting the
respond to the delivery or next-hop environment it encounters. outgoing message, as needed, to respond to the delivery or next-hop
environment the submission server encounters.
8.2. Downgrading or Other Processing After Final SMTP Delivery 8.2. Downgrading or Other Processing After Final SMTP Delivery
When an email message is received by a final delivery MTA, it is When an email message is received by a final delivery MTA, it is
usually stored in some form. Then it is retrieved either by software usually stored in some form. Then it is retrieved either by software
that reads the stored form directly or by client software via some that reads the stored form directly or by client software via some
email retrieval mechanisms such as POP or IMAP. email retrieval mechanisms such as POP or IMAP.
The SMTP extension described in Section 7.1 provides protection only The SMTP extension described in Section 7.1 provides protection only
in transport. It does not prevent MUAs and email retrieval in transport. It does not prevent MUAs and email retrieval
mechanisms that have not been upgraded to understand mechanisms that have not been upgraded to understand
internationalized addresses and UTF-8 message headers from accessing internationalized addresses and UTF-8 message headers from accessing
stored internationalized emails. stored internationalized emails.
Since the final delivery MTA (or, to be more specific, its Since the final delivery MTA (or, to be more specific, its
corresponding mail storage agent) cannot safely assume that agents corresponding mail storage agent) cannot safely assume that agents
accessing email storage will always be capable of handling the accessing email storage will always be capable of handling the
extensions proposed here, it MAY either downgrade internationalized extensions proposed here, it MAY downgrade internationalized emails,
emails or specially identify messages that utilize these extensions, specially identify messages that utilize these extensions, or both.
or both. If this is done, the final delivery MTA SHOULD include a If this is done, the final delivery MTA SHOULD include a mechanism to
mechanism to preserve or recover the original internationalized forms preserve or recover the original internationalized forms without
without information loss to support access by UTF8SMTPbis-aware information loss to support access by UTF8SMTPbis-aware agents.
agents.
9. Downgrading in Transit 9. Downgrading in Transit
The base SMTP specification (Section 2.3.11 of RFC 5321 [RFC5321]) The base SMTP specification (Section 2.3.11 of RFC 5321 [RFC5321])
states that "due to a long history of problems when intermediate states that "due to a long history of problems when intermediate
hosts have attempted to optimize transport by modifying them, the hosts have attempted to optimize transport by modifying them, the
local-part MUST be interpreted and assigned semantics only by the local-part MUST be interpreted and assigned semantics only by the
host specified in the domain part of the address". This is not a new host specified in the domain part of the address". This is not a new
requirement; equivalent statements appeared in specifications in 2001 requirement; equivalent statements appeared in specifications in 2001
[RFC2821] and even in 1989 [RFC1123]. [RFC2821] and even in 1989 [RFC1123].
skipping to change at page 21, line 6 skipping to change at page 21, line 9
versions with slight modifications, but the versions with slight modifications, but the
1968 version remains definitive for the 1968 version remains definitive for the
Internet. Internet.
[RFC1652] Klensin, J., Freed, N., Rose, M., [RFC1652] Klensin, J., Freed, N., Rose, M.,
Stefferud, E., and D. Crocker, "SMTP Stefferud, E., and D. Crocker, "SMTP
Service Extension for 8bit-MIMEtransport", Service Extension for 8bit-MIMEtransport",
RFC 1652, July 1994. RFC 1652, July 1994.
[RFC2119] Bradner, S., "Key words for use in RFCs to [RFC2119] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels'", RFC 2119, Indicate Requirement Levels", BCP 14,
BCP 14, March 1997. RFC 2119, March 1997.
[RFC3629] Yergeau, F., "UTF-8, a transformation [RFC3629] Yergeau, F., "UTF-8, a transformation
format of ISO 10646", STD 63, RFC 3629, format of ISO 10646", STD 63, RFC 3629,
November 2003. November 2003.
[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.
skipping to change at page 21, line 43 skipping to change at page 21, line 46
[RFC5721bis-POP3] Not yet posted?, "POP3 Support for UTF-8", [RFC5721bis-POP3] Not yet posted?, "POP3 Support for UTF-8",
Unwritten waiting for I-D, 2010. Unwritten waiting for I-D, 2010.
[RFC5738bis-IMAP] Not yet posted?, "IMAP Support for UTF-8", [RFC5738bis-IMAP] Not yet posted?, "IMAP Support for UTF-8",
Unwritten waiting for I-D, 2010. Unwritten waiting for I-D, 2010.
[RFC5890] Klensin, J., "Internationalized Domain [RFC5890] Klensin, J., "Internationalized Domain
Names for Applications (IDNA): Definitions Names for Applications (IDNA): Definitions
and Document Framework", RFC 5890, and Document Framework", RFC 5890,
June 2010. August 2010.
[RFCNNNNbis-MailingList] Not yet posted?, "Mailing Lists and [RFCNNNNbis-MailingList] Not yet posted?, "Mailing Lists and
Internationalized Email Addresses", First Internationalized Email Addresses", First
Version still not in RFC Editor queue https Version still not in RFC Editor queue https
://datatracker.ietf.org/doc/ ://datatracker.ietf.org/doc/
draft-ietf-eai-mailinglist/, draft-ietf-eai-mailinglist/,
Unwritten waiting for I-D, 2010. Unwritten waiting for I-D, 2010.
15.2. Informative References 15.2. Informative References
skipping to change at page 25, line 21 skipping to change at page 25, line 22
[RFC5825] Fujiwara, K. and B. Leiba, "Displaying [RFC5825] Fujiwara, K. and B. Leiba, "Displaying
Downgraded Messages for Email Address Downgraded Messages for Email Address
Internationalization", RFC 5825, Internationalization", RFC 5825,
April 2010. April 2010.
[RFC5863] Hansen, T., Siegel, E., Hallam-Baker, P., [RFC5863] Hansen, T., Siegel, E., Hallam-Baker, P.,
and D. Crocker, "DomainKeys Identified Mail and D. Crocker, "DomainKeys Identified Mail
(DKIM) Development, Deployment, and (DKIM) Development, Deployment, and
Operations", RFC 5863, May 2010. Operations", RFC 5863, May 2010.
[RFC5891] Klensin, J., "Internationalized Domain
Names in Applications (IDNA): Protocol",
RFC 5891, August 2010.
[RFC5892] Faltstrom, P., "The Unicode Code Points and
Internationalized Domain Names for
Applications (IDNA)", RFC 5892,
August 2010.
[RFC5893] Alvestrand, H. and C. Karp, "Right-to-Left [RFC5893] Alvestrand, H. and C. Karp, "Right-to-Left
Scripts for Internationalized Domain Names Scripts for Internationalized Domain Names
for Applications (IDNA)", RFC 5893, for Applications (IDNA)", RFC 5893,
June 2010. August 2010.
[RFC5894] Klensin, J., "Internationalized Domain
Names for Applications (IDNA): Background,
Explanation, and Rationale", RFC 5894,
August 2010.
[Unicode-UAX15] The Unicode Consortium, "Unicode Standard [Unicode-UAX15] The Unicode Consortium, "Unicode Standard
Annex #15: Unicode Normalization Forms", Annex #15: Unicode Normalization Forms",
March 2008, March 2008,
<http://www.unicode.org/reports/tr15/>. <http://www.unicode.org/reports/tr15/>.
[Unicode52] The Unicode Consortium. The Unicode [Unicode52] The Unicode Consortium. The Unicode
Standard, Version 5.2.0, defined by:, "The Standard, Version 5.2.0, defined by:, "The
Unicode Standard, Version 5.2.0", (Mountain Unicode Standard, Version 5.2.0", (Mountain
View, CA: The Unicode Consortium, View, CA: The Unicode Consortium,
skipping to change at page 27, line 39 skipping to change at page 28, line 5
aside to a separate section, Section 6. aside to a separate section, Section 6.
o Rewrote the discussion of configuration errors in MX setups to o Rewrote the discussion of configuration errors in MX setups to
make it clear that they are an issue with forward-pointing make it clear that they are an issue with forward-pointing
addresses only and improved the discussion of backward-pointing addresses only and improved the discussion of backward-pointing
addresses. addresses.
o Removed some now-obsolete placeholder notes and resolved the o Removed some now-obsolete placeholder notes and resolved the
remaining one to a dangling reference. remaining one to a dangling reference.
A.4. Changes between -02 and -03
o Several minor editorial changes.
o Added a discussion of the relationship to the base email, MIME,
and IDNA specifications.
Authors' Addresses Authors' Addresses
John C KLENSIN John C KLENSIN
1770 Massachusetts Ave, #322 1770 Massachusetts Ave, #322
Cambridge, MA 02140 Cambridge, MA 02140
USA USA
Phone: +1 617 491 5735 Phone: +1 617 491 5735
EMail: john-ietf@jck.com EMail: john-ietf@jck.com
YangWoo KO YangWoo KO
ICU ICU
119 Munjiro 119 Munjiro
Yuseong-gu, Daejeon 305-732 Yuseong-gu, Daejeon 305-732
Republic of Korea Republic of Korea
EMail: yw@mrko.pe.kr EMail: yw@mrko.pe.kr
 End of changes. 28 change blocks. 
57 lines changed or deleted 93 lines changed or added

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