Shawn Steele | 7 Oct 21:06 2014


> (1) A conforming i19n SMTP ("EAI") implementation MUST be a
> conforming IDNA2008 implementation.  Can't have EAI without IDNA
> conformance.

I think that depends on the implementation.  EAI allows UTF-8 for most everything.  As pointed out it's
difficult to complete the SMTP handshake without having the punicode, however there are many other mail
related tasks that can be done without needing to know about IDNA?

For example, an application needn't send mail itself, it could gather the information it needed and then
use a compliant STMP library to actually send the message.  In that case the application itself may not need
to know anything about IDNA itself.

Indeed, I'd prefer that applications use IDN/DNS/Mail APIs that abstract away some of these details.

Ronald F. Guilmette | 6 Oct 06:25 2014

A simple question

Having just today skimmed... for the first time... RFC 6531, I have
a rather basic question.

It appears from my skimming that the first opportunity that either
an SMTP client or an SMTP server gets, under these protocol revisions,
to tell the other that it can support the new internationalized domain
names, is when the server responds to a client-initiated HELO or EHLO
command.  Is that correct?

If so, then I am wondering what sorts of encoding(s), if any, a client
will be allowed to use with respect to the domain name that it may
include within the HELO/EHLO command that it issues, i.e. before
either side of the conversation has said anything definitive about
what it can or can't support.  Must such domain names be represented
as Punycode?
Jiankang Yao | 25 Sep 08:19 2014

APEC EAI deployment meeting in Beijing

Dear all,
     CNNIC will host the APEC EAI deployment meeting in Beijing on 30 and 31 Oct. 2014.
      The meeting venue is  in Legendale Hotel Beijing ( ).
      The topic related to EAI deployment such as email history, IETF EAI protocol, current implementations, current deployment will be presented by speakers from all over the world in the first day.
      The panel discussion about how to push the EAI deployment will be arranged in the morning of the second day. After the meeting, we will arrange to visit CNNIC.
      Any interested persons are welcomed to join this meeting. If anyone has something to share in this meeting, pls kindly let me know it.
     BTW,  There is still an APEC sponsored speaker available. If It is approved by APEC, the APEC funding will provide economic air tickets and accomodation and Speaker’s honorarium to the APEC sponsored speaker.    
       If anyone is interested in becoming the APEC sponsored speaker , pls kindly let me know it.
Jiankang Yao
IMA mailing list
IMA <at>
Arnt Gulbrandsen | 5 Aug 22:48 2014

gmail deploying EAI

Shawn Steele | 31 Jul 21:14 2014

ASCII tunneling hack standardization

Back when we were still being active in discussion on this list I ran into scenarios where we needed to put EAI addresses in non-UTF-8 slots.  There was some discussion about whether or not fallback should be permitted, and I had some conversations with Mark Davis where we came up with a draft way of doing that.  However the group headed in the direction that addresses should NEVER be manipulated into some sort of ASCII slot, so I didn’t really follow up.


Anyway, in recent conversations with others, several people have mentioned putting the EAI addresses in non-UTF-8 aware slots for various reasons, so I’d like to bring this up again.  Basically the attached doc says 2 things:


A)     You SHOULD never shove EAI into UTF-8 slots...  but sometimes we don’t have that choice, so this is a hack until those cases get fixed.

B)      If you really, really need to, then punycode the raw local part, using the xl-- prefix to be clear that this isn’t IDN.  (no mapping step)


For various reasons about ship cycle and stuff, this is what’s implemented in Windows’ IdnToAscii() when passed the IDN_EMAIL_ADDRESS flag.


Note that you cannot ‘just’ use IDN on the local part because 1) local parts aren’t like DNS labels, and 2) IDN does all sorts of strange mapping, whereas mail explicitly doesn’t provide standard mappings; even case mapping is optional and can be left up to the server.


Our intent at the time was to publish this as an informational RFC, eg: “this is what we’re doing in the even we really need to abuse stuff and shove EAI addresses into non-EAI aware slots”.


