Subject: [EAI] i18n of localpart versus i18n of email RFC standards

From: Soobok Lee <[email-masked]>
Date: Fri, 1 Dec 2006 01:49:24 +0900

Hi, All

After looking into EAI drafts, I find this WG had been focusing on
 18n(utf8-ization) of all Email related RFC standards, 
 rather than  defining ACE-encoding standard for non-ascii localpart.
 I can guess and accept the reason behind the former approach, but
 i still believe the latter approach has some merits and even co-exist
 with the cureent EAI framework.

1. 
The framework document does not exclude the use of 
proprietary (home-made) localpart ACE encoding per host basis, but
this WG has no nameprep-like stringprep profile draft for localpart 
ACE encoding yet. Do It Yourself policy ? :-) 

If we need and call it "localprep", it'll be almost the exact
copy of nameprep RFC with  addition of expanded delimiters set and 
email-specific security considerations and suggestion of x?-- prefix.
This encoding clearly has some limitations and may not be "MUST USE" 
for every host, but will help fast adoption of EAI for some parties, 
especially for major email portals who can accept the limitations.
the nameprep with more delimiters(,=/_ etc) would be enough for
most asian and european email users.

So, I suggest we have a draft for a stringprep profile for localpart 
encoding in this WG.

2.
current framework document has cautions about use of unauthenticated 
binding between Non-ASCII and alt-address,  so more draft work  is
required to fight against alt-address spoofing attacks.
Old JET members had a brief talk about this alt-address spoofing issue
recently and i hope we could post a summary and suggestion here.

Best Regards,

Soobok Lee

_______________________________________________
IMA mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ima

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 30 Nov 2006 23:08:34 +0100

>  with the cureent EAI framework.
It is, however, not the approach this WG is chartered to follow, and 
discussion is therefore out of scope for this WG.

I am sorry to be so blunt about it, but this group has work to do in 
finishing its approach, and spending resources exploring further a path 
that has been abandoned before the WG was chartered is not an efficient 
use of this WG's time.

You are free to submit whatever drafts you want on your own, but they 
are not within the scope of this WG.

            Harald, speaking as chair.

---

From: Yangwoo Ko <[email-masked]>
Date: Fri, 01 Dec 2006 10:16:47 +0900

>  with the cureent EAI framework.

Please be careful about the current charter of EAI WG.
It is clearly focused on "an" approach that is described
in framework document. If you want to pursue other approach,
you may need another WG.

> So, I suggest we have a draft for a stringprep profile for localpart 

Section 7 of framework document mentions a little bit about
local(?)-prep. I am very glad if you come up with a draft for
this.

However, I am confused because you mentioned some-prep the
local-prep "only" in the context of ACE. I think that the
usefulness of local-prep is not necessarily coupled with the
use of a specific encoding.

---

From: Soobok Lee <[email-masked]>
Date: Fri, 1 Dec 2006 10:22:57 +0900

> discussion is therefore out of scope for this WG.

I understand your concern as the chair.

But, when alt-address parameter is not given by MUA or not available at all,
downgrading MUA/MTA may favor some default ACE-encoding for localparts,
over just bouncing back or rejecting. 
and if we agree that such default auto-converint ACE encoding is useful,
this will support that ACE-encoding job falls within this WG scope.

Moreover, current un-authenticated alt-address binding may cause some spoofing
problem which has different nature than that of ascii-only email address,
so default ace-encoding has some merits from security viewpoints.
This is the second reason why i believe default ace encoding falls 
within this WG.

Of course, such ACE-encoding may be used not only for downgrading
but also for the early composing stage in MUA, but, this latter
un-intended use of ACE encoding is out of scope of this WG.

Soobok

---

From: Soobok Lee <[email-masked]>
Date: Fri, 1 Dec 2006 10:31:20 +0900

> in framework document. If you want to pursue other approach,

I understand, but the problem is on "time". :-)

