Subject: [Ima] ALT-address

From: yangwoo ko <[email-masked]>
Date: Thu, 28 Jul 2005 12:07:39 +0900

Resending just to test whether the mailist list works for
me and to get some responds from others regarding this
issue.

---

Dear John,

I would like to ask/raise three questions/issues regarding
the ALT-address. Though some of them may be beyond the scope
of our draft and yours, we need to consider them to make
I-email workable in real world.

(1) How to enter it?

According to your draft, we should not try to generate an
ALT-address from an I-email-address. It means there should
be a way for a user to obtain the ALT-address and input it
into MUA. One of possible ways is to use electronic name
card (e.g. vCard). As of today, we obtain email addresses
in various ways. We may copy and paste them from (web)
documents. We may get them during phone calls. For those
non structured or off-line situations, how can we deliver
the ALT-address without too much pain?

(2) Can I extract both I-email-address and ALT-address from
email messages?

ALT-addresses are defined within the context of SMTP. Thus,
we do not have them in mail messages in my box. Then, how
can I generate the proper ALT-addresses (or I-email-addresses)
from email addresses appeared in message header? You draft
mentions only Return-Path field. What about other fields?

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

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.

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

With my best regards

_______________________________________________
Ima mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ima

---

From: John C Klensin <[email-masked]>
Date: Thu, 28 Jul 2005 00:39:56 -0400

> me and to get some responds from others regarding this

