Franck Martin | 15 Apr 11:24 2015


it seems that a few MTA can be thrown at an email with a EAI RFC5321.mailfrom and pass the message fine to other
MTA or local delivery, as long as the MTA supports 8BITMIME and the RFC5321.rcptto is a standard email

replying to such email is a challenge, but it does not seem any MTA or MUA (with 8BITMIME) will complain
because the RFC5321.from is an EAI...

What’s your experience?
IMA mailing list
IMA <at>
Arnt Gulbrandsen | 15 Apr 11:13 2015

FWIW, draft-ietf-dane-openpgpkey-03

Some of you might want to take an interest in that. Might.

My wife pointed me to it, I've glanced at it and a) it seems to copy 4255, 
which AFAICT hasn't been much of a success and b) it adds to PGP, ditto. I 
can't find any motivation to care. But perhaps one of you should, so it'll 
avoid gratuitous incompatibility with 6530.

John Bucy | 25 Mar 01:16 2015

SMTPUTF8 for non EAI messages

This is a spillover from a discussion on dmarc <at>

Has the wg considered the case of using SMTPUTF8 as a means to avoid 2047/2231 encoding for messages that don't contain any eai addresses? I understand eai avoids downgrading since it doesn't really work for addr-spec but it seems like it should be harmless for places where encoded-word is allowed along the lines of the "gateway transformation" described in 6152.

IMA mailing list
IMA <at>
Jiankang Yao | 19 Dec 16:27 2014

Chinese email address

Dear all, 

    For those who can recognize the Chinese character, you can log on the    Following link to register a Chinese email address. You can also have an opportunity to get iPhone 6 as a prize.

IMA mailing list
IMA <at>
Jiankang Yao | 8 Dec 07:27 2014

***SPAM*** 6.681 (5) Fw: apec-eai-ppt

Dear all,

   If any one is interested in the Beijing APEC EAI workshop, below are some ppt files for the agenda of 


Particularly, John's speech is also online  


Best Regards,

Jiankang Yao
IMA mailing list
IMA <at>
John C Klensin | 4 Dec 18:30 2014

Conversations in other forums, wiki changes, question about local-parts


As many of you know but some may not, not only was there a very
successful (at least IMO) meeting about the SMTPUTF8 extensions
and internationalized mail in Beijing at the end of October
(thanks to Jiankang Yao), but there has been a recent discussion
about address syntax in W3C forms and the W3C
internationalization group.  

A few issues have come up in the various discussions that
inspired me to make some changes to the WG Wiki.  You might want
to take a look at them and either edit or raise issues here if
you disagree.   If anything I've said seems controversial,
please do identify the issues here.

As a reminder, the wiki is at

In addition, the folks working on Forms, notably Steven
Pemberton (copied) have noticed that the mailbox local-part
syntax of RFC 6532 allows some truly nasty Unicode strings,
including strings that start with combining marks and that
therefore may be very hard to have as input.  My recollection is
that was an intentional decision and not a mistake -- as with
passwords, hard-to-type strings can sometimes be an advantage in
email addresses.   However, it seems to me that they are very
much like case-sensitive strings in RFC 5321: we insist that
those be treated as separate up to the point of final delivery,
we forbid any message originating systems from assuming case
equivalence, and forbid intermediate systems from performing
case folding.  Then we advise those creating mailboxes or
operating delivery servers that they probably should not take
advantage of case-independence except in special circumstances
because case sensitive addresses are almost certain to create
confusion and to be mishandled by badly-written implementations.

It seems to me that we should say much the same thing about
badly-formed Unicode strings: support for them is required but
delivery servers that allow creation of mailbox names containing
such strings had really better know what they are getting into
and, otherwise, probably shouldn't.

If there is general agreement about that principle (or no strong
objections) I'll patch a note into the Wiki so we can come back
to it and formally see if there is consensus when we review the
documents for Full Standard.

Of course, if my memory is wrong and allowing such strings was
just a mistake, someone should start a discussion on that
subject and we should figure out what to do about it.

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>