Mail software consists of a large number of cooperating pieces, described in RFC 5598. A user composes a message with a Mail User Agent (MUA), which passes it to a Mail Submission Agent (MSA), which in turn usually passes it to a sequence of Mail Transfer Agents (MTAs), which eventually hand it to a Mail Delivery Agent (MDA) to place it in the user’s mail store. If the recipient user doesn’t read mail on the same computer with the mail store (as is usually the case these days) POP or IMAP transfers the mail to the recipient’s MUA.

EAI affects all of these pieces. In this article we’ll look at some parts that don’t directly interact with users, MSA, MTA, and MDA.

EAI Mail Submission

As I described in last year’s articles, EAI creates a new parallel mail stream that can handle mail with UTF-8 characters in the mailbox name and other places that traditional SMTP mail doesn’t. The MSA uses a new option code, SMTPUTF8, to tell MUAs that it can handle EAI mail. When an MUA submits a message that needs EAI features, it in turn uses the SMTPUTF8 option to say that this is an EAI message.

Since there will be parallel EAI and non-EAI mail streams for a long time, MSAs will have to support both, so for each submitted message, an MSA has to remember what kind of message it is, and a well-written MSA will try to verify whether an EAI message can actually be delivered. For example, if an EAI message is sent to an ASCII address, and the address happens to be handled by the same mail server as the MSA, it may be able to check whether that address is enabled for EAI mail, and if not immediately reject the message.

Since it is legal, albeit sloppy, to submit an ASCII message but set the UTFSMTP8 option, the MSA might check to see whether it’s really an ASCII message, what I’ve called Deep Message Inspection, and if so treat it as one. Or if the recipient can’t handle EAI, but the MSA happens to know that the submitting user also has an ASCII address and the message doesn’t have other characteristics that require EAI, it is allowed (not required) to rewrite the message using ASCII addresses and turn it into an ASCII message.

EAI Mail Transfer

MTAs will also need to manage two mail streams, for ASCII and EAI mail. If an MTA receives an EAI message for an ASCII-only recipient, it will typically reject or bounce it. (The experimental predecessor of EAI tried to invent a general purpose EAI to ASCII downgrade scheme, but it turned out to be flaky and unworkable.) It could also do Deep Message Inspection to check whether EAI messages are in fact ASCII messages, and handle them as such. As mail is relayed to other MTAs, it needs to check that a recipient MTA for an EAI message supports UTFSMTP8 and if not, to bounce the message back to the sender.

EAI Mail Delivery

Some mail systems may make a “flash cut” so that all of their mailboxes handle EAI. Others may let users upgrade individually, as they upgrade their user mail software to handle EAI. In the latter case, the MDA needs to remember who handles EAI and who doesn’t, so it can bounce EAI mail to non-EAI mailboxes. Alternatively, even if not all users have EAI software, a mail system can accept EAI mail to every mailbox, let the POP or IMAP server deal with the incompatibilities when the user tries to pick up the mail.

In our next installment, we’ll look at what happens when there’s EAI mail in an ASCII user’s mailbox.