> local(?)-prep. I am very glad if you come up with a draft for

I will try to look into this prep thing . thanks.

> use of a specific encoding.

I agree. 

Soobok

---

From: "Yao Jiankang" <[email-masked]>
Date: Fri, 1 Dec 2006 09:48:03 +0800

----- Original Message ----- 
From: "Soobok Lee" <[email-masked]>
To: "Harald Alvestrand" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, December 01, 2006 9:22 AM
Subject: Re: [EAI] i18n of localpart versus i18n of email RFC standards

> over just bouncing back or rejecting.

on such occasions,  bouncing back  is a good choice.
ACE-encoding on the local parts will cause a lot of potential problems, which has been discussed a lot on this mailing list and many drafts.
ACE-encoding is ugly to users. if some MUA/MTA is sure that some UTF-8 address can be safely transformed into ACE-address without losing any information,
these MUA/MTA may select their own version of ACE-address.

> this will support that ACE-encoding job falls within this WG scope.

as discussed above, default auto-converint ACE encoding has some problems.

> This is the second reason why i believe default ace encoding falls 

for future alt-address binding, we may have a operation guideline to prescribe how to bind. but it is not our current document plan.
it is also not core protocol issue.

> un-intended use of ACE encoding is out of scope of this WG.

as you have understand it, EAI WG is working out a solution based on SMTP extension not ACE.

Yao Jiankang
CNNIC

---

From: Soobok Lee <[email-masked]>
Date: Fri, 1 Dec 2006 11:35:18 +0900

> these MUA/MTA may select their own version of ACE-address.

As your [smtpext] section 2.5 stated, 
<quote>
   Some may prefer transformed the non-ASCII address to the ASCII
   Compatible Encoding(ACE) address as the value of the ALT-ADDRESS.
   The big problem with applying an ACE to all local-parts is that the
   sending or converting system doesn't know if there are some specific
   data or instructions embedded in the address that the ACE process
   would hide.  Some SMTP servers may depend on these specific data or
   instructions to do some operations while the local parts applied with
   ACE will lose or hide these data or instructions. 
</quote>

How about having some guideline to *ban* on embedding any data/instruction
into the NON-ASCII localpart, since  NON-ASCII lables are most for humans
not for machines. They will use ASCII localpart for that purpose. No harm
at all.

moreover, ACE encoding for downgrading may be geared to have minimum
loss of information. For interoperability, some default ace encoding
is good for MUA/MTA.

even if ACE-encoding has some "costs", bouncing back has some costs either.
this is the summary of argument against ace autoconverting i found.

1) ACE encoded localpart looks ugly and causes confusion.
   EAI-capable would convert them back to NON-ASCII. In most cases, ugly form
    would not be seen from end users.

2) some MTA have length limits on local parts,
   utf8/ace encoding produce different lengths of localparts for
   one mailbox name. In extreme cases, site-specific length limit would
   be broken, in which case the site admin reject to register that 
   ace lable perl case by case basis or by reject-all. 

3) lose some characters when auto-converting
   Can be avoided as addresssed in the above.

Soobok

---

From: "Yao Jiankang" <[email-masked]>
Date: Fri, 1 Dec 2006 11:17:36 +0800

----- Original Message ----- 
From: "Soobok Lee" <[email-masked]>
To: "Yao Jiankang" <[email-masked]>
Cc: <[email-masked]>; "Harald Alvestrand" <[email-masked]>
Sent: Friday, December 01, 2006 10:35 AM
Subject: Re: [EAI] i18n of localpart versus i18n of email RFC standards

> not for machines. They will use ASCII localpart for that purpose. No harm

yes, I also considered this issue about *ban* on embedding any data/instruction
 into the NON-ASCII localpart before.
on another thought, *ban" will also cause some problems and has some inconvenience.
for example, I can use sub-address such as [email-masked] before  EAI protocol is published.
but I can not use sub-address such as [Chinese Character yao]+ietf@IDN after  EAI protocol is published.

