draft-ietf-eai-frmwrk-4952bis-00.txt   draft-ietf-eai-frmwrk-4952bis-01.txt 
Email Address Internationalization J. Klensin Email Address Internationalization J. Klensin
(EAI) (EAI)
Internet-Draft Y. Ko Internet-Draft Y. Ko
Obsoletes: RFC4952 ICU Obsoletes: RFC4952 ICU
(if approved) June 25, 2010 (if approved) July 3, 2010
Intended status: Informational Intended status: Informational
Expires: December 27, 2010 Expires: January 4, 2011
Overview and Framework for Internationalized Email Overview and Framework for Internationalized Email
draft-ietf-eai-frmwrk-4952bis-00 draft-ietf-eai-frmwrk-4952bis-01
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
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 December 27, 2010. This Internet-Draft will expire on January 4, 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 16 skipping to change at page 3, line 16
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 . . . . . . . . . . . . . . . . . . 7 4.2. Address Character Sets . . . . . . . . . . . . . . . . . . 7
4.3. User Types . . . . . . . . . . . . . . . . . . . . . . . . 7 4.3. User Types . . . . . . . . . . . . . . . . . . . . . . . . 7
4.4. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.4. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.5. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . 8 4.5. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . 8
4.6. Conventional Message and Internationalized Message . . . . 8 4.6. Undeliverable Messages and Notification . . . . . . . . . 8
4.7. Undeliverable Messages and Notification . . . . . . . . . 8 5. Overview of the Approach . . . . . . . . . . . . . . . . . . . 8
5. Overview of the Approach . . . . . . . . . . . . . . . . . . . 9
6. Document Plan . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Document Plan . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Overview of Protocol Extensions and Changes . . . . . . . . . 9 7. Overview of Protocol Extensions and Changes . . . . . . . . . 9
7.1. SMTP Extension for Internationalized Email Address . . . . 9 7.1. SMTP Extension for Internationalized Email Address . . . . 9
7.2. Transmission of Email Header Fields in UTF-8 Encoding . . 11 7.2. Transmission of Email Header Fields in UTF-8 Encoding . . 10
8. Downgrading before and after SMTP Transactions . . . . . . . . 11 8. Downgrading before and after SMTP Transactions . . . . . . . . 11
8.1. Downgrading before or during Message Submission . . . . . 12 8.1. Downgrading before or during Message Submission . . . . . 12
8.2. Downgrading or Other Processing After Final SMTP 8.2. Downgrading or Other Processing After Final SMTP
Delivery . . . . . . . . . . . . . . . . . . . . . . . . . 13 Delivery . . . . . . . . . . . . . . . . . . . . . . . . . 13
9. Downgrading in Transit . . . . . . . . . . . . . . . . . . . . 13 9. Downgrading in Transit . . . . . . . . . . . . . . . . . . . . 13
10. User Interface and Configuration Issues . . . . . . . . . . . 13 10. User Interface and Configuration Issues . . . . . . . . . . . 13
10.1. Choices of Mailbox Names and Unicode Normalization . . . . 14 10.1. Choices of Mailbox Names and Unicode Normalization . . . . 14
11. Additional Issues . . . . . . . . . . . . . . . . . . . . . . 15 11. Additional Issues . . . . . . . . . . . . . . . . . . . . . . 15
11.1. Impact on URIs and IRIs . . . . . . . . . . . . . . . . . 15 11.1. Impact on URIs and IRIs . . . . . . . . . . . . . . . . . 15
11.2. Interaction with Delivery Notifications . . . . . . . . . 15 11.2. Interaction with Delivery Notifications . . . . . . . . . 15
11.3. Use of Email Addresses as Identifiers . . . . . . . . . . 16 11.3. Use of Email Addresses as Identifiers . . . . . . . . . . 16
11.4. Encoded Words, Signed Messages, and Downgrading . . . . . 16 11.4. Encoded Words, Signed Messages, and Downgrading . . . . . 16
11.5. LMTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 11.5. LMTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
11.6. SMTP Service Extension for DSNs . . . . . . . . . . . . . 17 11.6. Other Uses of Local Parts . . . . . . . . . . . . . . . . 16
11.7. Other Uses of Local Parts . . . . . . . . . . . . . . . . 17 11.7. Non-Standard Encapsulation Formats . . . . . . . . . . . . 17
11.8. Non-Standard Encapsulation Formats . . . . . . . . . . . . 17
12. Experimental Targets . . . . . . . . . . . . . . . . . . . . . 17 12. Experimental Targets . . . . . . . . . . . . . . . . . . . . . 17
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
14. Security Considerations . . . . . . . . . . . . . . . . . . . 18 14. Security Considerations . . . . . . . . . . . . . . . . . . . 17
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
16.1. Normative References . . . . . . . . . . . . . . . . . . . 20 16.1. Normative References . . . . . . . . . . . . . . . . . . . 19
16.2. Informative References . . . . . . . . . . . . . . . . . . 21 16.2. Informative References . . . . . . . . . . . . . . . . . . 20
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 22
A.1. Changes between -00 and -01 . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
[[anchor1: Note to EAI WG: this initial draft is intended to initiate [[anchor1: Note to EAI WG: these two initial drafts are intended to
discussion on what should, and should not, be in the Framework initiate discussion on what should, and should not, be in the
document and how we want those topics covered. As such, it is more Framework document and how we want those topics covered. As such, it
of an intermediate draft between RFC 4952 and the first draft of is more of an intermediate draft between RFC 4952 and the first draft
4952bis that could be a Last Call candidate. If we are going to keep of 4952bis that could be a Last Call candidate. If we are going to
the rather aggressive schedule we agreed to in the charter, we need keep the rather aggressive schedule we agreed to in the charter, we
to have enough discussion on critical-path points that a revision need to have enough discussion on critical-path points that a
suitable (at least) for final review prior to Last Call can be posted revision suitable (at least) for final review prior to Last Call can
before the 12 July I-D cutoff. For that to happen, we should have be posted before the 12 July I-D cutoff. For that to happen, we
enough discussion to start determining consensus within the next ten should have enough discussion to start determining consensus within
days. So, focused comments and soon, please.]] the next ten days. So, focused comments and soon, please.]]
In order to use internationalized email addresses, we need to In order to use internationalized email addresses, we need to
internationalize both the domain part and the local part of email internationalize both the domain part and the local part of email
addresses. The domain part of email addresses is already addresses. The domain part of email addresses is already
internationalized [RFC5890], while the local part is not. Without internationalized [RFC5890], while the local part is not. Without
the extensions specified in this document, the mailbox name is the extensions specified in this document, the mailbox name is
restricted to a subset of 7-bit ASCII [RFC5321]. Though MIME restricted to a subset of 7-bit ASCII [RFC5321]. Though MIME
[RFC2045] enables the transport of non-ASCII data, it does not [RFC2045] enables the transport of non-ASCII data, it does not
provide a mechanism for internationalized email addresses. In RFC provide a mechanism for internationalized email addresses. In RFC
2047 [RFC2047], MIME defines an encoding mechanism for some specific 2047 [RFC2047], MIME defines an encoding mechanism for some specific
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 headers. Information coded by other terms elsewhere) of the relevant header fields. Information
into the display name is invisible in the message envelope and, for coded into the display name is invisible in the message envelope and,
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] that 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].
2. Role of This Specification 2. Role of This Specification
This document presents the overview and framework for an approach to This document presents the overview and framework for an approach to
the next stage of email internationalization. This new stage the next stage of email internationalization. This new stage
requires not only internationalization of addresses and headers, but requires not only internationalization of addresses and header
also associated transport and delivery models. A prior version of fields, but also associated transport and delivery models. A prior
this specification, RFC 4952 [RFC4952], also provided an introduction version of this specification, RFC 4952 [RFC4952], also provided an
to a series of experimental protocols [RFC5335] [RFC5336] [RFC5337] introduction to a series of experimental protocols [RFC5335]
[RFC5504] [RFC5721] [RFC5738] [RFC5825]. [RFC5336] [RFC5337] [RFC5504] [RFC5721] [RFC5738] [RFC5825].
[[anchor2: Note in Draft: Is 5825 still relevant, or is a victim of [[anchor2: Note in Draft: Is 5825 still relevant, or is a victim of
the "no in-transit downgrade" decision.??]] the "no in-transit downgrade" decision.??]]
This revised form provides overview and conceptual information for This revised document provides overview and conceptual information
the standards-track successors of those protocols. Details of the for the standards-track successors of those protocols. Details of
documents and the relationships among them appear in Section 6. the documents and the relationships among them appear 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 [[anchor3: ??? provides a together and the relationships among the [[anchor3: ??? provides a
roadmap for navigating the]] various documents are involved. roadmap for navigating the]] various documents are involved.
3. Problem Statement 3. Problem Statement
Internationalizing Domain Names in Applications (IDNA) [RFC5890] Internationalizing Domain Names in Applications (IDNA) [RFC5890]
skipping to change at page 5, line 46 skipping to change at page 5, line 46
letters or numbers. Unless the entire email address can use familiar letters or numbers. Unless the entire email address can use familiar
characters and formats, users will perceive email as being culturally characters and formats, users will perceive email as being culturally
unfriendly. If the names and initials used in email addresses can be unfriendly. If the names and initials used in email addresses can be
expressed in the native languages and writing systems of the users, expressed in the native languages and writing systems of the users,
the Internet will be perceived as more natural, especially by those the Internet will be perceived as more natural, especially by those
whose native language is not written in a subset of a Roman-derived whose native language is not written in a subset of a Roman-derived
script. script.
Internationalization of email addresses is not merely a matter of Internationalization of email addresses is not merely a matter of
changing the SMTP envelope; or of modifying the From, To, and Cc changing the SMTP envelope; or of modifying the From, To, and Cc
headers; or of permitting upgraded Mail User Agents (MUAs) to decode header fields; or of permitting upgraded Mail User Agents (MUAs) to
a special coding and respond by displaying local characters. To be decode a special coding and respond by displaying local characters.
perceived as usable, the addresses must be internationalized and To be perceived as usable, the addresses must be internationalized
handled consistently in all of the contexts in which they occur. and handled consistently in all of the contexts in which they occur.
This requirement has far-reaching implications: collections of This requirement has far-reaching implications: collections of
patches and workarounds are not adequate. Even if they were patches and workarounds are not adequate. Even if they were
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] mail addressing and an SMTP Extension to permit UTF-8 [RFC3629] mail addressing and
delivery of those extended headers, and (finally) a requirement for delivery of those extended header fields, and (finally) a requirement
support of the 8BITMIME SMTP Extension [RFC1652] so that all of these for support of the 8BITMIME SMTP Extension [RFC1652] so that all of
can be transported through the mail system without having to overcome these can be transported through the mail system without having to
the limitation that headers do not have content-transfer-encodings. overcome the limitation 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].
4.1. Mail User and Mail Transfer Agents 4.1. Mail User and Mail Transfer Agents
Much of the description in this document depends on the abstractions Much of the description in this document depends on the abstractions
skipping to change at page 8, line 5 skipping to change at page 7, line 51
that the owner of that address is an i18mail user.) There is no such that the owner of that address is an i18mail user.) There is no such
thing as an "i18mail message"; the term applies only to users and thing as an "i18mail message"; the term applies only to users and
their agents and capabilities. their agents and capabilities.
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").
A conventional message is one that does not use any extension defined
in the SMTP extension document [RFC5336] or in the UTF8header
specification [RFC5335], and is strictly conformant to RFC 5322
[RFC5322].
An internationalized message is a message utilizing one or more of
the extensions defined in this specification or in the UTF8header
specification [RFC5335], so that it is no longer conformant to the
RFC 5322 specification of a message.
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
to multiple recipients by sending it to one recipient address. An to multiple recipients by sending it to one recipient address. An
agent (typically not a human being) at that single address then agent (typically not a human being) at that single address then
causes the message to be redistributed to the target recipients. causes the message to be redistributed to the target recipients.
This agent sets the envelope return address of the redistributed This agent sets the envelope return address of the redistributed
message to a different address from that of the original single message to a different address from that of the original single
recipient message. Using a different envelope return address recipient message. Using a different envelope return address
(reverse-path) causes error (and other automatically generated) (reverse-path) causes error (and other automatically generated)
messages to go to an error handling address. messages to go to an error handling address.
Special provisions for managing mailing lists that might contain non- Special provisions for managing mailing lists that might contain non-
ASCII addresses are discussed in a document that is specific to that ASCII addresses are discussed in a document that is specific to that
topic [EAI-Mailinglist]. topic [EAI-Mailinglist].
4.6. Conventional Message and Internationalized Message 4.6. Undeliverable Messages and Notification
o A conventional message is one that does not use any extension
defined in the SMTP extension document [RFC5336] or in the
UTF8header specification [RFC5335], and is strictly conformant to
RFC 5322 [RFC5322].
o An internationalized message is a message utilizing one or more of
the extensions defined in this specification or in the UTF8header
specification [RFC5335], so that it is no longer conformant to the
RFC 5322 specification of a message.
4.7. Undeliverable Messages and Notification
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.
[[anchor13: ??? The term "bounce" is used informally below to cover
both the rejection and NDN cases.]]
5. Overview of the Approach 5. Overview of the Approach
This set of specifications changes both SMTP and the format of email This set of specifications changes both SMTP and the character
headers to permit non-ASCII characters to be represented directly. encoding of email message headers to permit non-ASCII characters to
Each important component of the work is described in a separate be represented directly. Each important component of the work is
document. The document set, whose members are described in the next described in a separate document. The document set, whose members
section, also contains informational documents whose purpose is to are described in the next section, also contains informational
provide implementation suggestions and guidance for the protocols. documents whose purpose is to provide implementation suggestions and
guidance for the protocols.
6. Document Plan 6. Document Plan
In addition to this document, the following documents make up this In addition to this document, the following documents make up this
specification and provide advice and context for it. specification and provide advice and context for it.
[[anchor15: ... Note to WG: if we actually include a list here, the [[anchor12: ... Note to WG: if we actually include a list here, the
result will be that this document can be approved, but not published, result will be that this document can be approved, but not published,
until those documents on the list are complete. I'm inclined to list until those documents on the list are complete. I'm inclined to list
the SMTP extension and headers documents only and hand-wave about the the SMTP extension and headers documents only and hand-wave about the
rest, but we need to discuss. Version -00 simply refers to the rest, but we need to discuss. Versions -00 and -01 simply refer to
current Experimental documents --Editor.]] the current Experimental documents --Editor.]]
o SMTP extensions. This document [RFC5336] provides an SMTP o SMTP extensions. This document [RFC5336] provides an SMTP
extension (as provided for in RFC 5321) for internationalized extension (as provided for in RFC 5321) for internationalized
addresses. addresses.
o Email headers in UTF-8. This document [RFC5335] essentially o Email message headers in UTF-8. This document [RFC5335]
updates RFC 5322 to permit some information in email headers to be essentially updates RFC 5322 to permit some information in email
expressed directly by Unicode characters encoded in UTF-8 when the message headers to be expressed directly by Unicode characters
SMTP extension described above is used. This document, possibly encoded in UTF-8 when the SMTP extension described above is used.
with one or more supplemental ones, will also need to address the This document, possibly with one or more supplemental ones, will
interactions with MIME, including relationships between also need to address the interactions with MIME, including
UTF8SMTPbis and internal MIME headers and content types. relationships between UTF8SMTPbis and internal MIME headers and
content types.
o Extensions to the IMAP protocol to support internationalized o Extensions to the IMAP protocol to support internationalized
headers [RFC5738]. message headers [RFC5738].
o Parallel extensions to the POP protocol [RFC5721]. o Parallel extensions to the POP protocol [RFC5721].
o Description of internationalization changes for delivery o Description of internationalization changes for delivery
notifications (DSNs) [EAI-DSN]. notifications (DSNs) [RFC5337].
7. Overview of Protocol Extensions and Changes 7. Overview of Protocol Extensions and Changes
7.1. SMTP Extension for Internationalized Email Address 7.1. SMTP Extension for Internationalized Email Address
An SMTP extension, "UTF8SMTPbis" is specified as follows: An SMTP extension, "UTF8SMTPbis" is specified as follows:
o Permits the use of UTF-8 strings in email addresses, both local o Permits the use of UTF-8 strings in email addresses, both local
parts and domain names. parts and domain names.
o Permits the selective use of UTF-8 strings in email headers (see o Permits the selective use of UTF-8 strings in email message
Section 7.2). headers (see Section 7.2).
o Requires that the server advertise the 8BITMIME extension o Requires that the server advertise the 8BITMIME extension
[RFC1652] and that the client support 8-bit transmission so that [RFC1652] and that the client support 8-bit transmission so that
header information can be transmitted without using a special header information can be transmitted without using a special
content-transfer-encoding. content-transfer-encoding.
Some general principles affect the development decisions underlying Some general principles affect the development decisions underlying
this work. this work.
1. Email addresses enter subsystems (such as a user interface) that 1. Email addresses enter subsystems (such as a user interface) that
skipping to change at page 10, line 40 skipping to change at page 10, line 30
* Reject the message or, if necessary, return a non-delivery * Reject the message or, if necessary, return a non-delivery
notification message, so that the sender can make another notification message, so that the sender can make another
plan. plan.
3. If the message cannot be forwarded because the next-hop system 3. If the message cannot be forwarded because the next-hop system
cannot accept the extension it MUST be rejected or a non-delivery cannot accept the extension it MUST be rejected or a non-delivery
message generated and sent. message generated and sent.
4. In the interest of interoperability, charsets other than UTF-8 4. In the interest of interoperability, charsets other than UTF-8
are prohibited in mail addresses and headers being transmitted are prohibited in mail addresses and message headers being
over the Internet. There is no practical way to identify transmitted over the Internet. There is no practical way to
multiple charsets properly with an extension similar to this identify multiple charsets properly with an extension similar to
without introducing great complexity. this without introducing great complexity.
Conformance to the group of standards specified here for email Conformance to the group of standards specified here for email
transport and delivery requires implementation of the SMTP Extension transport and delivery requires implementation of the SMTP Extension
specification, including recognition of the keywords associated with specification, including recognition of the keywords associated with
alternate addresses, and the UTF-8 Header specification. If the alternate addresses, and the UTF-8 Header specification. If the
system implements IMAP or POP, it MUST conform to the i18n IMAP or system implements IMAP or POP, it MUST conform to the i18n IMAP or
POP specifications respectively. POP specifications respectively.
7.2. Transmission of Email Header Fields in UTF-8 Encoding 7.2. Transmission of Email Header Fields in UTF-8 Encoding
skipping to change at page 11, line 27 skipping to change at page 11, line 16
"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, it seems clear that
they should be accompanied by arrangements for the email headers to they should be accompanied by arrangements for the message headers to
be in the fully internationalized form. That form should presumably be in the fully internationalized form. That form should 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 will remain entirely in ASCII). For transition themselves will remain entirely in ASCII). For transition purposes
purposes and compatibility with legacy systems, this can done by and compatibility with legacy systems, this can done by extending the
extending the encoding models of [RFC2045] and [RFC2231]. However, encoding models of [RFC2045] and [RFC2231]. However, the target is
target is fully internationalized headers, as discussed in [RFC5335] fully internationalized message headers, as discussed in [RFC5335]
and not an extended and painful transition. and not an extended and painful transition.
8. Downgrading before and after SMTP Transactions 8. Downgrading before and after SMTP Transactions
An important issue with these extensions is how to handle An important issue with these extensions is how to handle
interactions between systems that support non-ASCII addresses and interactions between systems that support non-ASCII addresses and
legacy systems that expect ASCII. There is, of course, no problem legacy systems that expect ASCII. There is, of course, no problem
with ASCII-only systems sending to those that can handle with ASCII-only systems sending to those that can handle
internationalized forms because the ASCII forms are just a proper internationalized forms because the ASCII forms are just a proper
subset. But, when systems that support these extensions send mail, subset. But, when systems that support these extensions send mail,
they may include non-ASCII addresses for senders, receivers, or both they may include non-ASCII addresses for senders, receivers, or both
and might also provide non-ASCII header information other than and might also provide non-ASCII header information other than
addresses. If the extension is not supported by the first-hop system addresses. If the extension is not supported by the first-hop system
(SMTP server accessed by the Submission server acting as an SMTP (SMTP server accessed by the Submission server acting as an SMTP
client), message originating systems should be prepared to either client), message originating systems should be prepared to either
send conventional envelopes and headers or to return the message to send conventional envelopes and message headers or to return the
the originating user so the message may be manually downgraded to the message to the originating user so the message may be manually
traditional form, possibly using encoded words [RFC2047] in the downgraded to the traditional form, possibly using encoded words
headers. Of course, such transformations imply that the originating [RFC2047] in the message headers. Of course, such transformations
user or system must have ASCII-only addresses available for all imply that the originating user or system must have ASCII-only
senders and recipients. Mechanisms by which such addresses may be addresses available for all senders and recipients. Mechanisms by
found or identified are outside the scope of these specifications as which such addresses may be found or identified are outside the scope
are decisions about the design of originating systems such as whether of these specifications as are decisions about the design of
any required transformations are made by the user, the originating originating systems such as whether any required transformations are
MUA, or the Submission server. made by the user, the originating MUA, or the Submission server.
A somewhat more complex situation arises when the first-hop system A somewhat more complex situation arises when the first-hop system
supports these extensions but some subsequent server in the SMTP supports these extensions but some subsequent server in the SMTP
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 will be the result of configuration errors: of that situation will be the result of configuration errors:
especially if it hosts non-ASCII addresses, a final delivery server especially if it hosts non-ASCII addresses, a final delivery server
that accepts these extensions should not be configured with lower- that accepts these extensions should not be configured with lower-
preference MX hosts that do not. While the experiments that preceded preference MX hosts that do not. While the experiments that preceded
these specifications included a mechanism for passing backup ASCII these specifications included a mechanism for passing backup ASCII
addresses to intermediate relay systems and having those systems addresses to intermediate relay systems and having those systems
alter the headers and substitute the addresses, the requirements and alter the relevant message header fields and substitute the
long-term implications of that system proved too complex to be addresses, the requirements and long-term implications of that system
satisfactory. Consequently, if an intermediate SMTP relay that is proved too complex to be satisfactory. Consequently, if an
transmitting a message that requires these extensions and discovers intermediate SMTP relay that is transmitting a message that requires
that the next system in the chain does not support them, it will have these extensions and discovers that the next system in the chain does
little choice other than to reject or return the message. not support them, it will have little choice other than to reject or
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 22 skipping to change at page 13, line 15
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 SMTP server, it When an email message is received by a final delivery SMTP server, it
is usually stored in some form. Then it is retrieved either by is usually stored in some form. Then it is retrieved either by
software that reads the stored form directly or by client software software that reads the stored form directly or by client software
via some email retrieval mechanisms such as POP or IMAP. via some 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 headers from accessing stored internationalized addresses and UTF-8 message headers from accessing
internationalized emails. stored internationalized emails.
Since the final delivery SMTP server (or, to be more specific, its Since the final delivery SMTP server (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 either downgrade internationalized
emails or specially identify messages that utilize these extensions, emails or specially identify messages that utilize these extensions,
or both. If this is done, the final delivery SMTP server SHOULD or both. If this is done, the final delivery SMTP server SHOULD
include a mechanism to preserve or recover the original include a mechanism to preserve or recover the original
internationalized forms without information loss to support access by internationalized forms without information loss to support access by
UTF8SMTPbis-aware agents. UTF8SMTPbis-aware agents.
9. Downgrading in Transit 9. Downgrading in Transit
[[anchor19: Note in Draft and Question for the WG: We could discuss [[anchor16: Note in Draft and Question for the WG: We could discuss
the various issues with in-transit downgrading including the the various issues with in-transit downgrading including the
complexities of carrying backup addresses, the problems that complexities of carrying backup addresses, the problems that
motivated the "don't mess with addresses in transit" (paraphrased, motivated the "don't mess with addresses in transit" (paraphrased,
obviously) rule in RFC 5321 and friends, and so on. Or we could omit obviously) rule in RFC 5321 and friends, and so on. Or we could omit
it (and this section). Pragmatically, I think it would take us some it (and this section). Pragmatically, I think it would take us some
time to reach consensus on what, exactly, should be said and that time to reach consensus on what, exactly, should be said and that
might delay progress. But input is clearly needed.]] might delay progress. But input is clearly needed -- if it is not
received before we prepared -02, this section will simply be
dropped.]]
10. User Interface and Configuration Issues 10. User Interface and Configuration Issues
Internationalization of addresses and headers, especially in Internationalization of addresses and message headers, especially in
combination with variations on character coding that are inherent to combination with variations on character coding that are inherent to
Unicode, may make careful choices of addresses and careful Unicode, may make careful choices of addresses and careful
configuration of servers and DNS records even more important than configuration of servers and DNS records even more important than
they are for traditional Internet email. It is likely that, as they are for traditional Internet email. It is likely that, as
experience develops with the use of these protocols, it will be experience develops with the use of these protocols, it will be
desirable to produce one or more additional documents that offer desirable to produce one or more additional documents that offer
guidance for configuration and interfaces. A document that discusses guidance for configuration and interfaces. A document that discusses
issues with mail user agents (MUAs), especially with regard to issues with mail user agents (MUAs), especially with regard to
downgrading, is expected to be developed in the EAI Working Group. downgrading, is expected to be developed in the EAI Working Group.
The subsections below address some other issues. The subsections below address some other issues.
10.1. Choices of Mailbox Names and Unicode Normalization 10.1. Choices of Mailbox Names and Unicode Normalization
It has long been the case the email syntax permits choices about It has long been the case the email syntax permits choices about
mailbox names that that are unwise in practice if one actually mailbox names that that are unwise in practice if one actually
intends the mailboxes to be accessible to a broad range of senders. intends the mailboxes to be accessible to a broad range of senders.
The most-often-cited examples involve the use of case-sensitivity and The most-often-cited examples involve the use of case-sensitivity and
tricky quoting of embedded characters in mailbox local parts. While tricky quoting of embedded characters in mailbox local parts. While
these are permitted by the protocols and servers are expected to these are permitted by the protocols and servers are expected to
skipping to change at page 14, line 46 skipping to change at page 14, line 42
it continue to be recognized. it continue to be recognized.
For the particular case of EAI mailbox names, special attention must For the particular case of EAI mailbox names, special attention must
be paid to Unicode normalization, in part because Unicode strings may be paid to Unicode normalization, in part because Unicode strings may
be normalized by other processes independent of what a mail protocol be normalized by other processes independent of what a mail protocol
specifies (this is exactly analogous to what may happen with quoting specifies (this is exactly analogous to what may happen with quoting
and dequoting in traditional addresses). Consequently, the following and dequoting in traditional addresses). Consequently, the following
principles are offered as advice to those who are selecting names for principles are offered as advice to those who are selecting names for
mailboxes: mailboxes:
o In general, it is wise to support addresses in Normalized form, o In general, it is wise for servers to provide addresses only in
using either Normalization Form NFC and, except in unusual Normalized form and to normalize strings on receipt, using either
circumstances, NFKC. Normalization Form NFC and, except in unusual circumstances, NFKC.
[[anchor19: Note in Draft: "Normalize on receipt" is consistent
with the recommendations in draft-iab-i18n-encoding. The issue
with NFKC is that some of the characters mapped out may be
significant, especially in personal names. Anyone with objections
should speak up. Soon.]]
o It may be wise to support other forms of the same local-part o It may be wise to support other forms of the same local-part
string, either as aliases or by normalization of strings reaching string, either as aliases or by normalization of strings reaching
the delivery server, in the event that the sender does not send the delivery server, in the event that the sender does not send
the strings in normalized form. the strings in normalized form.
o Stated differently and in more specific terms, the rules of the o Stated differently and in more specific terms, the rules of the
protocol for local-part strings essentially provide that: protocol for local-part strings essentially provide that:
* Unnormalized strings are valid, but sufficiently bad practice * Unnormalized strings are valid, but sufficiently bad practice
skipping to change at page 15, line 41 skipping to change at page 15, line 41
The mailto: schema defined in [RFC2368] and discussed in the The mailto: schema defined in [RFC2368] and discussed in the
Internationalized Resource Identifier (IRI) specification [RFC3987] Internationalized Resource Identifier (IRI) specification [RFC3987]
may need to be modified when this work is completed and standardized. may need to be modified when this work is completed and standardized.
In particular, providing an alternate address as part of a mailto: In particular, providing an alternate address as part of a mailto:
URI may require some fairly careful work on the syntax of that URI. URI may require some fairly careful work on the syntax of that URI.
11.2. Interaction with Delivery Notifications 11.2. Interaction with Delivery Notifications
The advent of UTF8SMTPbis will make necessary consideration of the The advent of UTF8SMTPbis will make necessary consideration of the
interaction with delivery notification mechanisms, including the SMTP interaction with delivery notification mechanisms, including the
extension for requesting delivery notifications [RFC3461], and the ASCII-only SMTP extension for requesting delivery notifications
format of delivery notifications [RFC3464]. These issues are (DSNs) [RFC3461], and the format of delivery notifications [RFC3464].
discussed in a forthcoming document that will update those RFCs as A new document, "International Delivery and Disposition
needed [EAI-DSN]. Notifications" [RFC5337] adds a new address type for international
[[anchor25: Note in draft: we could just eliminate this section and email addresses so an original recipient address with non-ASCII
add the DSN document to the "Document Plan" in Section 6. characters can be correctly preserved even after downgrading. If an
Opinions?]] SMTP server advertises both the UTF8SMTPbis and the DSN extension,
that server MUST implement internationalized DSNs, including support
for the ORCPT parameter.
11.3. Use of Email Addresses as Identifiers 11.3. Use of Email Addresses as Identifiers
There are a number of places in contemporary Internet usage in which There are a number of places in contemporary Internet usage in which
email addresses are used as identifiers for individuals, including as email addresses are used as identifiers for individuals, including as
identifiers to Web servers supporting some electronic commerce sites. identifiers to Web servers supporting some electronic commerce sites.
These documents do not address those uses, but it is reasonable to These documents do not address those uses, but it is reasonable to
expect that some difficulties will be encountered when expect that some difficulties will be encountered when
internationalized addresses are first used in those contexts, many of internationalized addresses are first used in those contexts, many of
which cannot even handle the full range of addresses permitted today. which cannot even handle the full range of addresses permitted today.
skipping to change at page 16, line 38 skipping to change at page 16, line 38
effects. effects.
For example, message parts that are cryptographically signed, using For example, message parts that are cryptographically signed, using
e.g., S/MIME [RFC3851] or Pretty Good Privacy (PGP) [RFC3156], cannot e.g., S/MIME [RFC3851] or Pretty Good Privacy (PGP) [RFC3156], cannot
be upgraded from the RFC 2047 form to normal UTF-8 characters without be upgraded from the RFC 2047 form to normal UTF-8 characters without
breaking the signature. Similarly, message parts that are encrypted breaking the signature. Similarly, message parts that are encrypted
may contain, when decrypted, header fields that use the RFC 2047 may contain, when decrypted, header fields that use the RFC 2047
encoding; such messages cannot be 'fully' upgraded without access to encoding; such messages cannot be 'fully' upgraded without access to
cryptographic keys. cryptographic keys.
Similar issues may arise if signed messages are downgraded in transit
??? and then an attempt is made to upgrade them to the original form
and then verify the signatures. Even the very subtle changes that
may result from algorithms to downgrade and then upgrade again may be
sufficient to invalidate the signatures if they impact either the
primary or MIME bodypart headers. When signatures are present,
downgrading must be performed with extreme care if at all.
11.5. LMTP 11.5. LMTP
LMTP [RFC2033] may be used as the final delivery agent. In such LMTP [RFC2033] may be used as the final delivery agent. In such
cases, LMTP may be arranged to deliver the mail to the mail store. cases, LMTP may be arranged to deliver the mail to the mail store.
The mail store may not have UTF8SMTPbis capability. LMTP need to be The mail store may not have UTF8SMTPbis capability. LMTP need to be
updated to deal with these situations. updated to deal with these situations.
11.6. SMTP Service Extension for DSNs 11.6. Other Uses of Local Parts
The existing Draft Standard Delivery status notifications
(DSNs)[RFC3461] specification is limited to ASCII text in the machine
readable portions of the protocol. "International Delivery and
Disposition Notifications" [EAI-DSN] adds a new address type for
international email addresses so an original recipient address with
non-ASCII characters can be correctly preserved even after
downgrading. If an SMTP server advertises both the UTF8SMTPbis and
the DSN extension, that server MUST implement internationalized DSNs
[EAI-DSN] including support for the ORCPT parameter.
11.7. Other Uses of Local Parts
Local parts are sometimes used to construct domain labels, e.g., the Local parts are sometimes used to construct domain labels, e.g., the
local part "user" in the address user@domain.example could be local part "user" in the address user@domain.example could be
converted into a vanity host user.domain.example with its Web space converted into a vanity host user.domain.example with its Web space
at <http://user.domain.example> and the catchall addresses at <http://user.domain.example> and the catchall addresses
any.thing.goes@user.domain.example. any.thing.goes@user.domain.example.
Such schemes are obviously limited by, among other things, the SMTP Such schemes are obviously limited by, among other things, the SMTP
rules for domain names, and will not work without further rules for domain names, and will not work without further
restrictions for other local parts such as the <utf8-local-part> restrictions for other local parts such as the <utf8-local-part>
specified in [RFC5335]. Whether this issue is relevant to these specified in [RFC5335]. Whether this issue is relevant to these
specifications is an open question. It may be simply another case of specifications is an open question. It may be simply another case of
the considerable flexibility accorded to delivery MTAs in determining the considerable flexibility accorded to delivery MTAs in determining
the mailbox names they will accept and how they are interpreted. the mailbox names they will accept and how they are interpreted.
11.8. Non-Standard Encapsulation Formats 11.7. Non-Standard Encapsulation Formats
Some applications use formats similar to the application/mbox format Some applications use formats similar to the application/mbox format
defined in [RFC4155] instead of the message/digest RFC 2046, Section defined in [RFC4155] instead of the message/digest RFC 2046, Section
5.1.5 [RFC2046] form to transfer multiple messages as single units. 5.1.5 [RFC2046] form to transfer multiple messages as single units.
Insofar as such applications assume that all stored messages use the Insofar as such applications assume that all stored messages use the
message/rfc822 RFC 2046, Section 5.2.1 [RFC2046] format with US-ASCII message/rfc822 RFC 2046, Section 5.2.1 [RFC2046] format with US-ASCII
headers, they are not ready for the extensions specified in this message headers, they are not ready for the extensions specified in
series of documents and special measures may be needed to properly this series of documents and special measures may be needed to
detect and process them. properly detect and process them.
12. Experimental Targets 12. Experimental Targets
[[anchor31: Note in draft: this section is left in this draft for [[anchor26: Note in draft: this section is left in this draft for
convenience in review. It will be removed with -01.]] convenience in review. It will be removed with -02.]]
In addition to the simple question of whether the model outlined here In addition to the simple question of whether the model outlined here
can be made to work in a satisfactory way for upgraded systems and can be made to work in a satisfactory way for upgraded systems and
provide adequate protection for un-upgraded ones, we expect that provide adequate protection for un-upgraded ones, we expect that
actually working with the systems will provide answers to two actually working with the systems will provide answers to two
additional questions: what restrictions such as character lists or additional questions: what restrictions such as character lists or
normalization should be placed, if any, on the characters that are normalization should be placed, if any, on the characters that are
permitted to be used in address local-parts and how useful, in permitted to be used in address local-parts and how useful, in
practice, will downgrading turn out to be given whatever restrictions practice, will downgrading turn out to be given whatever restrictions
and constraints that must be placed upon it. and constraints that must be placed upon it.
skipping to change at page 18, line 37 skipping to change at page 18, line 17
local parts since those are case sensitive. local parts since those are case sensitive.
Since email addresses are often transcribed from business cards and Since email addresses are often transcribed from business cards and
notes on paper, they are subject to problems arising from confusable notes on paper, they are subject to problems arising from confusable
characters (see [RFC4690]). These problems are somewhat reduced if characters (see [RFC4690]). These problems are somewhat reduced if
the domain associated with the mailbox is unambiguous and supports a the domain associated with the mailbox is unambiguous and supports a
relatively small number of mailboxes whose names follow local system relatively small number of mailboxes whose names follow local system
conventions. They are increased with very large mail systems in conventions. They are increased with very large mail systems in
which users can freely select their own addresses. which users can freely select their own addresses.
The internationalization of email addresses and headers must not The internationalization of email addresses and message headers must
leave the Internet less secure than it is without the required not leave the Internet less secure than it is without the required
extensions. The requirements and mechanisms documented in this set extensions. The requirements and mechanisms documented in this set
of specifications do not, in general, raise any new security issues. of specifications do not, in general, raise any new security issues.
They do require a review of issues associated with confusable They do require a review of issues associated with confusable
characters -- a topic that is being explored thoroughly elsewhere characters -- a topic that is being explored thoroughly elsewhere
(see, e.g., [RFC4690]) -- and, potentially, some issues with UTF-8 (see, e.g., [RFC4690]) -- and, potentially, some issues with UTF-8
normalization, discussed in [RFC3629], and other transformations. normalization, discussed in [RFC3629], and other transformations.
Normalization and other issues associated with transformations and Normalization and other issues associated with transformations and
standard forms are also part of the subject of ongoing work discussed standard forms are also part of the subject of ongoing work discussed
in [RFC5198], in [RFC5893] and elsewhere. in [RFC5198], in [RFC5893] and elsewhere.
Some issues specifically related to internationalized addresses and Some issues specifically related to internationalized addresses and
headers are discussed in more detail in the other documents in this message headers are discussed in more detail in the other documents
set. However, in particular, caution should be taken that any in this set. However, in particular, caution should be taken that
"downgrading" mechanism, or use of downgraded addresses, does not any "downgrading" mechanism, or use of downgraded addresses, does not
inappropriately assume authenticated bindings between the inappropriately assume authenticated bindings between the
internationalized and ASCII addresses. Expecting and most or all internationalized and ASCII addresses. Expecting and most or all
such transformations prior to final delivery be done by systems that such transformations prior to final delivery be done by systems that
are presumed to be under the administrative control of the sending are presumed to be under the administrative control of the sending
user ameliorates the potential problem somewhat as compared to what user ameliorates the potential problem somewhat as compared to what
it would be if the relationships were changed in transit. it would be if the relationships were changed in transit.
The new UTF-8 header and message formats might also raise, or The new UTF-8 header and message formats might also raise, or
aggravate, another known issue. If the model creates new forms of an aggravate, another known issue. If the model creates new forms of an
'invalid' or 'malformed' message, then a new email attack is created: 'invalid' or 'malformed' message, then a new email attack is created:
skipping to change at page 19, line 34 skipping to change at page 19, line 14
types. types.
In addition, email addresses are used in many contexts other than In addition, email addresses are used in many contexts other than
sending mail, such as for identifiers under various circumstances sending mail, such as for identifiers under various circumstances
(see Section 11.3). Each of those contexts will need to be (see Section 11.3). Each of those contexts will need to be
evaluated, in turn, to determine whether the use of non-ASCII forms evaluated, in turn, to determine whether the use of non-ASCII forms
is appropriate and what particular issues they raise. is appropriate and what particular issues they raise.
This work will clearly affect any systems or mechanisms that are This work will clearly affect any systems or mechanisms that are
dependent on digital signatures or similar integrity protection for dependent on digital signatures or similar integrity protection for
mail headers (see also the discussion in Section 11.4). Many email message headers (see also the discussion in Section 11.4).
conventional uses of PGP and S/MIME are not affected since they are Many conventional uses of PGP and S/MIME are not affected since they
used to sign body parts but not headers. On the other hand, the are used to sign body parts but not message headers. On the other
developing work on domain keys identified mail (DKIM [RFC5863]) will hand, the developing work on domain keys identified mail (DKIM
eventually need to consider this work and vice versa: while this [RFC5863]) will eventually need to consider this work and vice versa:
specification does not address or solve the issues raised by DKIM and while this specification does not address or solve the issues raised
other signed header mechanisms, the issues will have to be by DKIM and other signed header mechanisms, the issues will have to
coordinated and resolved eventually if the two sets of protocols are be coordinated and resolved eventually if the two sets of protocols
to co-exist. In addition, to the degree to which email addresses are to co-exist. In addition, to the degree to which email addresses
appear in PKI (Public Key Infrastructure) certificates, standards appear in PKI (Public Key Infrastructure) certificates, standards
addressing such certificates will need to be upgraded to address addressing such certificates will need to be upgraded to address
these internationalized addresses. Those upgrades will need to these internationalized addresses. Those upgrades will need to
address questions of spoofing by look-alikes of the addresses address questions of spoofing by look-alikes of the addresses
themselves. themselves.
15. Acknowledgements 15. Acknowledgements
[[anchor34: To be upgraded in -01 to point back to 4952]] This document is an update to, and derived from, RFC 4952. This
document would have been impossible without the work and
This document, and the related ones, were originally derived from contributions acknowledged in it. The present document benefited
documents by John Klensin and the JET group [Klensin-emailaddr], significantly from discussions in the EAI WG and elsewhere after RFC
[JET-IMA]. The work drew inspiration from discussions on the "IMAA" 4952 was published, especially discussions about the experimental
mailing list, sponsored by the Internet Mail Consortium and versions of other documents in the internationalized email
especially from an early document by Paul Hoffman and Adam Costello collection, and from RFC errata on RFC 4952 itself.
[Hoffman-IMAA] that attempted to define an MUA-only solution to the
address internationalization problem.
More recent documents have benefited from considerable discussion
within the IETF EAI Working Group and especially from suggestions and
text provided by Martin Duerst, Frank Ellermann, Philip Guenther,
Kari Hurtta, and Alexey Melnikov, and from extended discussions among
the editors and authors of the core documents cited in Section 6:
Harald Alvestrand, Kazunori Fujiwara, Chris Newman, Pete Resnick,
Jiankang Yao, Jeff Yeh, and Yoshiro Yoneya.
Additional comments received during IETF Last Call, including those
from Paul Hoffman and Robert Sparks, were helpful in making the
document more clear and comprehensive.
16. References 16. References
16.1. Normative References 16.1. Normative References
[ASCII] American National Standards Institute (formerly [ASCII] American National Standards Institute (formerly
United States of America Standards Institute), United States of America Standards Institute),
"USA Code for Information Interchange", "USA Code for Information Interchange",
ANSI X3.4-1968, 1968. ANSI X3.4-1968, 1968.
skipping to change at page 21, line 14 skipping to change at page 20, line 25
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", [RFC5321] Klensin, J., "Simple Mail Transfer Protocol",
RFC 5321, October 2008. RFC 5321, October 2008.
[RFC5890] Klensin, J., "Internationalized Domain Names for [RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Applications (IDNA): Definitions and Document
Framework", RFC 5890, June 2010. Framework", RFC 5890, June 2010.
16.2. Informative References 16.2. Informative References
[EAI-DSN] Newman, C., "UTF-8 Delivery and Disposition
Notification", Work in Progress, January 2007.
[EAI-Mailinglist] Gellens, R., "Mailing Lists and [EAI-Mailinglist] Gellens, R., "Mailing Lists and
Internationalized Email Addresses", March 2010, Internationalized Email Addresses", June 2010, <
<https://datatracker.ietf.org/doc/ https://datatracker.ietf.org/doc/
draft-ietf-eai-mailinglist/>. draft-ietf-eai-mailinglist/>.
[Hoffman-IMAA] Hoffman, P. and A. Costello, "Internationalizing [Hoffman-IMAA] Hoffman, P. and A. Costello, "Internationalizing
Mail Addresses in Applications (IMAA)", Work Mail Addresses in Applications (IMAA)", Work
in Progress, October 2003. in Progress, October 2003.
[JET-IMA] Yao, J. and J. Yeh, "Internationalized eMail [JET-IMA] Yao, J. and J. Yeh, "Internationalized eMail
Address (IMA)", Work in Progress, June 2005. Address (IMA)", Work in Progress, June 2005.
[Klensin-emailaddr] Klensin, J., "Internationalization of Email [Klensin-emailaddr] Klensin, J., "Internationalization of Email
skipping to change at page 23, line 37 skipping to change at page 22, line 46
[RFC5863] Hansen, T., Siegel, E., Hallam-Baker, P., and D. [RFC5863] Hansen, T., Siegel, E., Hallam-Baker, P., and D.
Crocker, "DomainKeys Identified Mail (DKIM) Crocker, "DomainKeys Identified Mail (DKIM)
Development, Deployment, and Operations", Development, Deployment, and Operations",
RFC 5863, May 2010. RFC 5863, May 2010.
[RFC5893] Alvestrand, H. and C. Karp, "Right-to-Left [RFC5893] Alvestrand, H. and C. Karp, "Right-to-Left
Scripts for Internationalized Domain Names for Scripts for Internationalized Domain Names for
Applications (IDNA)", RFC 5893, June 2010. Applications (IDNA)", RFC 5893, June 2010.
Appendix A. Change Log
[[RFC Editor: Please remove this section prior to publication.]]
A.1. Changes between -00 and -01
o Because there has been no feedback on the mailing list, updated
the various questions to refer to this version as well.
o Reflected RFC Editor erratum #1507 by correcting terminology for
headers and header fields and distinguishing between "message
headers" and different sorts of headers (e.g., the MIME ones).
o Merged earlier sections 4.4 and 4.6 into an expanded Section 4.4.
o Merged earlier Section 11.6 into Section 11.2 and eliminated the
note in draft.
o Eliminated former last paragraph of Section 11.4 as an artifact of
in-transit downgrading.
o Updated a few references.
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. 48 change blocks. 
193 lines changed or deleted 190 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/