Subject: Re: [EAI] Thinking about requirements / downgrade

From: "YAO Jiankang" <[email-masked]>
Date: Wed, 16 Sep 2009 12:16:04 +0800

> ----- Original Message ----- 
> From: Ernie Dainow 
> To: Harald Alvestrand 
> Cc: Mark Davis ⌛ ; Shawn Steele ; [email-masked] 
> Sent: Wednesday, September 16, 2009 6:22 AM
> Subject: Re: [EAI] Thinking about requirements / downgrade
> 
> 
> 
 
> I'm not sure it is necessary for a standard to guarantee this. I think it is just the responsibility of email administration to avoid name collisions. Currently, when a new email address is requested, the email administrator for the domain on which the name is requested (or email admin software) will not grant the email address if
> 1. the address (local name) is assigned to someone else on the domain.
> 2. the address is already in use as an alias on another email account on the domain.
> 
> Suppose EAI used automatic punycode email addresses, where punycode conversion is applied separately to each side of the @. Then email administrators on EAI systems just have the following additional verification to do on new email account requests:
> 3. generate the punycode of the new address (local name) and apply tests 1 and 2 above to make sure the punycode name is not in use on the domain.

pls see my last email to shawn.

> 
> Since only owners of a domain can create email addresses, name collisions cannot occur unless administrators fail to check for uniqueness before granting new email addresses. That requirement is no different from today.
> 
> Another concern about using ACE conversions in EAI was the issue of punycode addresses "leaking" into the user environment. Just to remind people how ugly this can be, here is a conversion of one of the EAI addresses used in one of the downgrade tests.
> <[email-masked]>
> 
> 
> 

> I think receiving a lot of email with long unrecognizable ACE conversions might be incentive for people to upgrade to EAI.

it also might be incentive for people to refuse the use of  EAI.

> 
> 
> Email administrators can avoid local name collisions as outlined above. This assumption is also important to EAI to avoid collusions on the domain name.
> 

you can avoid the name collisions when creating the account, but you can not prohibit the possible name collisions when using it. many MUA and servers may mis-use it since many many MUA or servers might use the automatic one if there is a automatic algorithm.

for more, you can see my last email to shawn.

Yao Jiankang

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

---

From: Shawn Steele <[email-masked]>
Date: Wed, 16 Sep 2009 05:13:43 +0000

> it also might be incentive for people to refuse the use of  EAI.

I doubt it matters either way.  Outlook shows this message as being from YAO Jiankang, I don't even see the addresses 'til I reply.

Again, I'm concerned that 2 "big" companies are considering adopting something like this.  I can't fault their logic, for them the edge case seems rare.  Certainly it's allowed by the standard (we're very lax in what the ASCII form may be.)  I would expect that if a major vendor adopted a punycode form, then their clients would also recognize it.

It would be much better to have a shared algorithmic method that we could all use (even if it was discouraged) rather than having different vendors create versions that are perhaps incompatible.  Can we create a draft (I can help if necessary) of a common mechanism or are there other objections besides the xn-- might conflict one?

- Shawn

---

From: Bill McQuillan <[email-masked]>
Date: Tue, 15 Sep 2009 23:19:31 -0700

On Tue, 2009-09-15, Shawn Steele wrote:

> It would be much better to have a shared algorithmic method that we
> could all use (even if it was discouraged) rather than having different
> vendors create versions that are perhaps incompatible.  Can we create a
> draft (I can help if necessary) of a common mechanism or are there other
> objections besides the xn-- might conflict one?

I'm trying to remember all the reasons that were given when I advocated the
algorithmic approach several years ago.

The first was "Thou shalt not modify the left hand side!" Maybe all of the
issues brought up recently have softened this. Maybe not.

The second was "Some people expect to modify the left hand side!" For
example, the convention that a mailing list manager may be contacted by
appending "-request", like: <[email-masked]>. Punycode would mess
this up by appending stuff after the modified portion.

I don't remember if I bothered previously to suggest the ACE prefix: %%

The double percent would be using a character that historically had been used
for manual routing. Thus <[email-masked]> would be
initially sent to example.org which would forward it to me at
<[email-masked]>. This usage is now long deprecated, but may indicate
that the percent sign was considered reserved in left hand sides. Also a
double percent, like <[email-masked]>, is perhaps very unlikely to
collide with any existing left hand side.

If the algorthmic method were guaranteed reversible, *any* ima-aware server
or client could downgrade or upgrade as it saw fit (e.g., to parse
embedded information in the left hand side) making sure only to downgrade
before passing it along to an ima-UNaware server.

-- 
Bill McQuillan <[email-masked]>

---

From: Ernie Dainow <[email-masked]>
Date: Wed, 16 Sep 2009 08:54:01 -0400

> it also might be incentive for people to refuse the use of  EAI.
EAI users should never see the ACE names. They will appear only in 
downgraded messages and delivered to users who are not using EAI, 
since    EAI -> downgrade -> delivery to EAI client   
is typically a configuration error. In any case, up-conversion on the 
receiving side (POP, IMAP, MUA) can apply the reverse translation and 
restore UTF8 addresses from the ACE encodings.

As more and more people use EAI, non-EAI users will receive more and 
more downgraded messages with puunycode addresses. This will build 
momentum for conversion to the new standard.

> you can avoid the name collisions when creating the account, but you can not prohibit the possible name collisions when using it. many MUA and servers may mis-use it since many many MUA or servers…
The design of punycode ensures that there are no collisions, where more 
than one UTF8 name maps to the same punycode. As long as all email 
systems use the same standard ACE that has this property, there will be 
no collisions when using it.

    -Ernie