It seems like I should go ahead and get it posted since implementers are diverging in the way they do things.  (There are currently 3 techniques I know about, at least one of which clearly damages the local part).


It’d be really cool if we could agree on this technique for when someone feels they need to hack the address into an ASCII slot.  Again, people should be using Unicode, but in the event something had to tunnel through an ASCII slot at least consistency on the methodology would give a chance of having fewer problems.



 


Attachment (EAI Tunneling in Non-Unicode Slots.docx): application/vnd.openxmlformats-officedocument.wordprocessingml.document, 78 KiB
IMA mailing list
IMA <at>
Arnt Gulbrandsen | 24 Jul 17:24 2014

client support


mutt ( and mailkit/mimekit 
( should have EAI support 
in their next versions. Vmime ( is also under way.

Arnt Gulbrandsen | 15 Jul 13:38 2014

I have received my first real EAI email

Ie. local delivery, IMAP server and IMAP client all working. If any of you 
want an EAI-capable IMAP/SMTP account, let me know. No spam filtering, but 
come to think of it maybe that's not a problem: There are no EAI-capable 
spammers yet.

Franck Martin | 13 Jul 04:46 2014

Where can I get a mailbox?

Which service would offer the creation of a mailbox with an EAI email address?

Printed on recycled paper!
Arnt Gulbrandsen | 11 Jul 11:13 2014

EAI autoresponder has been partly broken for a week or more

Sorry about that. Should be good again now.

RFC Errata System | 1 Jul 18:22 2014

[Errata Verified] RFC6855 (4029)

The following errata report has been verified for RFC6855,
"IMAP Support for UTF-8". 

You may review the report below and at:

Status: Verified
Type: Technical

Reported by: Chris Newman <chris.newman <at>>
Date Reported: 2014-06-27
Verified by: Barry Leiba (IESG)

Section: 3

Original Text
   Once an IMAP client has enabled UTF-8 support with the "ENABLE
   UTF8=ACCEPT" command, it MUST NOT issue a "SEARCH" command that
   contains a charset specification.  If an IMAP server receives such a
   "SEARCH" command in that situation, it SHOULD reject the command with
   a "BAD" response (due to the conflicting charset labels).

Corrected Text
   Once an IMAP client has enabled UTF-8 support with the "ENABLE
   UTF8=ACCEPT" command, it MUST NOT issue a "SEARCH" command that
   contains a charset specification.  If an IMAP server receives such a
   "SEARCH" command in that situation, it SHOULD reject the command with
   a "BAD" response (due to the conflicting charset labels). This also
   applies to any IMAP command or extension that includes a charset
   label and associated strings in the command arguments. Such
   extensions presently include SORT, THREAD and MULTISEARCH.

This is a straightforward extrapolation of the existing text, but a literal reading of the existing text is
silent about how to deal with this situation.

RFC6855 (draft-ietf-eai-5738bis-12)
Title               : IMAP Support for UTF-8
Publication Date    : March 2013
Author(s)           : P. Resnick, Ed., C. Newman, Ed., S. Shen, Ed.
Category            : PROPOSED STANDARD
Source              : Email Address Internationalization
Area                : Applications
Stream              : IETF
Verifying Party     : IESG
Arnt Gulbrandsen | 30 Jun 15:13 2014

EAI patch for Postfix takes another small step



and in many other locations you can now find the EAI-patched postfix. It is 
not release quality; there are known bugs and limitations. Two relevant 
bugs are that case is not always insensitive when it should be, and that 
compiling postfix with -DNO_EAI does not eliminate all traces of EAI 
support (e.g. some 6533-related code remains active). But it'll do for 
testing. I trust the code enough that I'll switch my private mail over to 

The code will be worked into the main release towards the end of this year. 
Wietse Venema will do that work, not I, and he's going to do it slowly, 
carefully and thoroughly. (Wietse is the main Postfix maintainer.)