Deployment issues for Internationalized Email

At IETF 97, I presented on an Internet Draft that I’ve been collaborating with Nalini Elkins on, which discusses deployment issues for International Email Addresses (IEA).

This work is an extension of the work being done on top level Internationalized Domain Names (IDN TLDs), which seek to enable domain names to have characters from scripts other than the English alphabet (a-z) and Arabic numerals (0-9), and to further reinforce the fact that the inclusion of other languages is needed to connect the next billion users.

What’s been done in this area and what are the issues?

In today’s world, email is a widely used communications tool for personal and official purposes, and as such, is one of the first applications new Internet users are exposed to.

Although bodies of emails have allowed for non-English texts for many years, it’s only been until IDNs and IEAs that users can use native languages for usernames, passwords, and addresses (for example, राम@भाषा.भारत). In doing so, this has made the need to know a small amount of English, just to access the Internet/email, redundant.

IEA protocols have been available since 2014, and the IETF’s Email Address Internationalization (EAI) Working Group, has invested a lot of time to create a structure and framework for internationalized email addresses, which include the following RFCs:

• RFC6530 : Overview and Framework for Internationalized Email
• RFC6531 : SMTP Extension for Internationalized Email
• RFC6532 : Internationalized Email Headers
• RFC6533 : Internationalized Delivery Status and Disposition Notifications
• RFC6783 : Mailing Lists and Non-ASCII Addresses
• RFC6855 : IMAP Support for UTF-8
• RFC6856 : Post Office Protocol Version 3 (POP3) Support for UTF-8
• RFC6857 : Post-Delivery Message Downgrading for Internationalized Email Messages
• RFC6858 : Simplified POP and IMAP Downgrading for Internationalized Email

However, the deployment and use of IEAs are still restricted to a handful of languages and there is very limited or no support for it offered by 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 a non-ASCII based language.

This ultimately impedes the potential of IDN TLDs as well, given that owners and users of these new TLDs need and want to send and receive emails from their sites.

Possible solutions to the issues

In an effort to overcome these issues, we recommend that a multistakeholder approach, including all I* organizations, is required to:

• Upgrade and support the deployment of email servers (open-source) to versions which support SMTPUTF8 (for example POSTFIX 3.0 or higher supports SMTPUTF8).
• Modify major libraries to support IDNs, with a goal of enabling IDN-EAI support in random signup forms, applications and mobile apps, particularly for all sites that cannot be persuaded to enable IEA support for online applications and web services.
• Increase awareness of IDNs and EAIs, which may include holding awareness workshops.

What can we do in the Asia Pacific?

The Internet community in the Asia Pacific needs to play an important role to help in this multistakeholder effort given that over 50% of all languages of the world are spoken and used in the region.

Establishing a platform and/or forum might be a suitable first step to develop awareness and collect information to deal with all the issues each community has in relation to using and accessing IEAs and IDNs.

Ultimately, the benefits of a multilingual Internet and the new users it will be accessible to will not be recognized until we solve these interoperability issues.

Harish Chowdhary attended IETF 97 as an ISOC Fellow and is a Technology Analyst at the National Internet Exchange of India (NIXI).

Rate this article

---

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.