Subject: Re: [EAI] The value of simplified downgrade

From: Shawn Steele <[email-masked]>
Date: Wed, 9 Sep 2009 20:27:34 +0000

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

- Shawn

 
http://blogs.msdn.com/shawnste

---

From: Ernie Dainow <[email-masked]>
Date: Thu, 10 Sep 2009 09:57:32 -0400

> 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

---

From: SM <[email-masked]>
Date: Thu, 10 Sep 2009 16:28:16 -0700

Hi Ernie,
At 06:57 10-09-2009, Ernie Dainow wrote:
>downgrade, it can use this SMTP command to get the alternate 
>addresses needed from an authoritative source.

What Section 3 of draft-yao-eai-deployment-03 recommends is to 
generate an alternative address and have it stored on the (sender) 
server-side.  The user does not have to bother about that alternative 
address as the server puts it in.

Are you suggesting using VRFY to get the alternative address from 
another SMTP server?

Regards,
-sm

---

From: Ernie Dainow <[email-masked]>
Date: Fri, 11 Sep 2009 18:53:34 -0400

> Are you suggesting using VRFY to get the alternative address from 
Yes, if an EAI server has an alternate address associated with an EAI 
address, it can provide it in response to a new SMTP command from 
another EAI server. Apparently some similar ideas of doing this type of 
lookup, for example via LDAP, were explored early on and rejected. Doing 
this securely becomes complicated very quickly.