Microsoft’s announcement that Office 365 “will enable Email Address Internationalization (EAI) support in Q1 2018” might seem in the less-than-interesting category, but it is an important step forward from the legacy of email history. And it addresses an issue where Microsoft lagged its major competitor, as Gmail reached the same point in August 2014.
SMTP email addresses, which are what we use to communicate across the internet, divide into mailbox names and domain names. Mailbox names go back to the earliest systems, where the operating systems of the time dictated what the characters could appear in a mailbox name and the length of mailbox names. Thus, IBM PROFS, a popular system in the 1980s, limited mailbox (and account) names to 8 ASCII 7-bit uppercase characters. VMS supports 12-character account names and we could send mail between systems from the early 1980s using DECnet and VMSmail with addresses like BISTRO::REDMOND (an actual address I used).
Big as IBM and DEC were in those days, they did not serve every customer and interconnectivity of email systems became an increasingly important issue. The earliest attempt to standardize email addresses came in X.400, a set of recommendations that first appeared in 1984.
The industry still considered X.400 to be an important email interconnect method when Exchange 4.0 appeared in 1986, but SMTP and its radically simpler email addresses rapidly obsoleted X.400. Microsoft recognized this development by including the Internet email connector in Exchange 5.0 (1997). Twenty years later, that decision means that every Exchange Online mail-enabled recipient (mailboxes, shared mailboxes, Office 365 Groups, etc.) has at least one SMTP address.
One of the major attractions of SMTP is the simplicity of its addressing scheme. RFC5321 sets down the rules for system implementers, but unlike most technical standards, even people outside the industry know that mailbox@domain is the way to address email. Email internationalization (EAI) sets the rules for non-ASCII characters in email addresses. As RFC6530 explains, “An internationalized email user” has one or more non-ASCII email addresses.”
In Q1 2018, Office 365 will support the ability to send to and receive messages from EAI addresses. However, Office 365 will not support assignment of these addresses to its mail-enabled recipients. This is reasonable as the step will allow Office 365 to start interacting with the relatively small number of email systems that support EAI addresses while Microsoft does the work needed before Office 365 mail-enabled recipients can have these addresses. Further work is also necessary before Office 365 can support internationalized domain names (IDN) for tenants.
Because Outlook desktop is used with non-Microsoft email servers, Outlook 2013 began the process of supporting EAI addresses based on early drafts of the relevant RFCs. Exchange servers handled messages that arrived in from systems that supported EAI, but only because the inbound traffic didn’t cause any problems. What’s different now is that Exchange Online supports the full recommendations of the final RFCs and can therefore guarantee the acceptance and transmission of email from and to EAI addresses.
Assigning EAI addresses to Office 365 recipients is not just like adding another SMTP address to an object. Office 365 is an ecosystem, and all parts of the ecosystem must be able to deal with EAI addresses. The bulk of the work is in Exchange Online because it is the email engine for the service, but many other applications use email or email addresses.
For instance, when you share a document with an external person through SharePoint Online or OneDrive for Business, you type their email address into the sharing dialog. When you add a guest user to Office 365 Groups or Teams, their email address is their identity. And because the process used to bring guest users into a tenant uses Azure B2B collaboration, Azure Active Directory must be able to process EAI addresses too. In short, developers must check and possibly update every part of Office 365 that uses email addresses before Microsoft can enable EAI addresses for tenants.
The hybrid connections supported by Office 365 pose other complications. Microsoft says that they will bring EAI support to on-premises servers, but so far, no detail is available as to which version. The most likely scenario is that Microsoft will use the EAI code from Exchange Online, but who knows what version it will turn up in. If you run a hybrid configuration and want to use EAI addresses, you will need the right software at both sides of the divide to support mailbox moves.
As Microsoft reminds us in their post, there are lots of non-English speakers in the world who might like to have non-Latin characters in their email addresses. It is good to see that Office 365 is shaking some of the dust of email’s history.
The next step will be to allow for emoticons in email addresses. Only joking!
Follow Tony on Twitter @12Knocksinna.
Want to know more about how to manage Office 365? Find what you need to know in “Office 365 for IT Pros”, the most comprehensive eBook covering all aspects of Office 365. Available in PDF and EPUB formats (suitable for iBooks) or for Amazon Kindle.