Re: [EAI] Thinking about requirements / downgrade

[Bill McQuillan <McQuilWP at pobox.com>]

On Wed, 2009-09-16, Shawn Steele wrote:
>> Local names are not decoded until they arrive at the destination domain.
>> At that point, if a mailbox exists for the local name, it is delivered. 
>> On EAI systems, if that mailbox does not exist, then the name is decoded
>> and a second delivery is attempted to the UTF8 mailbox. If the checks 
>> outlined earlier are followed when creating new mailboxes, delivery will
>> never go to different users for these two cases.

> That's where there's confusion.  There is another scenario where an
> EAI aware system mails to a non-aware system, however the client on that
> side is EAI aware.  In that case, it is possible that the client would
> want to upgrade the message for display.


  

> I'm going to describe the thinking of a vendor trying to create an
> end-to-end solution.  Since beating around the bush didn't work, I will
> name Microsoft products explicitly, (That doesn't mean we're doing this,
> although it's pretty obvious we're thinking about it.)  Please replace
> the Microsoft products with your favorite vendor(s) because other vendors
> have the same problems and have thought about this as well.


<snip>


> 1) Are there any places where algorithmic ASCII addresses that will
> fail worse than the non-delivery case or partial-support case?  I can't
> think of any:
> * If I support Punycode mailboxes, then I can assign them in a way that aliasing isn't a problem.
> * If you don't support Punycode mailboxes, but my mailer tries to send mail that way, then either:
> 	a) You don't get the mail because there's no such mailbox,
> 	b) The mail goes somewhere else, like to a different mailbox.  This
> is similar to a misdirected fax or a typo in an email address today.  I
> can't trust scooby8787 at live.com because I might have got it wrong and it
> was really scooby7878 at live.com.  If I've never mailed there before
> there's no guarantee it'll behave.  If I trust the address as working,
> then I know it works.
> 	c) Apparently it could also run a job somewhere or do something else
> interesting.  In that case it doesn't really matter how I sent mail to
> that address since I could've done it directly anyway.  I'm not sure how
> this makes the punycode technique any riskier, that system already has a
> pretty serious security problem.

> 2) I realize it's not the right solution for everyone, but is there an
> objection to me creating an OPTIONAL last-resort draft for applications
> that think they need it?  Then even if those applications are being
> stupid, at least they'll all be stupid in a predictable and consistent
> manner.

It seems to me that the potential damage only occurs when an algorthmically
downgraded address is received by an MX in which the algorithmically
modified local part might be interpreted in some fashion other than as a
downgraded address. This is only for addresses local to that domain, since
all others would be treated as opaque by an eai-UNaware server.

I think that this implies that, if a common, algorithmically determined
aliasing system is allowed, then when a domain decides to implement ima, it
must examine such conventions within itself and make sure that it does not
use any that would conflict with the algorithm.

This seems to narrow the area of conflict somewhat.

-- 
Bill McQuillan <McQuilWP at pobox.com>