Subject: Re: [EAI] Downgrade simplifications

From: "YAO Jiankang" <[email-masked]>
Date: Fri, 7 Aug 2009 17:07:22 +0800

> ----- Original Message ----- 
> From: "John C Klensin" <[email-masked]>
> To: "YAO Jiankang" <[email-masked]>; "Ernie Dainow" <[email-masked]>; <[email-masked]>
> Sent: Friday, August 07, 2009 2:00 AM
> Subject: Re: [EAI] Downgrade simplifications
> 
> 
> 
> 
> --On Thursday, August 06, 2009 10:34 +0800 YAO Jiankang
> <[email-masked]> wrote:
> 
>>... 
>> 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 [email-masked] or [email-masked]. 
> 
> Do you mean the submission server?
  
yes, I mean the submission server.

>If it is provided by a
> random SMTP (relay) server, I think we are in for deeper
> problems as well as a need to relax current requirements of 5321
> about not changing messages in transit.
> 

yes.

> But, even if it is the submission server, it seems to me that
> what you accomplish by moving responsibility there (rather than
> in the MUA) is to:
> 
> -- Make it harder for users of many systems to provide alternate
> addresses, since few Submission Servers support the relevant
> databases for supplying alternate addresses today.  At minimum,
> we would have to advise that RFC 4408 servers be updated to
> maintain databases of, and insert, that information.

it seems that there is no definition about MUA from RFC. 

from wiki,  I get this definition "
An e-mail client (also mail user agent (MUA) or e-mail reader) is a frontend computer program used to manage e-mail.

"

normally, the server will keep all the email accounts information.
the MUA only keeps the personal email account information.

so it is better if I ask that the alt-address should be kept in client or server?

My answer is server. this server may be a server which runs as a mailstore.

> 
> -- Prevent casual users and vandals from supplying alternate
> addresses that have nothing to do with the primary (EAI) ones
> but not provide a barrier higher than minor inconvenience to any
> serious attacker.  Such an attacker could, in principle, use a
> compromised MSA.  Of course, EAI downgrading increases an
> existing problem only slightly -- nothing prevents my sending
> out a message "From" [email-masked] or [email-masked]
> today.. 

yes, nothing can prevents your sending out a message "From" [email-masked] or [email-masked] 
because you are email experts and know how smtp 
runs. but most normal email users who do not know the mechanism of the smtp has little chance to try  sending out a message "From" [email-masked] or [email-masked].

if alt-address is used in every email client, it means that every one can send out a message "From" [email-masked] or [email-masked] even he is a 
email beginner.
if we can allow the random input of alt-address at the email client, there will have more phising problems in the future than now.

everyone whether he is advanced email user or email biginner can do some phising if he wants to do so.

so I prefer that there should a mechanism to control the alt-address.

>EAI alternate addresses might serve to hide the fact
> that I had done that, but only with an MUA that tended to hide
> those addresses (and not others).
> 
>>> 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.
> 
> We have had that conversation before.  You are assuming a
> particular model of how MUAs, Submission Servers, and mail
> providers generally interact.  It may be the best such model,
> but it isn't the only one and there is nothing, anywhere, that
> standardizes it or makes it a requirement for EAI implementation
> or deployment.  

the mechanisme designed in the draft-yao-ea-deployment will help the deployment  of eai.
I mean that draft-yao-ea-deployment can pursue to be an informational or experimental RFC instead of standardizing it or making it a requirement.
if we follow the model, I think that at least we can reduce the phising.

Yao Jiankang
CNNIC

>There are also some useful examples of
> situations in which it may not be the right model.  For example,
> assume that my Russian had not deteriorated from fluency to
> non-existent in the last 50 years.  I might maintain a personal
> address of 
>   [email-masked]
> but want to have the mail sent to a business-address mailbox if
> it could not be delivered there, say
>   [email-masked]
> That would give my From: field a structure like
>   From: <[email-masked] <[email-masked]>>
> 
> Which definitely do not reflect the same domain and might or
> might not reflect the same server.
> 
>>...
> 
>   john
>

---

From: SM <[email-masked]>
Date: Fri, 07 Aug 2009 02:46:30 -0700

>it seems that there is no definition about MUA from RFC.

 From RFC 4409:

    Message User Agent (MUA)

    A process that acts (often on behalf of a user and with a user
    interface) to compose and submit new messages, and process delivered
    messages.

    For delivered messages, the receiving MUA may obtain and process the
    message according to local conventions or, in what is commonly
    referred to as a split-MUA model, Post Office Protocol [POP3] or IMAP
    [IMAP4] is used to access delivered messages, whereas the protocol
    defined here (or SMTP) is used to submit messages.

>so it is better if I ask that the alt-address should be kept in 

A long time ago, configuration information was stored on the 
server.  Users could override the configuration.  There are 
advantages to having the alt-address on the server but that assumes 
there should be a relationship between the MUA and the MSA.

Regards,
-sm

---

