Internet DRAFT - draft-elkchow-iea-deploy
draft-elkchow-iea-deploy
INTERNET-DRAFT N. Elkins
Intended Status: Informational Inside Products
H. Chowdhary
NIXI
Expires: April 7, 2017 October 4, 2016
Deployment Issues for Internationalized Email
draft-elkchow-iea-deploy-00
Abstract
International Email Addresses (IEA) are far from the global reality. The
current de-facto language of the Internet is English. Even today, many
of the users of the Internet do not speak English as their primary
language. The next billion users of the Internet are likely to be even
less familiar with English. IEA is probably the first application needed
in a truly internationalized Internet. The Email Address
Internationalization (EAI) Working Group defined the RFCs to support
internationalized email. The time may now finally have come to develop
best practices and to discuss the deployment challenges for IEA.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
N. H. Elkchow Expires April 7, 2017 [Page 1]
INTERNET DRAFT draft-elkchow-idniea-deploy-00 October 4, 2016
Copyright and License Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Punycode . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Single Language / Multiple Languages . . . . . . . . . . . 4
2 Email Servers . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1 Backend Databases . . . . . . . . . . . . . . . . . . . . . 5
3 Email Clients . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1 Display of Email ID . . . . . . . . . . . . . . . . . . . . 5
3.2 Display of Email Body . . . . . . . . . . . . . . . . . . . 5
3.3 Messages Routed to SPAM . . . . . . . . . . . . . . . . . . 6
4 Multiple Identities / Aliases . . . . . . . . . . . . . . . . . 6
5 Email Address Books . . . . . . . . . . . . . . . . . . . . . . 6
6 Security Considerations . . . . . . . . . . . . . . . . . . . . 6
6.1 Homographic Attacks . . . . . . . . . . . . . . . . . . . . 6
6.2 Use of Mixed Scripts . . . . . . . . . . . . . . . . . . . 7
6.3 Right-to-left Issues . . . . . . . . . . . . . . . . . . . 7
7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1 Normative References . . . . . . . . . . . . . . . . . . . 7
8.2 Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
N. H. Elkchow Expires April 7, 2017 [Page 2]
INTERNET DRAFT draft-elkchow-idniea-deploy-00 October 4, 2016
1 Introduction
The Email Address Internationalization (EAI) Working Group, which has
concluded, created a structure and framework for internationalized
email addresses. From the charter:
"The email address has two parts, local part and domain part. Email
address internationalization must deal with both. This working
group's previous experimental efforts investigated the use of UTF-8
as a general approach to email internationalization. That approach is
based on the use of an SMTP extension to enable the use of UTF-8 in
envelope address local-parts, optionally in address domain-parts, and
in mail headers. The mail header contexts can include both addresses
and wherever existing protocols (e.g., RFC 2231) permit the use of
encoded-words." [EAICharter]
Much work was done in this group including:
RFC 6530 : Overview and Framework for Internationalized Email
[RFC6530]
RFC 6531 : SMTP Extension for Internationalized Email [RFC6531]
RFC 6532 : Internationalized Email Headers [RFC6532]
RFC 6533 : Internationalized Delivery Status and Disposition
Notifications [RFC6533]
RFC 6783 : Mailing Lists and Non-ASCII Addresses [RFC6783]
RFC 6855 : IMAP Support for UTF-8 [RFC6855]
RFC 6856 : Post Office Protocol Version 3 (POP3) Support for UTF-8
[RFC6856]
RFC 6857 : Post-Delivery Message Downgrading for Internationalized
Email Messages [RFC6857]
RFC 6858 : Simplified POP and IMAP Downgrading for Internationalized
Email [RFC6858]
Yet, deployment lags. Global EAI is far from the reality.
The Internet is getting bigger day by day by integrating top level
domains using non-ASCII based scripts i.e Devanagari,Cyrillic,Arabic,
Chinese etc. These new top level domains need to be able to send
emails as well as to access web sites via browsers.
If a user has an internationalized email address, then it should be
possible to send/ receive to/from any email address using any email
client. This interoperability demands concerted efforts by all major
email service providers. Even now, there is very limited or no
support in email servers (SMTP, IMAP, POP), email providers (Gmail,
Yahoo, Hotmail) and email clients.
Often, it is not even possible to create an email ID for end-users in
N. H. Elkchow Expires April 7, 2017 [Page 3]
INTERNET DRAFT draft-elkchow-idniea-deploy-00 October 4, 2016
a non-ascii based language while many Internationalized Domain Names
(IDN) exist. This is of major concern to many in the parts of the
world where the primary language is not English.
1.1 Punycode
Languages not based on the Latin script (A, B, C, etc) use unicode to
represent the letters in their alphabet rather than ASCII. Punycode
is used to show unicode characters in ASCII format. It is used in
the transport of email.
For example:
English: Nehru
Hindi: ????? [Cannot be displayed]
Punycode: xn--l2bq0a0bw
Punycode will start with the prefix: "xn--".
An application handling IDN domains has to reference an IDN
repository to know how to display them. Emails add to the
complication since many email systems pre-date the introduction of
IDNs. These systems often simply reject emails that don't work within
the old domain name model.
1.2 Single Language / Multiple Languages
Some people ask, "What if I send an email in Russian and want to
respond in Chinese?" What problems will arise?
This is certainly an important issue but it is hard enough to send
emails back and forth in one non-ASCII based language. This draft
will leave for the future the issues of multiple languages with the
accompanying translation and user interface issues.
2 Email Servers
For an email server to be ready for EAI, it must implement:
RFC 6530 : Overview and Framework for Internationalized Email
[RFC6530]
RFC 6531 : SMTP Extension for Internationalized Email [RFC6531]
RFC 6532 : Internationalized Email Headers [RFC6532]
Here is a partial list of servers and test beds for EAI:
N. H. Elkchow Expires April 7, 2017 [Page 4]
INTERNET DRAFT draft-elkchow-idniea-deploy-00 October 4, 2016
PostFix 3.0 and above
Coremail
Throughway (Thailand)
OpenMail (Taiwan)
EAI test environment (Saudi Arabia)
Xgenplus (INDIA)
2.1 Backend Databases
The email servers store data in relational databases such as MySQL
and MariaDB. These databases must support UTF-8 and be configured
to use UTF-8. There may need to be both Punycode and UTF-8 fields
defined on occasion.
3 Email Clients
Since the email client is the interface to the user, here is where a
number of issues arise. There are a number of email clients services
providers that support EAI to various extents. A partial list
follows:
Coremail
Horde Project
Microsoft Outlook 2016 for PC
Gmail - to some extent
Apple Mail - to some extent
Throughway (Thailand)
OpenMail (Taiwan)
EAI test environment (Saudi Arabia)
Roundcube
3.1 Display of Email ID
The email ID is often shown in Punycode. For example, the email id:
harish@nalini.bharat in Hindi is:
???????@??????.?????? [cannot be displayed]
This email ID will be displayed in many email clients in Punycode.
That is, the email ID will be shown as: xn--t2bmh3a@xn--l2ba3a4cg.xn-
-h2brj9c. This is not particularly user-friendly.
3.2 Display of Email Body
The issue with the email body have to do with an easy ability to type
in the language of choice. A number of browsers have extensions to
allow this.
N. H. Elkchow Expires April 7, 2017 [Page 5]
INTERNET DRAFT draft-elkchow-idniea-deploy-00 October 4, 2016
But when it comes to displays of links containing IDN names, often
the link does not work.
3.3 Messages Routed to SPAM
Messages may be routed by email clients to SPAM if they are not in
English.
4 Multiple Identities / Aliases
A user may have multiple identities. That is, he / she may have an
English language email ID, a Hindi email ID, and so on.
5 Email Address Books
Email address books today have little or no support for addresses in
non-Latin based languages.
6 Security Considerations
6.1 Homographic Attacks
A user on Internet can be easily duped with Russian letters 'a, e, p,
or y' as they are indistinguishable in writing from their English
equivalents. A number of the letters (such as "a") are closely look
alike etymologically, whereas others look similar by sheer
coincidence. for example, Russian letter p is really pronounced like
r, however the glyphs of both the letters are identical. Russian
isn't the single such language; other Cyrillic languages could cause
similar collisions.
For example paypal.com and paypal.com are look alike however first
domain name contains the Russian letter "a" while other contains
English letter "a",further it can lead to similar-looking e-mail IDs
such as Nalini@paypal.com,and Nalini@paypal.com ;both are similar in
view however different e-mail IDs in reality.In this case,the
characters used for the fraud are perfectly legitimate.
Therefore numerous English domain and e-mail IDs may be homographed -
that is, maliciously misspelled by substitution of non-Latin letters.
A number of approaches may be utilized to protect against this sort
of attack. the best fix would indiscriminately forbid domain names
that combine letters from totally different alphabets, but this will
block actually helpful names like "CNNenEspanol.com". [Note: the 'n'
in Espanol has a ~ on the top] Alternatively, the browser may
highlight international letters existing in domain names with a
separate color, although users might find this system excessively
intrusive.
N. H. Elkchow Expires April 7, 2017 [Page 6]
INTERNET DRAFT draft-elkchow-idniea-deploy-00 October 4, 2016
Browsers may solely highlight really suspicious names, like ones that
blend letters from different scripts inside one single word. For
additional security, the browser may use a map of identical letters
to look for collisions between the requested domain and equally
written registered ones. If critical, it would then warn the user of
suspected fraud
6.2 Use of Mixed Scripts
Legitimate uses for mixed scripts in both Japanese and Chinese are
also possible, and many people use Latin usernames with IDN domains.
6.3 Right-to-left Issues
Some languages, for example, Arabic, are written right-to-left.
Systems created to work with Arabic script typically switch when the
first Arabic character is entered. But with a mixed script email
address such as 'customer.care@[IDN domain].IDN', the system needs to
be able to handle both left-to-right and right-to-left scripting.
This could be an additional potential security issue. If someone
registers the domain name "customer.helpline" in this scenario, they
could type in the Arabic script first (username), triggering an email
system to switch to right-to-left and then put in the domain
"customer.helpline". It would appear in the input box as though
"customer.helpline" was the username on the left-hand side of the
email address. The only difference would be that the whole address
would be aligned right.
7 IANA Considerations
There are no IANA considerations.
8 References
8.1 Normative References
[RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for
Internationalized Email", RFC 6530, February 2012.
[RFC6531] Yao, J. and W. Mao, "SMTP Extension for Internationalized
Email", RFC 6531, February 2012.
[RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized
Email Headers", RFC 6532, February 2012.
[RFC6533] Hansen, T., Newman, C., and A. Melnikov,
"Internationalized Delivery Status and Disposition Notifications",
N. H. Elkchow Expires April 7, 2017 [Page 7]
INTERNET DRAFT draft-elkchow-idniea-deploy-00 October 4, 2016
RFC 6533, February 2012.
[RFC6783] Hansen, T., Newman, C., and A. Melnikov, " Mailing Lists
and Non-ASCII Addresses", RFC 6783, November 2012.
[RFC6855] Resnick, P., Ed., Newman, C., Ed., and S. Shen, Ed., "IMAP
Support for UTF-8", RFC 6855, March 2013.
[RFC6856] Gellens, R., Newman, C., Yao, J., and K. Fujiwara, "Post
Office Protocol Version 3 (POP3) Support for UTF-8", RFC 6856, March
2013.
[RFC6857] Fujiwara, K., "Post-Delivery Message Downgrading for
Internationalized Email Messages", RFC 6857, March 2013.
[RFC6858] Gulbrandsen, A., "Simplified POP and IMAP Downgrading for
Internationalized Email", RFC 6858, March 2013
8.2 Informative References
[EAICharter] https://datatracker.ietf.org/wg/eai/charter/, May 2010
Authors' Addresses
Nalini Elkins
Inside Products, Inc.
Carmel Valley, CA 93924
USA
Phone: +1 831 659 8360
Email: nalini.elkins@insidethestack.com
Harish Chowdhary
NIXI
India
Email: harish@nixi.in
N. H. Elkchow Expires April 7, 2017 [Page 8]