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

From: Shawn Steele <[email-masked]>
Date: Thu, 10 Sep 2009 16:44:55 +0000

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 <[email-masked]>
Sent: Thursday, September 10, 2009 7:00 AM
To: Shawn Steele <[email-masked]>
Cc: [email-masked] <[email-masked]>
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

---

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

Hi Shawn,
>since it would tell them good mailboxes.

VRFY could help in getting the EAI-addr.  As that feature has been 
turned off in the default configuration since a long time, I'm not 
sure whether you can sell it as a solution.  By the way, I can tell 
what are the good mailboxes even if VRFY is disabled.

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

The EAI mail client (not to be confused with the SMTP client) should 
be using the submission port.  You cannot "ask the server" as you'll 
run into port 25 blocking and other techniques which prohibits that.

Regards,
-sm