In previous surveys, we have noted the problems associated with using an IDN as part of an email address. In 2018, our research continues to discover isolated initiatives that attempt to provide Email Address Internationalisation (EAI), but, discouragingly, no progress toward internet-wide success. It is almost impossible for two people, using different email providers, to exchange internationalised email.
Components of an email address
Email addresses consist of two parts separated by an “@” symbol. At the front of the “@” symbol is a string called the user portion (technically known as the “local-part”). Behind the “@” symbol is usually a domain name. To achieve universal acceptance of IDNs we should be able to use any IDN as the domain name and also use the non-ASCII script for the user portion. Not only should we be able to address email with these internationalised addresses, but we should be able to send and receive them as well. A system that allows a user to address email, and send and receive it with IDNs is often referred to as Email Address Internationalisation (EAI).
We should be able to use email addresses that look like:
It is crucial to understand that this does not just apply to the top-level of the domain name. In a fully EAI compliant system, we should be able to use IDNs anywhere in the domain name string where they are legally permitted by IDN and registry standards.
There are two, crucial challenges that need to be overcome, before EAI is achievable:
- The client software (for instance, Outlook or Thunderbird) needs to be able to display, process and store the internationalised address. For instance, the client software should display EAI addresses in Unicode, while passing the domain name to the mail server in Punycode.
- The server software must support EAI and allow for the transfer of the mail in a manner that preserves the EAI address.
In 2018, we can report further limited progress on the first challenge, but the second challenge remains an enormous obstacle to the success of EAI.
Whenever an email is sent, it passes through mail servers at different stages of delivery. Traditional, legacy mail servers, mail clients, and web-based email services will usually only handle message headers containing ASCII characters. This is the fundamental problem for EAI in 2018. While several email clients are available that support EAI fully, and while there are a limited number of email servers and systems that support EAI, a single legacy mail server in the transmission chain between sender and recipient will make the EAI mail fail.
Correspondents trying to receive email from senders with addresses using extended character sets would not be able to do so in a traditional mail client, or through a web-based mail system. In the past, mail servers would try to re-encode data in a non-native way that caused the recipient to receive incomplete headers or information within an email. This would occur because a mail system would first take a message header and convert it to the character set native to the system, which is not always successful.
Native EAI support has appeared in a variety of settings
In 2014 came the support for both the transport and addressing of internationalised email at Gmail. This was an important development because, as we have seen, mail servers need to be standards compliant just as much as mail clients. Support for ‘transport’ of internationalised email means that internationalised email can be passed through and delivered using Google’s servers. However, as we have seen above, there is no guarantee that internationalised email passing through other servers will be forwarded correctly. Indeed, while you can use EAI in Gmail, Google continues to not allow users to use an internationalised email address for a Gmail account.
In Russia, we also have seen Yandex.Mail, a service with over 300 million users, begin to provide support for transport of internationalised email. Unlike Gmail, Yandex allows for registration of addresses with an IDN as the domain-part of the address (it does not yet support registration of internationalised strings in the user portion). In looking at its incoming email, Yandex reports that is seeing more than 1 billion incoming email messages a week.
In August of 2017, the Indian government announced plans to issue fully Hindi-script email addresses to some five million civil servants. The Ministry of Electronics and Information Technology announced the move, which will see each government employee given an @सरकार.भारत email address.
According to the Ministry, सरकार.भारत transliterates as “sarkar.bharat”, or “government.india”. The press release for the announcement indicates that exploiting local scripts in India is less of a motivation than regaining local control of information. The Ministry states, “the primary trigger behind the policy was Government data which resides on servers outside India and on servers beyond the control of the Government of India.” While this development means that civil servants in India will be able to exchange internationalised email with each other, it does not mean that they will be able to use EAI with every correspondent outside the system.
In 2018, Microsoft announced that EAI is now enabled in Exchange Online and Exchange Online Protection for Office 365. This means that Office 365 users can now send messages to and receive messages from internationalized email addresses. At the same time Microsoft announced that EAI was also enabled for outlook.com customers (including hotmail.com, live.com, etc.). Microsoft is also working to enable EAI for Exchange Server 2019, the on-premises version of Exchange that will come out later in 2018.
This is consistent with the deployments we have found on the server-side. We find a group of systems, sometimes with large subscriber bases, that allow for the exchange of EAI mail between subscribers on the same system. When exchanging email with compatible external systems, for instance, Gmail, the EAI features of the mail can be preserved. However, general purpose support for broad use of EAI email is still not available.