Subject: Re: [IMA] re: JET IMA meeting memo

From: "YAO Jiankang" <[email-masked]>
Date: Fri, 2 Sep 2005 09:46:09 +0800

if all SMTP servers can support IMA in one night, that is better. but it seem impossilbe.
so when UTF-8@UTF-8 is used, some transition strategy should be needed in order to be easy deployable for IMA.
when some smtp servers including some internal servers can not support IMA, an alt-address may be a good choice whether  or not the alt-address is ACE or others.

----- Original Message ----- 
From: "Jeff Yeh" <[email-masked]>
To: "'YAO Jiankang'" <[email-masked]>; <[email-masked]>
Sent: Friday, September 02, 2005 9:33 AM
Subject: RE: [IMA] re: JET IMA meeting memo

> > If my understanding is correct.
> > Since option 2 don't have down-grade mechnism, it might 
> > bounce with a error like "IMA not supported" when the email 
> > meet  a non-IMA enabled SMTP.
> > That means all the SMTP servers on the delivery path needs to 
> > upgrade to make it work.
> > 
> > Actually option 2 is very much close to option 3. 
> > What diffent is option 3 provide a ALT address (or convert to 
> > ACE, in that case we have the same problem like option 1 have 
> > to solve) as downgrade mechnism.
> > I think this is very flexible to have a ALT address because 
> > we can define it as a optional field.
> > If one can make sure all the SMTP on his delivery path is IMA 
> > enabled, he may skip the ALT address.
> > 
> > Jeff Yeh
> > 
> > 
_______________________________________________
IMA mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ima

---

From: yangwoo ko <[email-masked]>
Date: Fri, 02 Sep 2005 11:35:05 +0900

Dear Yao and Jeff,

> if all SMTP servers can support IMA in one night, that is better. but it seem impossilbe.

We do not necessarily have "ALL" of them support IMA. Only
servers involved in a transport of an email with IMA in
address fileds are required to do so.

My guess is that if we have IMA standard, then most
of big email account providers (e.g. Daum in Korea having
millions of "Korean" email users) will start to support it
very soon. (Or, as a NIC, we may start a promotion program
far in advance.) Then there will be a period during which
more and more servers are upgraded. Then we will see a
point at which server upgrading saturates. From this point
on, still many mail servers would not be IMA compliant. But
most of users do not know/care of this fact and are hardly
affected by them. Still there are many people using very
old style email client that lacks many features we commonly
have. But who cares?

> so when UTF-8@UTF-8 is used, some transition strategy should be needed in order to be easy deployable for IMA.

Well, easy come easy go. As far as easiness of deployment
in introduction phase is concerned, ACE@ACE is the best.

Deployment for UTF8 with downgrade can be considered easier
than ACE@ACE. Because, it will work even none of servers
is upgraded. After that, who will want to upgrade servers?
Mail system operators will be far less interested in
upgrading because most of mails are using the "old
plain downgraded" addresses.

>>>That means all the SMTP servers on the delivery path needs to 

Severs are regarded as "working correctly" if they bounce
mails that they cannot handle.

s/work/be delivered/

>>>enabled, he may skip the ALT address.

If one is not sure then what will he/she/it do? He/she/it will
put ASCII-only address in address fields and send. This is the
way that option 3 works in the introduction phase.

Difference is that the action of "alternating" is done by SMTP
servers or by human/mail-generating-software.

---

From: "YAO Jiankang" <[email-masked]>
Date: Fri, 2 Sep 2005 10:56:49 +0800

----- Original Message ----- 
From: "yangwoo ko" <[email-masked]>
To: "YAO Jiankang" <[email-masked]>
Cc: "Jeff Yeh" <[email-masked]>; <[email-masked]>
Sent: Friday, September 02, 2005 10:35 AM
Subject: Re: [IMA] re: JET IMA meeting memo

> old style email client that lacks many features we commonly

it seems a very good argument.
consider the situation that IMA will only be used and sent and received  by those who can read or be interested in IMA. those who can not read Multi-Language will not use IMA at all. so we don't care for whether or not those smtp servers in whhic all the registered email users have not interested in IMA at all are upgaraded to support IMA. if some email user in some company are interested in IMA will urge the email running company to follow IMA standard.