From: John C Klensin <[email-masked]>
Date: Fri, 07 Aug 2009 06:10:55 -0400

--On Friday, August 07, 2009 17:07 +0800 YAO Jiankang
<[email-masked]> wrote:
 
> An e-mail client (also mail user agent (MUA) or e-mail reader)
> is a frontend computer program used to manage e-mail.

See RFC 5598.

>....
> normally, the server will keep all the email accounts
> information. the MUA only keeps the personal email account
> information.
> 

I think there are lots of good reasons to keep the information
on the server.  I think there are also lots of good reasons to
keep the information on the client.   The problem isn't what you
ask for; it is what the standard requires.  I don't think the
standard can _require_, even at the level of a SHOULD, either
one.  If we are ever to have the information specified in the
MUA, or directly by the user, then there has to be syntax for it.

Now, one could remove forward-path downgrading entirely, remove
the notion of in-transit downgrading (even for the
backward-pointing addresses) entirely and put some language into
the specs indicating that it would be perfectly reasonable (but
not required) for a sending-side system (either MUA or
Submission Server) to intercept an NDN that indicated
non-support for the i18n extensions,  modify the message by
substituting all-ASCII information, and sending it back out
without involving the user.  That would be consistent with the
principle that programs acting as agents for the user, at the
user's request and presumably under the user's control, can do
things for the user without explicitly involving her.   

That is a model that can be implemented consistent with the
existing specs, so the question is whether to permit and support
en-route downgrading in addition and under what circumstances to
do so.

>...
> yes, nothing can prevents your sending out a message "From"
> [email-masked] or [email-masked]  because you are
> email experts and know how smtp 
> runs. but most normal email users who do not know the
> mechanism of the smtp has little chance to try  sending out a
> message "From" [email-masked] or [email-masked].

We have never found security by obscurity to work very well.  I
also note that "normal email users" are probably well-behaved
people to whom the idea of faking an address would never occur.
To those to whom it does occur, the knowledge is only a few
keystrokes away.  And the MSA-based mechanisms that are intended
to prevent their doing so could be extended to MSA tests for
alternate addresses as well.

> so I prefer that there should a mechanism to control the

Other than very aggressive measures by MSAs (e.g., permitting
submission only from addresses matched to the user or that
authenticate using some mechanisms), nothing is going to
prevent, or even significantly reduce, abuse of alt-address
other than not having alt-addresses.  We've know, and discussed,
that since this effort started.

   john

---

From: Joseph Yee <[email-masked]>
Date: Fri, 7 Aug 2009 08:35:15 -0400

Sent from my iPhone

> there should be a relationship between the MUA and the MSA.

Agreed with SM, this is a design decision, up to the service  
provider.  From WG perspective we can make recommendation or write  
best practice.  I don't think we can say it must be MUA or MSA.

Personal thought:
Header 'From' controlled by user in most cases today, some call it  
identity in MUA.  I would guess no behavior change because of EAI.

Regards,
Joseph

>
> Regards,
> -sm
> _______________________________________________
> IMA mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ima

---

From: John C Klensin <[email-masked]>
Date: Fri, 07 Aug 2009 09:14:01 -0400

--On Friday, August 07, 2009 08:35 -0400 Joseph Yee
<[email-masked]> wrote:

>...
> Personal thought:
> Header 'From' controlled by user in most cases today, some
> call it identity in MUA.  I would guess no behavior change
> because of EAI.

Unless an alternative address must be specified there, in which
case all of the MUA's identity (or equivalent) mechanisms must
be rewritten.

Note that 

   From: mailbox1, mailbox2

While rarely used, is perfectly valid, even though two MAIL
commands for the same message (with different addresses) are not.

If one assumed that a reply to one of the addresses was
sufficient, then

  From: i18n-local-part@IDN, ascii-local-part@ascii-domain

might accomplish quite a lot, without new syntax.  I would
assume, but don't know, that many legacy MUAs which are used to
dealing with all sorts of garbage anyway would either accept the
i18n address without noticing or would complain about it, drop
it, and continue with the other address.    

As a side-effect, that would eliminate most of the claim about
binding of the two addresses, but, as Yao has pointed out (and
as we discussed perhaps a year ago), that claim isn't very
strong anyway and might cause problems.

Beyond that, I don't have any idea how that dual-From syntax
would work with most MUAs or how easy the adaptation would be to
make it work, but it might be useful for someone to examine the
case in which we had:

   MAIL FROM:<i18n-local-part@IDN>
alt-address="ascii-local-part@ascii-domain"
   ...
   From: i18n-local-part@IDN, 
      ascii-local-part@ascii-domain
   ...
and all forward-pointing addresses in ASCII.  

That approach would clearly be wrong for forward-pointing
addresses, where each address is expected to be a separate one,
but the semantics of multiple From: elements have always been a
little unclear... unclear enough that assuming that they loosely
identify the same entity is actually not much of a stretch.

Just thinking while typing here... this may be a dumb idea.

    john