Home / Blogs

Making Multi-Language Mail Work (Part 2)

John Levine

In the previous installment we looked at the software changes needed for mail servers to handle internationalized mail, generally abbreviated as EAI. When a message arrives, whether ASCII or EAI, mail servers generally drop it into a mailbox and let the user pick it up. The usual ways for mail programs to pick up mail are POP3 and IMAP4.

The new EAI RFCs define extensions to both POP and IMAP to handle EAI mail. Part of the extension simply lets a client (the user mail program) ask a server whether is has EAI capabilities, and if so enable them. This is the way a server can tell whether a client can handle EAI mail. Other extensions enable UTF-8 login names and passwords. For IMAP, they enable UTF-8 names for subfolders, and for POP, the server can provide the text part of responses in languages other than the default English.

If a mailbox contains EAI messages, and a client can handle EAI, the client just picks them up as usual. But if a client can't handle EAI, none of the options are great. One possibility is simply not to show the client the EAI messages, or to replace them with a placeholder that says something like to see this message, update your mail program. This may seem like a cruel joke (we're not going to show you your mail, neener neener), but in some environments, particularly ones where the local language isn't written in Roman characters and users are all expected to upgrade, it can make sense.

The softer alternative is to downgrade the messages, give the user an ASCII version of the message that more or less matches the original. The experimental predecessor to EAI tried valiantly to create downgraded messages that captured the complete original and failed. There are two remaining approaches to creating the downgrade at message retrieval time. The more complicated one encodes the non-ASCII material in a way that a suitably aware mail client could mostly reverse, adding Downgraded-whatever: headers for MIME-encoded versions of headers that don't allow MIME encoding, and a stylized way of representing non-ASCII addresses as MIME comments in address lines.

The less complicated one just makes the minumum changes required to get an ASCII message, without trying to preserve everything. I prefer the simpler approach; any effort spent making mail programs handle the more complex downgrades would better be spent making them handle EAI directly, and in either case, the most likely reaction by a human user is to go find an EAI mail client (web mail perhaps) if she wants to reply to an EAI address.

In the last part of this series, we'll see the surprisingly minor changes needed to make user mail programs handle EAI messages.

By John Levine, Author, Consultant & Speaker. More blog posts from John Levine can also be read here.

Related topics: Email, Multilinguism

 
   
WEEKLY WRAP — Get CircleID's Weekly Summary Report by Email:

Comments

To post comments, please login or create an account.

Related Blogs

Related News

Explore Topics

Industry Updates – Sponsored Posts

Port25 Announces Release of PowerMTA V4.5r5

Verisign Announces .コム Domain Names Are Now Available for Anyone to Register

New Case Study: Jobtome.com Replaces 30 Postfix Servers with a Single PowerMTA

Verisign Launches New gTLDs for the Korean Market, .닷컴 and .닷넷

Verisign Opens Landrush Program Period for .コム Domain Names

An Update on Port25 and the Future of PowerMTA - One Year Later​

Encrypting Inbound and Outbound Email Connections with PowerMTA

V12 Group Sustains Customer Satisfaction by Deploying PowerMTA for Launchpad Platform

Priority Access Program for Verisign's First IDN New gTLD, .コム

PowerMTA Now Offers Scheduled Delivery Control

DKIM for ESPs: The Struggle of Living Up to the Ideal

Reactivation Campaign: Shared vs. Dedicated IPs

To Where are Bounce Messages Sent?

An Open Source Perspective on Commercial MTAs

Five Essential PowerMTA Configuration Tips

What's New With Port25's PowerMTA v4.5

New Feature in PowerMTA v4.5: IP Based Rate Limiting

Case Study: Emergency Response Systems Rely on Timely Messaging Through PowerMTA

Port25 Announces Next Major Release of Its Email Delivery Solution, PowerMTA

Case Study: How PowerMTA Transparent Deliverability Metrics Paves Way for Email Service Provider

Sponsored Topics

Afilias

DNS Security

Sponsored by
Afilias
Afilias - Mobile & Web Services

Mobile

Sponsored by
Afilias - Mobile & Web Services
Verisign

Security

Sponsored by
Verisign
Port25

Email

Sponsored by
Port25