the path you said seems a workable path.
IMA-standard---->promotion----->a lot of IMA supported SMTP servers.

Yao Jiankang
CNNIC

---

From: "Jeff Yeh" <[email-masked]>
Date: Fri, 2 Sep 2005 12:01:14 +0800

> My guess is that if we have IMA standard, then most of big 
> email account providers (e.g. Daum in Korea having millions 
> of "Korean" email users) will start to support it very soon. 
> (Or, as a NIC, we may start a promotion program far in 
> advance.) Then there will be a period during which more and 
> more servers are upgraded. Then we will see a point at which 
> server upgrading saturates. From this point on, still many 
> mail servers would not be IMA compliant. But most of users do 
> not know/care of this fact and are hardly affected by them. 
> Still there are many people using very old style email client 
> that lacks many features we commonly have. But who cares?

Yes, that really be a good approach either we adopt UTF8 with downgrade or
without downgrade.

> 
> Well, easy come easy go. As far as easiness of deployment in 
> introduction phase is concerned, ACE@ACE is the best.
> 
> than ACE@ACE. Because, it will work even none of servers is 
> upgraded. After that, who will want to upgrade servers?
> upgrading because most of mails are using the "old plain 
> downgraded" addresses.

In my stand point of view, I think to use pure chineses email address is
pretty cool itself.
To able to use this feature will motivate people (in IDN communtiy) to
upgrade their system.
And also, I believe there are also a lot of people are interesting in using
I-Email (John for instance).
If UTF8@UTF8 without downgrade is adopted, there will be some barrier for
them.
In addition, to have a optional ALT address will do no harm.

> mails that they cannot handle.

Agree.
But the email still can't go to receiver end.

> 
> 
> If one is not sure then what will he/she/it do? He/she/it 
> will put ASCII-only address in address fields and send. This 
> is the way that option 3 works in the introduction phase.
> 
> Difference is that the action of "alternating" is done by 
> SMTP servers or by human/mail-generating-software.
> 

Agree.
That's the problem we have to define.
Does alt-address MUST goes to the same mailbox with I-Email?
I believe there is reason not to forece them the same.
I put some discuess you have with john eailer.
====quote========
> (3) Are they same?
> 
> Your draft allows an I-email-address and an ALT-address may be 
> designated to different mailboxes. However, we think that those two 
> boxes are for the (logically) same user.

I think they usually will be.  Perhaps even "almost always".
But, given other constraints imposed by the email system, there is no reason
to make that a protocol requirement and, I believe,
several reasons not to.    One example has to do with some of
the "additional processing" mentioned in the draft and an earlier note.  Let
me take a far-fetched example, just to illustrate what might happen here.
Suppose you told me that it would be very convenient for you if I provided a
mailbox name in Hangul.  Ok, by patching or configuring my MTA to disable
its ASCII-only checks and getting it to support the relevant SMTP option, I
could presumably arrange that, making an alias that points to my standard
mailbox.  So far, one user, one mailbox.

But the nature of these things is such that, if I support a Hangul address
for myself, sooner or later you or someone else in Korea will accidentally
send a message whose body is in Hangul to me.  Remember I can't read such
message bodies, even to pronounce the syllables without understanding the
vocabulary.
But, if that happens several times and I can find a decent automatic
translation program that can handle Korean in Hangul-> English, I'm going to
have a lot of incentive to attach my Hangul address to an agent that will
inspect the message body looking for Unicode character ranges that
correspond to Hangul and, if it finds them, send the text off for
translation before depositing the message in my mailbox.  Still the same
mailbox, of course, but the processing for one address is different from the
processing for another.

For those of us who have been using email intensely for many years, the idea
of "one user - one mailbox" is, itself, too narrow.  Offhand, I don't know
how many different mailboxes I have set up at the moment, but it is more
than five or six.
All sorts of routing occurs among mailboxes and folders, different
processing occurs at different addresses, and so on.
And I use domains to receive mail that it is likely that you have not heard
of.  This should not be relevant, but it might be.

