In previous surveys we have noted that using IDNs in email is problematic at best and completely broken at worst.
Email addresses consist of two parts separated by an “@” symbol. At the front of the “@” symbol is a string called the local-part. Behind the “@” symbol is usually a domain name. For the purposes of 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 local part. Not only should we be able to address email with these internationalized addresses, but we should be able to send and receive them as well. A system that allows use to address email and send and receive it with IDNs is often referred to as Email Address Internationalization (EAI).
We should be able to use email addresses that look like:
There are a pair of key problems. First, the client must support the addressing of EAI email. Second, old versions of mail server software must be upgraded to support the new features of sending and receiving EAI email. This is a more complex problem than appears at first glance: all mail server infrastructure must support the new feature: POP severs, IMAP servers, indexing tools, search tools, anti-virus and anti-spam tools and mailing list software all must be upgraded. And, all links in the chain from sender to receiver must be EAI enabled.
In August of 2016, 150,000 mail servers were surveyed in Russia for support of EAI to see how prevalent acceptance of internationalization was. Less than ½ of one-percent of the servers surveyed were EAI enabled. Since EAI requires every link in the chain of email transit to be enabled, the current state of internationalized email in Russia is bleak. The key difference is that, in Russia at least, there is an on-going program of surveying the environment. In other countries no such regular survey of the email landscape exists.
In 2014 came the support for both the transport and addressing of internationalized email at Google. This was an important development because mail servers need to be standards compliant just as much as mail clients. In the case of Google’s announcement this means that internationalized email can be passed through and delivered using Google’s servers. However, as we have seen above, there is no guarantee that internationalized email passing through other servers will be forwarded correctly. Indeed, the Google announcement provides transport for international email but Google does not yet allow users to use an internationalized email address for a Gmail account.
This year some other services have begun to offer internationalized email. Yandex.Mail, a service with over 300 million users, now provides support for transport of internationalized 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 internationalized strings in the local part). In looking at its incoming email, Yandex reports that is sees more than 1 billion incoming email messages a week. Of these, about 350,000 per week have IDNs (almost always ccTLDs).
In India, Data XGen Technologies has introduced a smartphone email service that supports both IDN and local-part EAI addresses in eight Indian languages. On the client side, Microsoft provide support for EAI addresses for both Outlook 2016 and Office 365, although like Google, Microsoft does not let you set up an Office 365 account using an internationalized email address. The Thunderbird and Opera email clients support EAI for the IDN but not the local-part.
The result of these changes and announcements is continued growth for internationalised email but a patchwork quilt of capabilities. The routine monitoring of EAI capabilities – for instance, in Russia – is a welcome development and may spur some organisations to upgrade email infrastructure to support EAI. The hoped for effect of Google announcing support for internationalised email has not emerged: there are still very few cases where users can experience end-to-end delivery of internationalised email and universal acceptance seems a long way off.