Subject: [EAI] Downgrade simplifications

From: Ernie Dainow <[email-masked]>
Date: Tue, 04 Aug 2009 11:25:38 -0400

I think there are a number of things we can change to make Downgrade 
simpler and have less impact on existing email systems yet still provide 
the key backward compatibility that many people feel is important to the 
success of EAI.

The current design of Downgrade is very comprehensive. A lot of clever 
things were done to provide Downgrade in every possible situation and to 
provide a complete audit trail through the use of new Downgraded headers 
that also provide the ability to reconstruct the original UTF8 address 
information (Downgraded display). We can greatly simplify Downgrade by 
limiting the design goals to support only essential cases and make clear 
that Downgrade is an interim feature, is not perfect and does not 
provide a complete audit trail.

1. As recommended in 4.2 of  draft-ietf-eai-email-clients and in various 
emails on the EAI list, we should consider downgrade of forward-pointing 
(recipient) addresses as a configuration error and not something that 
Downgrade needs to support. Then we can remove Alternate Addresses for 
recipients. I think this would also allow us to redesign Downgrade 
without the double angle bracket syntax which seems to be the source of 
a lot of compatibility and security concerns.

2. Implementation of Downgrade is currently an option for MUA, POP/IMAP. 
Consideration of these cases in draft-ietf-eai-email-clients (3.1.1, 
3.2) is that these are unusual configurations. The standard should be 
explicit and state that Downgrade is only done by MTAs.

3. While an audit trail and ability to display original UTF8 addresses 
from a Downgraded message is a nice feature, some people consider the 
case in which this is useful to be a configuration error (an EAI MUA, 
POP or IMAP behind a non-EAI MTA.). In any case, it is not an essential 
feature within the revised design goals outlined above. If it is 
dropped, then all the added "Downgraded-" headers can be dropped.

4. Alternate Addresses for the sender can be handled in the "Accounts" 
setting of the MUA. They can also be provided by the SMTP server, as in 
draft-yao-eai-deployment. Since there is no interface for the MUA to 
find out from the server if it needs to provide Alternate Addresses or 
not, this ambiguity may lead to unexpected behavior in terms of which 
Alternate Address gets used if it is provided by both. While the server 
solution offers a certain amount of transparency to the end user, the 
MUA solution is more general in that it supports a legacy ASCII Address 
that may be on a different email provider. The standard should resolve 
this ambiguity and specify that Alternate Address for the sender is 
provided by the MUA and not the server.

5. Capturing UTF8 addresses in empty groups when Downgrading should be 
dropped. This has numerous interoperability problems with existing mail 
clients (3.2.1 in draft-ietf-eai-email-clients).

To make a clean line between Downgrade and the rest of the EAI standard, 
so that we can move ahead with standards track of the latter while 
continuing to work on experimental track Downgrade, all normative 
requirements relating to Downgrade should be pulled out of the EAI 
documents and moved into the Downgrade document. So for example, the 
ALT-ADDRESS parameter should be moved from RFC 5336 to the Downgrade 
document and the addr-spec for double angle brackets moved out of RFC 
5335 into the Downgrade doc (or dropped if 1. above can be achieved).

   -Ernie Dainow

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 06 Aug 2009 13:13:11 +0200

Ernie Dainow wrote:
> simpler and have less impact on existing email systems yet still 
> provide the key backward compatibility that many people feel is 
> important to the success of EAI.
>
> things were done to provide Downgrade in every possible situation and 
> to provide a complete audit trail through the use of new Downgraded 
> headers that also provide the ability to reconstruct the original UTF8 
> address information (Downgraded display). We can greatly simplify 
> Downgrade by limiting the design goals to support only essential cases 
> and make clear that Downgrade is an interim feature, is not perfect 
> and does not provide a complete audit trail.
>
> 1. As recommended in 4.2 of  draft-ietf-eai-email-clients and in 
> various emails on the EAI list, we should consider downgrade of 
> forward-pointing (recipient) addresses as a configuration error and 
> not something that Downgrade needs to support. Then we can remove 
> Alternate Addresses for recipients. I think this would also allow us 
> to redesign Downgrade without the double angle bracket syntax which 
> seems to be the source of a lot of compatibility and security concerns. 
As I said at the Stockholm meeting:

I'm fine with this, as long as we're able to satisfy the triangular 
scenario.

 From the long-expired scenarios draft:

> 2.5.  An i18mail user sends to one ascii user and one i18mail user
>
>    In this scenario, A sends to B and X; both reply.
>
>    Precondition: A and B have to have valid ASCII addresses.
>
>    Requirement: Through some series of steps, A must be able to get a
>    message to both B and X; through some series of steps, B and X must
>    be able to reply to each other and to A. X must not require
>    information outside of what is included in the message to get a
>    message to B.
>
>    Possible non-requirements (for discussion):
>
>    o  Maybe the messages to B and X don't need to be exactly the same.
>
>    o  Maybe B doesn't need to see or use A's i18n-address when he's
>       replying to A and X.
>
>    o  Maybe X doesn't need to see A's address exactly the same on the
>       message from A and the reply from B.
The way this is satisfied in the current spec is that in the headers of 
the message from A to X, B's address is in <unicode <ascii>> form, and 
will be turned into <ascii> at the downgrade gateway.

If we drop the <unicode <ascii>> form from the headers, how will X know 
what B's ASCII address is?

                             Harald

---

From: Ernie Dainow <[email-masked]>
Date: Sat, 08 Aug 2009 11:53:42 -0400

Harald Alvestrand wrote:

Ernie
Dainow wrote:

