E-mail Address Internationalisation (EAI)

This article does not attempt to provide a complete summary of all IETF activities in this area. It reflects the author’s personal perspective on some current highlights.

Shortly after the internationalised e-mail and extensions (IEE) BoF that was reported in the IETF Journal, Volume 1, Issue 2, a new working group in the Applications Area was formed called E-mail Address Internationalisation, or EAI. The WG, chaired by Xiaodong Lee and Harald Alvestrand, has met three times at IETF meetings and has held one interim meeting, in Beijing.

The following charter is excerpted from

This working group will address one basic approach to e-mail internationalisation. That approach is based on the use of an SMTP [Simple Mail Transfer Protocol] extension to enable both the use of UTF-8 [8-bit unicode transformation format] in envelope address local-parts and optionally in domain-parts and the use of UTF-8 in mail headers – both in address contexts and wherever encoded-words are permitted today. Its initial target will be a set of experimental RFCs that specify the details of this approach and provide the basis for generating and testing interoperable implementations. Its work will include examining whether “downgrading” – transforming an internationalised message to one that is compatible with unextended SMTP clients and servers and unextended MUA [mail user agent] – is feasible and appropriate and, if it is, specifying a way to do so. If it is not, the WG will evaluate whether the effort is worth taking forward. Other approaches may be considered by the formation of other working groups.

As of this writing, the WG has the following Internet Drafts in the agenda. All were discussed at IETF 67 in November:

  • draft-ietf-eai-framework
    Presents an overview of, and the framework for, the approach described in the charter. This is a good one-stop reading if you want to quickly find out how all of this is supposed to work.
  • draft-ietf-eai-scenarios
    Describes possible scenarios that an EAI solution will have to deal with, defining what the acceptable behaviour for a technical solution would be and thus constraining the space of possible alternatives.
  • draft-ietf-eai-smtpext
    Describes an SMTP service extension that enables mail transmission agents (MTAs) to signalise to their clients EAI support.
  • draft-ietf-eai-utf8headers
    Defines a representation – in UTF-8 – of certain mail header field bodies.
  • draft-ietf-eai-downgrade
    Defines mechanisms for backward compatibility, so that EAI mail can be transported even through non-EAI-aware MTAs. Downgrading is the generic term used for any kind of conversion mechanism employed for allowing this.
  • draft-ietf-eai-mailinglist
    Illustrates issues with mailing lists that need to be considered and that are not listed in the scenarios document. Mailing lists are interesting environments inasmuch as mails are received by software and then reinjected into mail transport for users to receive, many of whom, without any a priori knowledge on the original sender’s side, might or might not be users of EAI addresses.
  • draft-ietf-eai-pop
    Extends the Post Office Protocol version 3 (POP3) (RFC 2449) to support without encodings characters beyond ASCII in user names, mail addresses, and other message headers. This document also takes the opportunity to support localisation of protocol-level textual errors into different languages.
  • draft-ietf-eai-imap-utf8
    Extends the Internet Message Access Protocol version 4rev1 (IMAP) (RFC 3501) to support without encodings characters beyond ASCII in user names, mail addresses, and other message headers.

During the most recent group meeting, it was decided that the framework document was ready to go to the IESG after passing working group Last-Call. It became clear, too, that a new document on a service extension to Delivery Status Notifications (DSN) for SMTP (cf RFC 3461) with EAI support was necessary. A high note during the meeting was the reaching of consensus on representation of an alternative ASCII address for a given EAI. This ASCII address would be specified by the user – if it is known to the user at the moment of mail submission – and it would then look like this:

<utf8@utf8 <ascii@ascii>>
For instance,
<chimä <>>

Unfortunately, there were disagreements in the room as well. There is still ongoing discussion about whether the introduction of a marker header field that would identify a message (in transit or not) as an EAI mail is really necessary. Also controversial was the issue of the appearance of raw UTF-8 in multipurpose Internet mail extension (MIME) headers (a usual situation when dealing with file names, for instance) and how to handle it. One possibility could be to downgrade it by means of RFC 2047 mechanisms when it’s outside quotes and RFC 2231 mechanisms when it’s inside quotes. Alternatively, it could be possible to deprecate RFC 2231 and use the RFC 2047 technique.

Regarding the running-code part of the proverbial saying, there’s an implementation in Perl by the Taiwan Network Information Centre (TWNIC) based on sendmail together with Milter and Mimedefang. In parallel, the China Internet Network Information Centre (CNNIC) has developed an implementation based on qmail. The existence of two independent implementations has allowed for intercompatibility tests.

If you want to get involved, do it now, because the current plans of this hardworking group are to have all the documents ready before the next IETF meeting in Prague!

RFC 2449: POP3 Extension Mechanism. R. Gellens et al., Nov. 1998.
RFC 3501: Internet Message Access Protocol, Version 4rev1. M. Crispin, March 2003.
RFC 3461: Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs). K. Moore, Jan. 2003.
RFC 2047: MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text. K. Moore, Nov. 1996.
RFC 2231: MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations. N. Freed, K. Moore, Nov. 1997.

No Comments to Show

Leave a Reply

Your email address will not be published. Required fields are marked *