> There is no algorithmic way to uniquely generate an ALT-address from a 
> given I-email-address. Thus, there is no way to verify that an 
> I-email-address and an ALt-address are destined to the same user.

That is correct.  Given other elements of the email system, there is, of
course, no way to verify that an ASCII email address will go to the user you
expect.  That is why, when things are important, we  have mechanisms for
encrypting messages and various "deliver URL rather than message text"
techniques are popular in some cases.

> What if an I-email-address and an ALT-address in an email designate 
> different users? The mail will be delivered to different users 
> depending on the status of I-email capability on the route. This may 
> happen due to errors of sending users or even attacks by malicious 
> users. I have not yet found any possible attack through this 
> discrepancy.
> But, there could be ...

Of course.  But either the sending user has to be deceived or something has
to tamper with the message en route.  In the first case, the deception could
occur with the ASCII address today.
In the second, anything that can do that sort of tampering can do so more
generally.

Again, suppose I ask you to send me a piece of mail addressed to
[email-masked] for some reason of convenience.  Since this message
is not digitally signed and you haven't verified the signature through some
mechanism you trust, you cannot be certain that the request to use that
address instead is valid and coming from me.  Assuming it is a valid request
from me, you still have no way to know where that address is going, to whom
it is being forwarded, etc.  All of those issues are matters for the mail
server that answers to addresses at bogus.domain.name,
and it is fairly secretive.   If you want to be sure that only I
can read the mail, we know how to provide that protection.  But, if you want
to be sure the mail is, in fact, going to a destination which you can
guarantee and over which you have control... well, not with SMTP.

So, yes, there is an attack in this area, but neither i18n addresses nor
Alt-Addresses change the properties of that attack at all.
=====end of quote=====

Jeff Yeh

---

From: yangwoo ko <[email-masked]>
Date: Fri, 02 Sep 2005 15:27:54 +0900

Jeff Yeh wrote:
> (snip)

What barriers do you have in your mind? Entering Chinese
email addresses by the people who cannot even read those
characters? Yes, it is a barrier. But how does the
downgrade feature mitigate the problem? Still they need
to handle Chinese email addresses as primary addresses
for Chinese friends.

> In addition, to have a optional ALT address will do no harm.

Well, it is too bold to say that. We need consider many cases
including;
(1) which address should be recorded in header fields
(2) which address should be used for spam protection measures
(3) maybe more...

> But the email still can't go to receiver end.

Yes.

> That's the problem we have to define.

My argument is that we don't need to define it. Just let
users do whatever they want.

> (snip)

---

From: "Jeff Yeh" <[email-masked]>
Date: Fri, 2 Sep 2005 16:10:45 +0800

> to handle Chinese email addresses as primary addresses

One solution is when a IMA SMTP talking to a non IMA SMTP.
The IMA SMTP can put a additional header like "IMA-address: xxx@xxxx".
Thus, even if the delivery SMTP does not support IMA but receiving client
does.
He can still found the IMA address in the mail header.

> (2) which address should be used for spam protection measures

ALT address itself doesn't raise any new problem.
Some problem is already happing in our current email environment.
Such as sending email address (mail from) between reply address.
And also some SPAM mail use different email within SMTP communciating
(RFC2821) and mail header (RFC2822).
I think it is necessary to put both IMA address and ALT address on the
header.
Mail server administrators can filter by one of the address or both the
addresses. 
It depends on the local management policy.

Jeff Yeh

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 02 Sep 2005 20:02:07 +0200

Think of it this way....

with ace@ace, you are adding a kluge to the existing mail system, and 
praying that it does not interfere with the other kluges.

with UTF8@UTF8, you are building a new mail system.

Any new system that's successful will have gateways built to/from the old; 
if you don't define them, entrepreneurs will make "something that works".

With UTF8@UTF8 + Downgrade, you are trying to design in the gateways. 
They're still gateways, and as Einar Stefferud used to say: "All gateways 
lose information. Some of them are better at it than others." People will 
still have reason to prefer the un-gatewayed environment.

That's my thinking, after listening to this conversation....

                      Harald

---

From: John C Klensin <[email-masked]>
Date: Fri, 02 Sep 2005 16:07:19 -0400

