draft-ietf-eai-frmwrk-4952bis-06.txt   draft-ietf-eai-frmwrk-4952bis-07.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 23, 2010 (if approved) August 31, 2010
Intended status: Informational Intended status: Informational
Expires: February 24, 2011 Expires: March 4, 2011
Overview and Framework for Internationalized Email Overview and Framework for Internationalized Email
draft-ietf-eai-frmwrk-4952bis-06 draft-ietf-eai-frmwrk-4952bis-07
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 February 24, 2011. This Internet-Draft will expire on March 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 36 skipping to change at page 3, line 36
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 . . . . . . . . . . 17 11.2. Use of Email Addresses as Identifiers . . . . . . . . . . 17
11.3. Encoded Words, Signed Messages, and Downgrading . . . . . 17 11.3. Encoded Words, Signed Messages, and Downgrading . . . . . 17
11.4. LMTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 11.4. Other Uses of Local Parts . . . . . . . . . . . . . . . . 18
11.5. Other Uses of Local Parts . . . . . . . . . . . . . . . . 18 11.5. Non-Standard Encapsulation Formats . . . . . . . . . . . . 18
11.6. Non-Standard Encapsulation Formats . . . . . . . . . . . . 18 12. Key Changes From the Experimental Protocols and Framework . . 18
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
13. Security Considerations . . . . . . . . . . . . . . . . . . . 18 14. Security Considerations . . . . . . . . . . . . . . . . . . . 19
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
15.1. Normative References . . . . . . . . . . . . . . . . . . . 20 16.1. Normative References . . . . . . . . . . . . . . . . . . . 21
15.2. Informative References . . . . . . . . . . . . . . . . . . 22 16.2. Informative References . . . . . . . . . . . . . . . . . . 22
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 26 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 26
A.1. Changes between -00 and -01 . . . . . . . . . . . . . . . 26 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 . . . . . . . . . . . . . . . 28
A.4. Changes between -03 and -04 . . . . . . . . . . . . . . . 28 A.4. Changes between -03 and -04 . . . . . . . . . . . . . . . 28
A.5. Changes between -04 and -05 . . . . . . . . . . . . . . . 28 A.5. Changes between -04 and -05 . . . . . . . . . . . . . . . 28
A.6. Changes between -05 and -06 . . . . . . . . . . . . . . . 28 A.6. Changes between -05 and -06 . . . . . . . . . . . . . . . 28
A.7. Changes between -06 and -07 . . . . . . . . . . . . . . . 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 18, line 5 skipping to change at page 18, line 5
Similar issues may arise if messages are signed and then subsequently Similar issues may arise if messages are signed and then subsequently
downgraded, e.g., as discussed in Section 8.1, and then an attempt is downgraded, e.g., as discussed in Section 8.1, and then an attempt is
made to upgrade them to the original form and then verify the made to upgrade them to the original form and then verify the
signatures. Even the very subtle changes that may result from signatures. Even the very subtle changes that may result from
algorithms to downgrade and then upgrade again may be sufficient to algorithms to downgrade and then upgrade again may be sufficient to
invalidate the signatures if they impact either the primary or MIME invalidate the signatures if they impact either the primary or MIME
bodypart headers. When signatures are present, downgrading MUST be bodypart headers. When signatures are present, downgrading MUST be
performed with extreme care if at all. performed with extreme care if at all.
11.4. LMTP 11.4. Other Uses of Local Parts
LMTP [RFC2033] may be used as part of the final delivery agent. In
such cases, LMTP may be arranged to deliver the mail to the mail
store. The mail store may not have UTF8SMTPbis capability. LMTP may
need to be updated to deal with these situations.
11.5. 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 [RFC5335bis-Hdrs]. Whether those limitations are specified in [RFC5335bis-Hdrs]. Whether those limitations are
relevant to these specifications is an open question. It may be relevant to these specifications is an open question. It may be
simply another case of the considerable flexibility accorded to simply another case of the considerable flexibility accorded to
delivery MTAs in determining the mailbox names they will accept and delivery MTAs in determining the mailbox names they will accept and
how they are interpreted. how they are interpreted.
11.6. Non-Standard Encapsulation Formats 11.5. 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 form described in defined in [RFC4155] instead of the message/digest form described in
RFC 2046, Section 5.1.5 [RFC2046] to transfer multiple messages as RFC 2046, Section 5.1.5 [RFC2046] to transfer multiple messages as
single units. Insofar as such applications assume that all stored single units. Insofar as such applications assume that all stored
messages use the message/rfc822 format described in RFC 2046, Section messages use the message/rfc822 format described in RFC 2046, Section
5.2.1 [RFC2046] with US-ASCII message headers, they are not ready for 5.2.1 [RFC2046] with US-ASCII message headers, they are not ready for
the extensions specified in this series of documents and special the extensions specified in this series of documents and special
measures may be needed to properly detect and process them. measures may be needed to properly detect and process them.
12. IANA Considerations 12. Key Changes From the Experimental Protocols and Framework
The original framework for internationalized email addresses and
headers was described in RFC 4952 and a subsequent set of
experimental protocol documents. Those relationships are described
in Section 3. The key architectural difference between the
experimental specifications and this newer set is that the earlier
specifications supported in-transit downgrading including providing
syntax and functions to support passing alternate, all-ASCII,
addresses with the non-ASCII ones and special headers to indicate the
downgraded status of messages. Those features were eliminated after
experimentation indicated that they were more complex and less
necessary than had been assumed earlier. Those issues are described
in more detail in Section 6 and Section 9.
13. IANA Considerations
This overview description and framework document does not contemplate This overview description and framework document does not contemplate
any IANA registrations or other actions. Some of the documents in any IANA registrations or other actions. Some of the documents in
the group have their own IANA considerations sections and the group have their own IANA considerations sections and
requirements. requirements.
13. Security Considerations 14. Security Considerations
Any expansion of permitted characters and encoding forms in email Any expansion of permitted characters and encoding forms in email
addresses raises some risks. There have been discussions on so addresses raises some risks. There have been discussions on so
called "IDN-spoofing" or "IDN homograph attacks". These attacks called "IDN-spoofing" or "IDN homograph attacks". These attacks
allow an attacker (or "phisher") to spoof the domain or URLs of allow an attacker (or "phisher") to spoof the domain or URLs of
businesses. The same kind of attack is also possible on the local businesses. The same kind of attack is also possible on the local
part of internationalized email addresses. It should be noted that part of internationalized email addresses. It should be noted that
the proposed fix involving forcing all displayed elements into the proposed fix involving forcing all displayed elements into
normalized lower-case works for domain names in URLs, but not email normalized lower-case works for domain names in URLs, but not email
local parts since those are case sensitive. local parts since those are case sensitive.
skipping to change at page 20, line 30 skipping to change at page 20, line 38
while this specification does not address or solve the issues raised while this specification does not address or solve the issues raised
by DKIM and other signed header mechanisms, the issues will have to by DKIM and other signed header mechanisms, the issues will have to
be coordinated and resolved eventually if the two sets of protocols be coordinated and resolved eventually if the two sets of protocols
are 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.
14. Acknowledgments 15. Acknowledgments
This document is an update to, and derived from, RFC 4952. This This document is an update to, and derived from, RFC 4952. This
document would have been impossible without the work and document would have been impossible without the work and
contributions acknowledged in it. The present document benefited contributions acknowledged in it. The present document benefited
significantly from discussions in the EAI WG and elsewhere after RFC significantly from discussions in the EAI WG and elsewhere after RFC
4952 was published, especially discussions about the experimental 4952 was published, especially discussions about the experimental
versions of other documents in the internationalized email versions of other documents in the internationalized email
collection, and from RFC errata on RFC 4952 itself. collection, and from RFC errata on RFC 4952 itself.
Special thanks are due to Ernie Dainow for careful reviews and Special thanks are due to Ernie Dainow for careful reviews and
suggested text in this version. suggested text in this version.
15. References 16. References
16.1. Normative References
15.1. Normative References
[ASCII] American National Standards Institute [ASCII] American National Standards Institute
(formerly United States of America (formerly United States of America
Standards Institute), "USA Code for Standards Institute), "USA Code for
Information Interchange", ANSI X3.4-1968, Information Interchange", ANSI X3.4-1968,
1968. 1968.
ANSI X3.4-1968 has been replaced by newer ANSI X3.4-1968 has been replaced by newer
versions with slight modifications, but the versions with slight modifications, but the
1968 version remains definitive for the 1968 version remains definitive for the
skipping to change at page 22, line 13 skipping to change at page 22, line 21
and Document Framework", RFC 5890, and Document Framework", RFC 5890,
August 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 16.2. Informative References
[EAI-MUA-issues] EAI WG, "Still-unnamed proposed document on [EAI-MUA-issues] EAI WG, "Still-unnamed proposed document on
MUA issues", Not assigned or agreed to yet, MUA issues", Not assigned or agreed to yet,
2011. 2011.
Note to IESG and RFC Editor: While there is Note to IESG and RFC Editor: While there is
provision for a document on this subject in provision for a document on this subject in
the WG Charter, there is, as yet, no plan the WG Charter, there is, as yet, no plan
for producing it or even for adding it to for producing it or even for adding it to
the WG's task list with benchmarks. If the the WG's task list with benchmarks. If the
skipping to change at page 28, line 26 skipping to change at page 28, line 40
A.5. Changes between -04 and -05 A.5. Changes between -04 and -05
o Several more minor editorial changes. o Several more minor editorial changes.
A.6. Changes between -05 and -06 A.6. Changes between -05 and -06
o Corrections to more precisely reflect RFC 2119 language o Corrections to more precisely reflect RFC 2119 language
requirements and closely-related issues.. requirements and closely-related issues..
A.7. Changes between -06 and -07
o Added a new section (now Section 12) to explicitly discuss the
changes from the previous version.
o Removed the discussion of LMTP from Section 11; it is more
appropriately placed in the SMTP Extension document (5336bis).
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
 End of changes. 15 change blocks. 
30 lines changed or deleted 46 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/