Re: [EAI] Downgrade simplifications

["YAO Jiankang" <[e-mail]>]

----- Original Message ----- 
From: "Ernie Dainow" <[e-mail]>
To: <[e-mail]>
Sent: Tuesday, August 04, 2009 11:25 PM
Subject: [EAI] Downgrade simplifications


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


this is a good idea. I also wonder whether we need the downgrading for recipient.

in practise, only "downgrade from address" may be useful.


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

this issue need more discussions.


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

I remeber that the WG decided to have no upgrading after downgrading.

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

+1

the possible phising will be reduced if the alternate address is only provided by smtp server.
if the alternate address is provided by MUA, the user can put any address they want such as [e-mail] or [e-mail] . 

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

when you register an email account, you can apply both the ascii email account and non-ascii email account from the same company or organization.

>The standard should resolve 
> this ambiguity and specify that Alternate Address for the sender is 
> provided by the MUA and not the server.

if we decide to have no downgrade issue in RFC5336 5335, then you are right. otherwise, we may consider that only by server, not by MUA.


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

+1.

I personally agree this suggestion.

Yao Jiankang
CNNIC

> 
>   -Ernie Dainow
> 
> 
> _______________________________________________
> IMA mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ima