Section background image

Email

Email and IDNs

Email and IDNs

For universal acceptance, there are two, huge challenges that seem to prevent true internationalisation of the Internet. The use of IDNs as personal identifiers, and Email Address Internationalisation (EAI).

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.

For all its utility, electronic mail is surprisingly complex. Even the human-facing component can be a standalone piece of software (e.g. Outlook), a web page (e.g. the basic interface to Gmail), or a mobile client that simply queries a server and synchronises its view of the available email with that of the server. On the server side, there are two major ways to arrange for the pickup of electronic mail. Finally, in between the sender and receiver are mail transmission agents (MTAs) that arrange for the forwarding of email from one place to another.

Electronic mail works because all of these components are standardised – they are interoperable. Interoperability means that any computer, running any software can connect any way it likes to the Internet and send and receive email – as long as it abides by the standards for email. Electronic mail is so complex that Internet Engineering Task Force (the standards development organisation) has published a guide to understanding the entire ecosystem.

The standards that make up the traditional electronic email ecosystem are very old (the basic Internet email format was codified in 1977). The installed base of servers and clients is also extremely large. Those two facts, taken together, make change to the email ecosystem very challenging.

Older, legacy, email messages consist of three parts: the envelope, the headers and the body.

  • The envelope of the message contains metadata or information about the message (e.g. when it was received, the size of the message, how important it is, etc.).
  • The header is a set of fields such as the sender address, the subject, the date the message was sent and other information provided by the sender of the message.
  • The body of the message contains the text of the message and any attachments.

When a message is sent, the sender provides “From:” and “To:” addresses as well as a “Subject:” and the content of the message. As we have seen above, the legacy address is of the form [email protected] name. The domain name part is an LDH-based string and the local part can be arbitrary ASCII characters. The fundamental problem for EAI is changing email so that it can use internationalised scripts in both the local part and the domain name.

Because the underlying system has so many parts, solving the EAI problem is quite complex.

At a high level, solving the problem seems simple. When a user agent (e.g. Outlook) wants to send an EAI message to another user, it needs to be sure that all the infrastructure between sender and receiver, plus the receiver itself, can handle the email. For one of the two major mail protocols, SMTP, the solution is in an extension to the older email standards. Computer applications can test whether the receiving computer can support the extension that supports EAI, called SMTPUTF8.

That seems easy, but what happens when a sender can’t find a receiver that handles SMTPUTF8? What happens when the message is delivered to the recipient, but they do not have a user agent that can handle EAI?

In fact, the technical, standardised solution for EAI has been around for more than a decade. However, the related infrastructure and deployment challenges still remain. 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.
Top