Re: [EAI] Thinking about requirements / downgrade

[Shawn Steele <Shawn.Steele at microsoft.com>]

> 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.
 
As a business, we'd like to provide EAI solutions.  It'd be cool & solve a real customer need.  However people and businesses don't upgrade Exchange and Outlook every day.  Also we have Live mail and web based front ends to consider.

Presumably at least some of our customers want international addresses.  We're pretty much certain that they'll want reliable email service as well.  If an Exchange site is going to upgrade to EAI, they're going to want to make sure that it plays well with other Exchange sites, with Outlook clients, etc.  In some cases an entire enterprise is using Microsoft products; Outlook clients talking to Exchange servers, etc.

If our customers want to upgrade their Tokyo office to support EAI but can't afford to update their US servers right now, what would a Microsoft solution look like?
 
The other downgrade techniques that have been proposed fail in far too many cases for us to have satisfied customers.  It doesn't matter if 90% of their mail succeeds, if 1% fails without any warning.  Even staying on the same vendor's products won't help because of the other downgrade techniques have fundamental flaws.

In that case, a workaround could be to use an algorithmic encoding.  Then customers using Outlook or Live Mail could talk to these improved EAI Exchange servers and interoperate, regardless of the infrastructure in-between.  So this would provide a fairly robust end-to-end solution for customers that used our products.  It would probably also help our customers is a few cases even when some of the infrastructure was on other platforms.

In an EAI-supporting Exchange/Outlook environment it'd be really nice if non-Microsoft products interoperated as well, but even if mail to a different platform failed, at least the boundary would be pretty clear.  Customers could still have solutions that worked within their enterprise, even if external mail ran into the no-downgrade or partial-downgrade experience when talking to non-Microsoft products.

As I mentioned, we're not the only ones thinking along these lines, replace our products with our competitors' above.  If we can provide a more robust solution with our products, then we're inclined to consider it.  Our competitors are.  I'd prefer a solution that interoperates as much as possible though.

When considering a solution that works within our product line, the problem is simpler.  We don't have to worry about strange xn-- codes running scripts because our stuff doesn't do that.  Neither do most of our competitors' products.  I can readily see where an old Unix? box that ran scripts from email addresses wouldn't want to use this mechanism, but they don't have to.  I'm suggesting it as an optional worst-case fallback.

There's nothing in the current EAI RFCs that prohibits algorithmic generation of an ASCII address, address generation is left to the server.  I imagine that fallback would look something like:

1) Use EAI
2) If I can't use EAI, try to use human-readable ASCII (assuming I know enough)
3) If I can't do that, use the worst-case, last-resort Punycode mechanism.  Like for fields that downgrade doesn't address fully.

I get that algorithmic downgrade might not work for all environments, but I think that when vendors look at their offerings they'll try to provide a complete end-to-end solution.  In most cases the algorithmic technique will work.  In other cases it shouldn't be used.

I've heard feedback that xn-- or any other prefix is going to trip up some esoteric part of the system (you don't really need to query every mail server to realize that z.-_., or even xn--, is rarely encountered in email).  I'm not suggesting that this is a perfect solution for every environment, only that it will work in many environments.

Unless downgrade can be solved perfectly some other way, I believe that some software vendors will implement such a last-resort algorithmic solution.

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.

-Shawn