.... We can greatly simplify Downgrade by
limiting the design goals to support only essential cases and make
clear that Downgrade is an interim feature, is not perfect and does
not provide a complete audit trail.

1. As recommended in 4.2 of  draft-ietf-eai-email-clients and in
various emails on the EAI list, we should consider downgrade of
forward-pointing (recipient) addresses as a configuration error and not
something that Downgrade needs to support. Then we can remove Alternate
Addresses for recipients. I think this would also allow us to redesign
Downgrade without the double angle bracket syntax which seems to be the
source of a lot of compatibility and security concerns.

>From the long-expired scenarios draft:

2.5.  An i18mail user sends to one ascii user
and one i18mail user

message to B.

replying to A and X.

The way this is satisfied in the current spec is that in the headers of
the message from A to X, B's address is in <unicode
<ascii>> form, and will be turned into <ascii> at the
downgrade gateway.

If we drop the <unicode <ascii>> form from the headers, how
will X know what B's ASCII address is?

Simplifying downgrade comes at a cost. We need to identify what we lose
and compare it to the gains.

For the triangular case, we lose the email path X -> B, but we have

A <-> B

A <-> X

B -> X

So we lose 1/6 connections, 17%. This is less than the failures we have
seen from several Downgrade tests based on current spec (20%).

Actually, even with double angle brackets for recipients, the
triangular case will fail in many cases. In practice, we have concluded
that someone with a UTF8 address can generally receive EAI email,
otherwise they have a configuration error. So if A has B's UTF8 address
and assumes that B will be able to receive EAI email, A won't bother to
enter B's alternate address and X->B will fail. This is especially
true if A is in an environment where an ASCII keyboard is unfamiliar or
difficult to use.

-Ernie Dainow

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Sun, 09 Aug 2009 16:47:36 +0200

Ernie Dainow skrev:
>
> Harald Alvestrand wrote:
>> Ernie Dainow wrote:
>>> .... We can greatly simplify Downgrade by limiting the design goals 
>>> to support only essential cases and make clear that *Downgrade is an 
>>> interim feature, is not perfect and does not provide a complete 
>>> audit trail*.
>>>
>> The way this is satisfied in the current spec is that in the headers 
>> of the message from A to X, B's address is in <unicode <ascii>> form, 
>> and will be turned into <ascii> at the downgrade gateway.
>>
>> If we drop the <unicode <ascii>> form from the headers, how will X 
>> know what B's ASCII address is?
>>
> Simplifying downgrade comes at a cost. We need to identify what we 
> lose and compare it to the gains.
>
> So we lose 1/6 connections, 17%. This is less than the failures we 
> have seen from several Downgrade tests based on current spec (20%).
Any more insight into *why* those 2 out of 10 tests failed?
> triangular case will fail in many cases. In practice, we have 
> concluded that someone with a UTF8 address can generally receive EAI 
> email, otherwise they have a configuration error. So if A has B's UTF8 
> address and assumes that B will be able to receive EAI email, A won't 
> bother to enter B's alternate address and X->B will fail. This is 
> especially true if A is in an environment where an ASCII keyboard is 
> unfamiliar or difficult to use.
I'm not dead set against making this scenario impossible. I'm dead set 
against making this scenario impossible without an explicit decision to 
do so.

What do others think of this scenario?

       Harald

---

From: John C Klensin <[email-masked]>
Date: Sun, 09 Aug 2009 19:30:09 -0400

--On Sunday, August 09, 2009 4:47 PM +0200 Harald Tveit 
Alvestrand <[email-masked]> wrote:

> Ernie Dainow skrev:
>>
>> Harald Alvestrand wrote:
>>> Ernie Dainow wrote:
>>>> .... We can greatly simplify Downgrade by limiting the
>>>> design goals  to support only essential cases and make
>>>> clear that *Downgrade is an  interim feature, is not
>>>> perfect and does not provide a complete  audit trail*.
>>>>
>>>> 1. As recommended in 4.2 of  draft-ietf-eai-email-clients
>>>> and in  various emails on the EAI list, we should consider
>...
>> concluded that someone with a UTF8 address can generally
>> receive EAI  email, otherwise they have a configuration
>> error. So if A has B's UTF8  address and assumes that B will
>> be able to receive EAI email, A won't  bother to enter B's
>> alternate address and X->B will fail. This is  especially
>> true if A is in an environment where an ASCII keyboard is

> I'm not dead set against making this scenario impossible. I'm
> dead set against making this scenario impossible without an
> explicit decision to do so.
>

Harald,

While I'm trying to keep an open mind on this, I'm increasingly 
coming to the conclusion that the number of cases for which full 
downgrade capability is going to be helpful --i.e., it will work 
and there is no practical alternative-- is much smaller than we 
believed a year or so ago.  Ernie's reasoning, which I believe 
to be correct, further narrows that range of cases.

I also believe that full Downgrade capability as now specified 
carries real costs -- more expensive and complex EAI 
implementations and therefore probably slower and fewer ones, 
need to carry the artifacts of a transitional facility forever, 
consequences to legacy implementations that could result in lost 
mail (not just bounces).  And, of course, there are the marginal 
security risks and opportunities for (perhaps invitations to) 
bad behavior that Yao has pointed out, complications for 
header-signing procedures, etc.

When I weigh those costs against the benefits of Downgrading 
with forward-pointing alternate addresses, I think we should 
probably be considering other alternatives.   Certainly moving 
the scenario you identify from "unlikely" (at least for people 
using non-Latin-based scripts and keyboards) to "impossible" is 
one of those alternatives.

    john