Subject: [EAI] double angle brackets

From: Ernie Dainow <[email-masked]>
Date: Fri, 04 Sep 2009 17:46:26 -0400

One of the key goals in simplifying Downgrade is to drop the double 
angle bracket notation, due to compatibility and security concerns. 
There have been a few email threads on this. I think the following 
summarizes the current thinking.

Dropping double angle brackets on Recipient addresses is part of the 
downgrade simplification to not support downgrade of forward pointing 
addresses (considering these cases as configuration errors).

To replace double angle brackets for the Sender, John Klensin proposed 
using multiple From fields. SM amended this with Reply-To to specify the 
preferred address, as in
        From: EAI-addr, ASCII-addr
        Reply-To: EAI-addr
where the EAI-addr gets dropped in Downgrade.

I did some (non-EAI) tests of multiple From fields with Reply-To on two 
different email systems and both worked as expected. This looks like an 
elegant solution.

SM raised some possible problems with multiple From addresses on mailing 
lists. The suggestion was to address these issues in the mailinglist 
document.

There still needs to be a mechanism to carry the alternate address of 
the sender in the envelope through SMTP relays up until the point that a 
non-EAI transport is encountered. No change is being proposed to the EAI 
SMTP extension for the ALT-ADDRESS parameter on MAIL FROM. If a non-EAI 
server is encountered, Downgrade is done on the message and the EAI 
address in the Envelope is replaced with the ALT-ADDRESS. However, we 
would drop the ALT-ADDRESS parameter on RCPT TO.

    -Ernie Dainow

---

From: "Charles Lindsey" <[email-masked]>
Date: Sun, 06 Sep 2009 12:58:24 +0100

> different email systems and both worked as expected. This looks like an  

Yes, but the interesting case is multiple fields in Reply-To. Normally,  
these will cause the reply to go to _both_ (but if one is utf-8 and one is  
ascii, then the utf-8 might fail).

If we retain the double angle brackets, then one could still say, in the  
Reply-To, "please reply to my utf-8 address if possible, but if your  
system (or some intermediate server that knows how to downgrade) can't do  
that, then please reply to my ascii address".

I would expect that to be the commonest (and most useful) situation in  
which those double angle brackets will appear in practice.

So my preference would be to retain them, at least so long as these remain  
Experimental documents. If the eventual Standard still retains them, then  
it could still say "this feature may well be withdrawn in a future version  
of this standard" (with the intent to do so when utf-8 has become so  
widely implemented that it is no longer needed).

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

---

From: John C Klensin <[email-masked]>
Date: Sun, 06 Sep 2009 23:16:07 -0400

--On Sunday, September 06, 2009 12:58 PM +0100 Charles Lindsey 
<[email-masked]> wrote:

> On Fri, 04 Sep 2009 22:46:26 +0100, Ernie Dainow
> <[email-masked]> wrote:
>
>> One of the key goals in simplifying Downgrade is to drop the
>> double   angle bracket notation, due to compatibility and
>> security concerns.   There have been a few email threads on
>> this. I think the following   summarizes the current thinking.
>>
>> Dropping double angle brackets on Recipient addresses is part
>> of the   downgrade simplification to not support downgrade of
>> forward pointing   addresses (considering these cases as
>> configuration errors).
>>
>> To replace double angle brackets for the Sender, John Klensin
>> proposed   using multiple From fields. SM amended this with
>> Reply-To to specify the   preferred address, as in
>> I did some (non-EAI) tests of multiple From fields with
>> Reply-To on two   different email systems and both worked as
>> expected. This looks like an   elegant solution.
>
> Yes, but the interesting case is multiple fields in Reply-To.
> Normally, these will cause the reply to go to _both_ (but if
> one is utf-8 and one is ascii, then the utf-8 might fail).
>
> If we retain the double angle brackets, then one could still
> say, in the Reply-To, "please reply to my utf-8 address if
> possible, but if your system (or some intermediate server that
> knows how to downgrade) can't do that, then please reply to my
> ascii address".

And this is different from adding "if this address doesn't work, 
try that other one" to the email model -- something we have 
never had, nor missed very much?

The cost and risks of adding new syntax to addresses is quite 
high, especially given the risk of leakage and of causing 
serious interoperability problems if things do leak.   It may be 
worth it (I'm still trying to keep an open mind although I'm 
increasingly doubtful that it is), but, if so, we should have a 
much stronger justification than a marginal reply-to case, at 
least IMO.

> I would expect that to be the commonest (and most useful)
> situation in which those double angle brackets will appear in
> practice.
>
> So my preference would be to retain them, at least so long as
> these remain Experimental documents. If the eventual Standard
> still retains them, then it could still say "this feature may
> well be withdrawn in a future version of this standard" (with
> the intent to do so when utf-8 has become so widely
> implemented that it is no longer needed).

Our experience has been that, if one does that, it will only 
affect new implementations created after the feature is 
withdrawn and maybe, for competitive reasons, not even them. 
For everyone else, if a feature like that is ever supported as 
part of a standard, it is forever.

    john\

---

From: SM <[email-masked]>
Date: Mon, 07 Sep 2009 01:18:55 -0700

>summarizes the current thinking.

Yes.

>which those double angle brackets will appear in practice.

Ernie summarizes what may be considered in my opinion as easier, i.e. 
lower amount of changes to existing syntax.

>widely implemented that it is no longer needed).

If the decision is taken to retain them in an existing Proposed 
Standard, it will be more difficult to withdraw that feature even 
though there is a statement about it.

Regards,
-sm