Subject: Re: [Ima] ALT-address

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

> 
> 
> --On Thursday, 28 July, 2005 12:07 +0900 yangwoo ko
> <[email-masked]> wrote:
> 
> > 
> > Resending just to test whether the mailist list works for
> > me and to get some responds from others regarding this
> > issue.
> 
> 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.
> 
> >... 
> > 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?
> 
> 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.
> 
> > (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?
> 
> 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.
> 
> > (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.
> 
>  best regards,
>      john
> 
> 
> _______________________________________________
> Ima mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ima
> 

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