--On Friday, 02 September, 2005 16:10 +0800 Jeff Yeh
<[email-masked]> wrote:

> The IMA SMTP can put a additional header like "IMA-address:
> xxx@xxxx". Thus, even if the delivery SMTP does not support
> IMA but receiving client does.

Not unless you also extend the mail header syntax in a way that
makes such a header valid (at present, it must be all-ASCII).
You also need to be prepared for the header to get "lost": many
gateways and firewall SMTP implementations will drop any
unrecognized headers in the interest of security and reliability
of interpretation and the IMAP header abstraction will not pass
this header through to clients.

I believe that something like that header is the right thing to
do, but we should not overestimate how effective it will be, nor
how easy it is to get propagated.    Also, the idea of MTAs
adding mail headers is high-risk.  For example, some
spam-detectors will reject any message whose headers intermix
trace (Received and Return-path) fields with other fields.

> Some problem is already happing in our current email
> environment. Such as sending email address (mail from) between
> reply address. And also some SPAM mail use different email
> within SMTP communciating (RFC2821) and mail header (RFC2822).
> I think it is necessary to put both IMA address and ALT
> address on the header.
> Mail server administrators can filter by one of the address or
> both the addresses. 

I think this is right, but we need to fill in the details.
 
    john

---

From: yangwoo ko <[email-masked]>
Date: Wed, 07 Sep 2005 14:03:50 +0900

Please help me understand Harald's comment correctly.

Following Harald's comment, I come to a conclusion that we will
see several different gateways regardless of having a gateway
standard. If so, why do we need to define it in the standard?

Harald Tveit Alvestrand wrote:
> Any new system that's successful will have gateways built to/from the 
> old; if you don't define them, entrepreneurs will make "something that 
> works".
> 
> They're still gateways, and as Einar Stefferud used to say: "All 
> gateways lose information. Some of them are better at it than others." 
> People will still have reason to prefer the un-gatewayed environment.
>

---

From: "Edmon Chung" <[email-masked]>
Date: Wed, 7 Sep 2005 05:01:57 -0400

If I understood it correctly, I think what Harald means is that each SMTP that implements the "downgrade" specified by the protocol is in fact a gateway to the non-IMA-aware system (hence the plural).

That being said, it is possible that people will have other "gateways", today some mailers still send double byte chars as is...

Anyway, Harald please correct me, but I think the point here is that we should view the "downgrade" as a "gateway" for the new IMA-aware mail system to connect back to the existing mail system (like tunneling), and therefore there could be information loss (and not that regardless of specifying a protocol standard there will be different gateways).

Edmon

---

From: "Edmon Chung" <[email-masked]>
Date: Wed, 7 Sep 2005 05:07:49 -0400

----- Original Message ----- 
From: "Edmon Chung" <[email-masked]>
> If I understood it correctly, I think what Harald means is that each SMTP (sorry, should probably say mailer) that implements the "downgrade" specified by the protocol is in fact a gateway to the non-IMA-aware system (hence the plural).
> 

--------------------------------------------------------------------------------

---

From: yangwoo ko <[email-masked]>
Date: Wed, 07 Sep 2005 18:57:51 +0900

Following Edmon's interpretation, it is unavoidable for utf8@
based solution to suffer from loss of information while
downgrading. (That is really what "down grade" means...)

Then questions we need to investigate are;
(1) how large the information loss is when we use either
     (1)-1 utf8@ with downgrade
     OR
     (1)-2 utf8@ without downgrade (or non-IETF standard downgrade)
(2) whether the information loss is significant or not
(3) maybe more...

Regards

Edmon Chung wrote:
> ------------------------------------------------------------------------
>

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 07 Sep 2005 09:32:37 +0200

> standard. If so, why do we need to define it in the standard?

Experience from X.400 to SMTP gatewaying says that multiple gateways that 
make different decisions on how to reformat data makes the user experience 
much more painful than having most gateways perform the same way.

My point was mainly that you will have gateways whether you want them or 
not, so having UTF8@UTF8 + no downgrade just means that you will have no 
chance to define how gateways should behave before they start appearing.

---

From: yangwoo ko <[email-masked]>
Date: Wed, 07 Sep 2005 21:18:53 +0900

