Re: [EAI] The value of simplified downgrade

[Ernie Dainow <[e-mail]>]

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 Addesses 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