so after EAI protocols are published, it is not our design aim that  some email address form will be dis-allowed. 

> loss of information. For interoperability, some default ace encoding

Yes, as you have already said, the EAI WG has not exclude some MUA/MTA which may use its own version of  ACE encoding.

> this is the summary of argument against ace autoconverting i found.
yes, both has some costs. so we select the safe one.

>    would not be seen from end users.

I am sure that some MUA or MTA will never be upgraded if ACE is used.
these users of eai-incapability MUA/MTA will always see the email address such as [email-masked] and  [email-masked] .

these 2 address are same?

actually, it is not same. it cause confusion.

>   ace lable perl case by case basis or by reject-all. 

as you said it, some MTA have length limits on local parts, but some MTA have not strict length limits on local parts.
for example, MTA A prefer the length 32 characters, but MTA B prefer the length 64 characters.

how communictions between A and B when the email address including 64 characters from B is sent to A?

So we do some fragment?

>   Can be avoided as addresssed in the above.

may lose some information, pls see above.

---

From: Soobok Lee <[email-masked]>
Date: Fri, 1 Dec 2006 13:29:34 +0900

> so after EAI protocols are published, it is not our design aim that  some email address form will be dis-allowed. 

in your example, "+" can be added as a legal delimiter for localparts. /=_! can be added as legal delimiters likewise.
For my example, "[SOOBOK in UTF8].[LEE in UTF8][email-masked] can be autoconverted into
"[email-masked]. No loss of information. dot and + and underbar was not lost.
The receiving SMTP server parses it back to NONASCII in order to find data/instruction
for whitelisting filtering. Even the receiving server can work directly
on [email-masked]   without NON-ASCII version if it is already registered
as an ascii *alias* for NON_ASCII in the server alias database.  
Still I can find no problem at all.

> Yes, as you have already said, the EAI WG has not exclude some MUA/MTA which may use its own version of  ACE encoding.

Yes. it's better we have one default ace encoding rather than having nothing , 
even though it can not be perfect and has some costs.

> yes, both has some costs. so we select the safe one.

I believe ace encoding can be made safer  by eliminating some problems about
converting problem.

> I am sure that some MUA or MTA will never be upgraded if ACE is used.

MUA will be upgraded easily since their market is occupied
by a few big venders (MS,Mozilla,Opera,Eudora etc).
To pursuade them to adopt EAI protocols early, protocols should be made simple 
and efficient as possible,
and provide some easy transition path to final full-blown utf8 protocol sets. 
ACE for downgrading will do the job in the road, i believe.
Without ace encoding, industry-wide EAI adoption  will be very slow.

> these users of eai-incapability MUA/MTA will always see the email address such as [email-masked] and  [email-masked] .

Yes. many end users give up chechking the diffference. and this is the valid security problem.
but, IDNA and even the ASCII mboxname/domain name has the same problem, like  [email-masked] vs [email-masked].
IDN labels/NON-ASCII localpart can contain the exact-same-looking characters.
Slash-like chars are on unicode special char section/CJK section/Japanese section etc.

> for example, MTA A prefer the length 32 characters, but MTA B prefer the length 64 characters.

Most CJK names falls between 2~5 unicode chars. The length of xn--ewqeqwewqqw will be 4+10~12.
so, in most cases ace encoded localpart won't exceed 30 chars.
에베레스트.com (5 unicode char mt. Everest in korean).com ==> XN--OM2B17FB6FZRDD5V.COM (19 chars).com
For ace label to exceed 30 chars, 8 unicode chars is needed , i guess.

> how communictions between A and B when the email address including 64 characters from B is sent to A?

Just bounce at this time. It will be rare. the cost is minimum.

> may lose some information, pls see above.

+ may can be a legal delimiter for localpart as it had been so far in
ascii world.

Soobok Lee