I apologize for not responding to the earlier copy of this note
which you sent me separately (probably after discovering that I
wasn't on the other list).   For your information and that of
others, I am working very hard to get ready to leave for Paris
and to finish other work that needs to be done first.  These
technical notes on the IMA topic take me a long time to write
because the issues are complex and I want to answer precisely.
But that means you will probably see fewer and fewer responses
between now and next week.

More below.

>... 

Please see my note from yesterday.  Take a phone call as an
example.  If you speak on the phone to a colleague in Korea, you
will presumably give him or her your address in Korean.  You can
also verify that address can be used by both of you.  So there
is no need to have an Alt-Address at all.   By contrast, if you
and I talk on the phone, you are going to give me an ASCII
address because, if you pronounced your Korean address to me, I
would have no idea what to do with it, since I cannot write, or
even effectively look up, either Hanji or Hangul characters.
So, again, you would not need an Alt-Address.   

In practice, I believe that the Alt-Addresses are needed only
when (i) you are communicating with someone for whom your
native-script address is intelligible and (ii) you do know the
state of each other's mail servers or the path between them.
That case will certainly occur, but it may not be common in
practice.

There are actually a very large number of ways by which the
purpose of an Alt-Address could be accomplished.  What I don't
think anyone has done is to really work through all of the cases
(certainly I have not).  Which ones are most effective depend on
assumptions about address books, server availability, and so on.
For that purpose, I think we are going to need a face-to-face
meeting and a whiteboard to actually try to do some engineering
design work together.

Let me give two examples which are actually alternatives to the
Alt-Address idea, rather than answers to the question of how one
obtains one:

	(i) Instead of putting an alt-address in as a parameter,
	one uses an LDAP (or equivalent) server whose address
	either appears as a parameter or is obtained by a
	service-location DNS query associated with the domain
	part of the address.  If the primary, internationalized,
	address is unusable, the SMTP sender queries the LDAP
	server with the i18n address and gets back a
	corresponding ASCII string.  Of course, this would
	require that the LDAP server exist and be populated with
	the relevant records, but it completely removes the
	burden from the end user.
	
	(ii) Instead of putting an alt-address in as a
	parameter, we use the existing VRFY command to support a
	slightly new function, but one that is consistent with
	its definition (as long as UTF-8 VRFY arguments are
	permitted by whatever ESMTP extension permits i18n
	addresses at all).   If the primary, internationalized,
	i18n address is unusable, the client sends VRFY with
	that address to the server for the mailbox domain and
	that server returns an appropriate ASCII address. 

The second of these does not require end user intervention or
knowledge, although it probably requires the ability to read the
local alias table.  In both cases, there are issues with relays
and offline users that I have not explored.  But the point is
that there are many options possible.

> mentions only Return-Path field. What about other fields?

Largely because I just ran out of time, but partially because,
again, the issues have not been explored fully enough, the draft
does some hand waving about headers and then points to Paul
Hoffman's long-expired draft about just making the entire header
collection into UTF-8.  My recollection of the discussion of 18
months or so ago was that we considered both the option of
having some headers exist in both ASCII form and UTF-8 form.  We
also talked about using message encapsulation to handle the real
(i.e., internationalized) headers if it was necessary to
downgrade to ASCII.   Since the restrictions on non-ASCII
characters in headers ultimately apply only to the 822/2822 set
and other rules can be created for anything that is embedded in
MIME structures, encapsulated UTF-8 headers could stay in UTF-8,
presumably with some type of content-transfer-encoding.    If we
shift the entire header collection into UTF-8 and encapsulate if
needed, then there is still an issue about supplemental headers
(or supplemental subfields) for the Alt-address if that is
needed, but the primary addresses are unchanged.  If we do not,
then we have a fairly long list of other issues.

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

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

> not yet found any possible attack through this discrepancy.

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.

 best regards,
     john

---

From: "YAO Jiankang" <[email-masked]>
Date: Thu, 28 Jul 2005 18:10:13 +0800

if alt-address is used, as an IMA user, I prefer that the address is computed instead of inputing it.

Jiankang YAO
CNNIC
----- Original Message ----- 
From: "John C Klensin" <[email-masked]>
To: "yangwoo ko" <[email-masked]>; <[email-masked]>
Sent: Thursday, July 28, 2005 12:39 PM
Subject: Re: [Ima] ALT-address

[email-masked]

---

From: yangwoo ko <[email-masked]>
Date: Fri, 29 Jul 2005 11:34:40 +0900

Dear John and others,

Now points get quite clear to me. Though JET's draft and John's draft 
happen to use the same name "ALT-address", their usages are a little bit 
different. The common thing is that the ALT-address is to be used when 
given email address is not usable by anything by any reason.

The fundamental difference is that JET's draft aims to realize IMA 
quickly while John's draft tries to provide rather a longer term 
solution to the IMA issue.

As pointed out by John, there are various options we can take. I wish we 
could come (or at least start to come) up with good findings during the 
next week at Paris.

See you at Paris.

IMA mailing list
[email-masked]

---

From: "YAO Jiankang" <[email-masked]>
Date: Fri, 29 Jul 2005 15:42:32 +0800

----- Original Message ----- 
From: "yangwoo ko" <[email-masked]>
To: "John C Klensin" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, July 29, 2005 10:34 AM
Subject: Re: [Ima] ALT-address

> could come (or at least start to come) up with good findings during the 

Yes, we'd better try our best to get a good result in Paris since IMA is so important to us.

YAO Jiankang
CNNIC

---

From: John C Klensin <[email-masked]>
Date: Fri, 29 Jul 2005 08:32:03 -0400

--On Friday, 29 July, 2005 11:34 +0900 yangwoo ko
<[email-masked]> wrote:

> 
> Dear John and others,
> 
> Now points get quite clear to me. Though JET's draft and
> John's draft happen to use the same name "ALT-address", their
> usages are a little bit different. The common thing is that
> the ALT-address is to be used when given email address is not
> usable by anything by any reason.
> 
> The fundamental difference is that JET's draft aims to realize
> IMA quickly while John's draft tries to provide rather a
> longer term solution to the IMA issue.

Yes, but I think it is also important to understand the reason
for the difference in making decisions about the options.  The
difference is not primarily between "quickly" and "longer term".
Instead, it is about mail management and mail application
options.  Automatically generating an Alt-Address by simply
encoding the entire local part as an ACE will work, and work
well, under one condition.  That condition is that all email
addresses are atomic.  In other words, the local part is a
simple mailbox name on the recipient host with no internal
structures or coding.  

Atomic local parts are, of course, the most common case.
Certainly, they are the intended case for every public mail
service (hotmail, yahoo, pobox, gmail, mail.com, etc.) that I
know of.

However, a decision that local parts are going to be
algorithmically encoded by the sending system is essentially a
decision that one will never have a structured (i.e., not
atomic) local part in a non-ASCII mailbox address.   Perhaps
that it would even be reasonable to say "for a given mailbox
either i18n or a structured address, but not structured
internationalized addresses".  I make enough use of structured
addresses that I would be reluctant to advise users of
internationalized forms to give them up forever (see below), but
that is not a decision I should try to make.

Much of the problem with the difference between the two
approaches is due to the fact that one cannot tell whether an
address is structured or not by looking at it.  If one could,
then it would be possible to devise a short term plan of "atomic
local parts only" and then devise a longer-term plan for
non-atomic local parts.  But there is no algorithm for making
that distinction so, unless we provide a specific and formal
syntax for non-ASCII structured addresses (I think that might be
hard), there is no "short term": a decision to automatically
encode the Alt-Address is forever an exclusion of structured
addresses.

There is no rigid rule in this: one could make the decision that
structured addresses are not important and will never been
important.  At some level, that is just an engineering tradeoff,
although I would certainly hate to hear complaints, a few years
in the future, about how those who use ASCII addresses have more
capability than those who have decided to use local scripts.
 
> As pointed out by John, there are various options we can take.
> I wish we could come (or at least start to come) up with good
> findings during the next week at Paris.

I would like to suggest two design principles for thinking about
these problems.  Certainly, these are not the only possible
design principles or guidelines, but please consider whether or
not they are useful:

(1) It is reasonable to talk about "short term" and "long term"
solutions separately only if one can define a strategy for
getting from the "short term" approach to the "long term" one.
It is ok to not have the long term approach completely defined
but, unless there is some logic or proof of concept of a way to
shut down the short term plan and move to the longer term one,
then the short term plan becomes the permanent one and we need
to be prepared to live with it, and whatever restrictions it
imposes, forever.  Even if the long term plan is
backward-compatible with the short-term one, any special
processing needed to support the short-term plan will be with us
forever unless there is a clear and plausible strategy for
removing the short-term methods from the Internet.

(2) Whatever solution we agree upon now -- for the long term or
for the short term without a plan to eliminate the short term
aspects completely-- will be with us for a very long time.  If
we need to do some extra work now to get to the desired
long-term state when IMAs are widely deployed,  that is a
reasonable thing to do.  But imposing extensive extra processing
or requirements that will be around forever in the interest of
making a slightly faster transition is probably not a good
decision: our target should be a long-term plan with maximum
flexibility and minimum extra processing and operations overhead
relative to traditional email.  Then we should figure out the
most efficient way to get to that point... transition plans,
short-term extra processing, and so on.  Please do not make bad
decisions for the future in order to get a little bit more
deployment a little bit more quickly.  We would all regret that
in a few years.

> See you at Paris.

Yes.  I look forward to continuing these discussions there and,
I hope, at APAN.

regards,
    john