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.