Re: [EAI] The value of simplified downgrade

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

I know full doesn't work in the current rfcs :) 

And yes I don't buy into the utility of the current partial idea.

A problem with a VRFY type solution is that it's a spammers dream, since it would tell them good mailboxes.

I'm also concerned that an ask-the-server type solution would be more fragile.  Numerous things could make it hard to ask the server, yet transmit legacy mail.  For example, would you expect EAI aware mail clients to contact the server directly if they don't have an EAI aware server?  Port 25 is often blocked, forcing use of a local server.

I HATE ACE.  It certainly shouldn't be a human friendly alias.  However it is reasonably simple, robust, and I can't think of any technical problem with that solution, only aesthetic.

Sent from my HTC FUZE™, a Windows Mobile® smartphone from AT&T

-----Original Message-----
From: Ernie Dainow <edainow at ca.afilias.info>
Sent: Thursday, September 10, 2009 7:00 AM
To: Shawn Steele <Shawn.Steele at microsoft.com>
Cc: ima at ietf.org <ima at ietf.org>
Subject: Re: [EAI] The value of simplified downgrade



Shawn Steele wrote:
>> By comparison, in 3a, EAI recipients will see all the people that 
>> received the email and Reply All will reach everyone. However, non-EAI 
>> recipients will not see any of the EAI recipients, and their Reply All 
>> will only reach the non-EAI recipients and the sender.
>>     
>
> This summarizes my concerns with "partial" downgrade solutions.  Things that appear to work stop working in edge cases, and it may be difficult for the sender to predict or understand the behavior.  If it fails completely I know I need to get fixed addresses or get an updated mail client or whine at my network admin or something.  If it fails "randomly" (many users won't recognize the pattern) then they have no recourse (but to whine at the network admin, which won't help but will cost the support people a lot of money.)
>
> In short: If it always works for me, great.  If it's always broken, then I'll do something to fix it, but if it works sometimes but not others I just get confused and it gets expensive to support.
>   
So you basically do not accept the stated design goal for a simplified 
downgrade which was for a simplified but imperfect solution.

Note that the 'full' downgrade specified in RFC 5504 does not meet this 
criterion either. Although RFC 5504, unlike the simplified downgrade, is 
able to handle the 'triangle' case, it will not be reliable and may work 
sometimes and not others. This is because Alternate Addresses are 
optional and not required. If the user does not provide an alternate 
address for every recipient EAI address, someone will be left out on a 
Reply All to a downgraded message.

I don't think anyone would consider making Alternate Addresses required 
to solve this. So other approaches are necessary. On another thread 
(Thinking about requirements / downgrade), you have proposed to 
auto-generate alternate addresses to handle cases like this. That may 
provide a solution.

Other approaches are possible. I think a cleaner one than an ACE based 
scheme is as follows.

Have alternate addresses stored on the server, associated with the 
primary EAI address for the account (this has been recommended in 
draft-yao-eai-deployment, section 3). Then add a new SMTP command, 
something like VRFY, that verifies an email address and returns the 
associated alternate address. So when an MTA discovers it needs to 
downgrade, it can use this SMTP command to get the alternate addresses 
needed from an authoritative source.

    -Ernie