Thanks for clarification. More comments are in-line below.

Harald Tveit Alvestrand wrote:
> Experience from X.400 to SMTP gatewaying says that multiple gateways 
> that make different decisions on how to reformat data makes the user 
> experience much more painful than having most gateways perform the same 
> way.

New mail system should work with several legacy mail systems. In
order to provide downgrading in "the same way", we should define
the least common denominator as the downgrade scheme. I guess
falling back to ASCII-only address known to sender SMTP server
can be the L.C.D.

However I still do not understand why the downgrading should be
defined as a function in the network rather than letting end
points (email client or human/non-human user) handle it. If a
packet cannot find a path to which it is routed, it should be
dropped rather than trying to get it through via roundabout.

---

From: John C Klensin <[email-masked]>
Date: Wed, 07 Sep 2005 15:14:48 -0400

--On Wednesday, 07 September, 2005 09:32 +0200 Harald Tveit
Alvestrand <[email-masked]> wrote:

>> Following Harald's comment, I come to a conclusion that we
>> will see several different gateways regardless of having a
>> gateway standard. If so, why do we need to define it in the
>> standard?
> 
> Experience from X.400 to SMTP gatewaying says that multiple
> gateways that make different decisions on how to reformat data
> makes the user experience much more painful than having most
> gateways perform the same way.
> 
> My point was mainly that you will have gateways whether you
> want them or not, so having UTF8@UTF8 + no downgrade just
> means that you will have no chance to define how gateways
> should behave before they start appearing.

For whatever it is worth, and while I would have explained it
differently, this is the reason I've said before that there is
essentially no difference between "UTF-8@UTF-8 with downgrade
strategy" and "UTF-8@UTF-8 with no downgrade".  In both cases,
the protocol will need to identify what should happen when a
client trying to send a message that contains non-ASCII address
material tries to send to a server that is not IMA-capable.  The
issue cannot simply be ignored.

Now, to me, there are three possible classes of answer to the
"what happens" question:

	(i) A specific translate-and-downgrade procedure is
	specified and required.  As Harald, Edmon, and others
	have pointed out in different ways, this will inevitably
	result in some information loss.  But predictable
	information loss is better than unpredictable behavior.
	Unfortunately, if the translation procedure is at all
	complex or subject to local options or variations, some
	implementers will get it wrong and we may have
	unpredictable behavior anyway.  Conversely, whatever we
	say about requirements, some servers will choose to
	reject IMA traffic rather than provide the downgrade
	procedure -- they will just be non-conforming.
	
	(ii) A "must bounce" model is specified.  As Harald
	points out, this will result in some servers trying to
	invent and do downgrades of their own as a means of
	getting commercial advantage.  They will mess it up, and
	they won't do it the same way, which will result in
	further problems.   The only defense against this is a
	very careful analysis of why downgrades are impractical
	and drop too much information and that analysis just
	about requires designing the downgrade mechanism (see
	below).
	
	(iii) An optional downgrade mechanism, with the tools to
	carry sufficient information to make it possible, but
	with the provision that a client, confronted with a
	non-upgraded server, may either bounce or implement and
	apply the downgrade.

Now, (i) and (iii) will turn out to be exactly the same in
practice.  Some servers will bounce and some will downgrade.  If
the downgrade procedure is easy and clear enough and is seen to
have marketplace value, more servers will implement it.  If it
fails on any of those three criteria, either more servers will
bounce (even if it makes them non-conforming) or some will get
the downgrade wrong, causing interoperability problems.  By
contrast, (ii) without a standard downgrade procedure, will
result in some implementers generating their own, incompatible,
versions of how to do downgrades.

I think we have no other choice other than to try to sort out
and specify a downgrade procedure and, for the reasons above,
make it optional.  If we succeed, then we basically have case
(iii).  If we convince ourselves that downgrades are basically
unworkable, we have either a version of (iii) in which no one
will implement the downgrade or a version of (ii) in which we
say "should not attempt to downgrade" and supplement it with an
informational RFC that explains why attempts to do IMA
downgrading are harmful.

Debating "downgrade or not" as a philosophical issue is probably
not useful.

regards,  
   john