Subject: [EAI] Chinese email address

From: Jiankang Yao <[email-masked]>
Date: Fri, 19 Dec 2014 23:27:33 +0800

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.

http://mp.weixin.qq.com/s?__biz=MjM5NzM3Mjg2Mw==&mid=202089804&idx=1&sn=741bffe6eb1882be4fe7f548d602cf1a&scene=2&from=timeline&isappinstalled=0#rd

http://中文邮箱.网络/mail/register.jsp

From my phone

---

From: Franck Martin <[email-masked]>
Date: Tue, 23 Dec 2014 23:44:17 +0000

> http://中文邮箱.网络/mail/register.jsp

Tried it, still waiting for the confirmation… is it working?

---

From: Franck Martin <[email-masked]>
Date: Wed, 24 Dec 2014 07:34:09 +0000

> Tried it, still waiting for the confirmation… is it working?
Got it, thanks

Some feedback now...

Interesting, the left hand side of the @ was converted to puny-code when sending to my non SMTPUTF8 email server. I guess it is possible because of the limited character set allowed in the LHS?

I add to force Firefox to the right encoding to see  the email source in gmail correctly

There is no SPF or DKIM, please put an SPF at least, Gmail thinks this is all spam. I had to look in my junk folder, may be it thinks it is spam for other reasons, but nowadays you do at least SPF on mail servers. 
https://dmarcian.com/spf-survey/%E4%BA%92%E8%81%94%E7%BD%91.%E5%85%AC%E5%8F%B8
Authentication-Results: mx.google.com;
       spf=none (google.com: [email-masked] does not designate permitted sender hosts) smtp.mail=[email-masked]
Gmail calls it UTF8SMTP instead of SMTPUTF8

isn’t the 7bit encoding weird with UTF8?
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
sending IP has a rDNS, which does not match the ehlo hostname and the ehlo hostname does not have a SPF record…

Please don’t send the password in the confirmation email!

---

From: "Jiankang Yao" <[email-masked]>
Date: Wed, 24 Dec 2014 16:22:32 +0800

发件人： Franck Martin
发送时间： 2014-12-24 15:34
收件人： Jiankang Yao
抄送： [email-masked]
主题： Re: [EAI] Chinese email address

> Interesting, the left hand side of the @ was converted to puny-code when sending to my non SMTPUTF8 email 
 > server. I guess it is possible because of the limited character set allowed in the LHS?
> 

coremail chooses  punycode as a kind of dowingrading mechanism when encountering non-smtputf8 server.

---

From: John C Klensin <[email-masked]>
Date: Wed, 24 Dec 2014 16:02:50 -0500

--On Wednesday, December 24, 2014 16:22 +0800 Jiankang Yao
<[email-masked]> wrote:

>> Interesting, the left hand side of the @ was converted to
>> puny-code when sending to my non SMTPUTF8 email 

> when encountering non-smtputf8 server.

That is, of course, either a bug or a serious violation of the
standard.

   john

---

From: Franck Martin <[email-masked]>
Date: Wed, 24 Dec 2014 21:17:49 +0000

> That is, of course, either a bug or a serious violation of the
Not yet. From previous posts, I assume they have limited the character set for their mailboxes, which may allow a puny code translation back and forth.

The question is what will happen when they try to email an address they can’t convert?

And back to the problem, how people will understand that these are 2 different email addresses...

---

From: "Jiankang Yao" <[email-masked]>
Date: Thu, 25 Dec 2014 09:23:14 +0800

From: Franck Martin
Date: 2014-12-25 05:17
To: John C Klensin
CC: yaojk; ima
Subject: Re: [EAI] Chinese email address

>Not yet. From previous posts, I assume they have limited the character set for their mailboxes, which may allow a puny code translation back and forth.

coremail chooses to transform their own systems' email address only when encounting non-EAI.

>The question is what will happen when they try to email an address they can’t convert?

Currently, coremail has 2 downgrade mechanisms.
1, transform it to punycode
2, use the alternate address. for example, [email-masked] and [email-masked] are name alias, which share the same storage. when encountering non-eai, the system can choose [email-masked] as an alternate address.

which mechanism is used is based on the server administrator's confirguration.
of course, the administrator can configure not downgrade too.

---

From: John C Klensin <[email-masked]>
Date: Wed, 24 Dec 2014 21:45:56 -0500

--On Thursday, December 25, 2014 09:23 +0800 Jiankang Yao
<[email-masked]> wrote:

>> Not yet. From previous posts, I assume they have limited the
>> character set for their mailboxes, which may allow a puny
>> code translation back and forth. 
> 
>> The question is what will happen when they try to email an
>> address they can't convert?
>> 
> 
> 2, use the alternate address. for example, [email-masked] and
> [email-masked] are name alias, which share the same
> storage. when encountering non-eai, the system can choose
> [email-masked] as an alternate address.
> 
> which mechanism is used is based on the server administrator's
> confirguration. of course, the administrator can configure not
> downgrade too.

I may have misunderstood the issue here, in which case I
apologize for the confusion.  If the _only_ addresses they are
transforming are their own local ones and they are doing it on
the submission server or _very_ close to it, then, as far as
SMTPUTF8 and (SMTP itself) are concerned, it is just an aliasing
issue [1].  

With one possible exception [2], character restrictions in
addresses are irrelevant to that and Punycode encoding nearly
so: any reversible encoding that can handle the original
characters to be encoded will do as well; the various
restrictions and transformations are part of IDNA, not the
Punycode algorithm.  One could equally well use Unicode code
point ("\uNNNN" or "\u'NNNN'"), hexadecimal ("0xNN" or "%NN"),
Base64, or anything else including completely arbitrary ASCII
aliases... as long as the addresses would be recognized in the
reverse direction, e.g., when the message is replied to.

Now, if any of the forward-pointing addresses had non-ASCII
local parts, the next-hop system didn't support SMTPUTF8, and
the originating system didn't have specific knowledge about
aliases for the address, conversion of the local parts of those
addresses (via Punycode or anything else) would be a protocol
violation.

    john

[1] Note that, as far as SMTP is concerned, matching upper and
lower case in a local part is just an aliasing issue too -- one
can process aliases in all sorts of ways -- as long as it is
done at the delivery server or on a submission server
canonicalizing a local address on the way out.  If some
intermediate server does, e.g., lowercasing of the local-part,
it is a protocol violation.  So would a submission server
altering the local part of a remote address in any way unless it
had external knowledge (and, presumably, sender authorization).

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 25 Dec 2014 12:10:24 +0000

I an not quite sure, but I think I have now heard of three different downgrade mechanisms, none of which work with each other.

At least "down"grade describes the direction very well.

Arnt