Subject: [IMA] Re: some issues about IMA in your draft

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

Dear all, 

   We'd better invite those who are interested in IMA to join this email list [email-masked].

  if someone want to be added, you can visist this website https://www1.ietf.org/mailman/listinfo/ima to input your email address in the first bland and submit it.

or tell me directly.

thanks

Yao Jiankang
CNNIC

----- Original Message ----- 
From: "John C Klensin" <[email-masked]>
To: "YAO Jiankang" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Tuesday, July 26, 2005 3:10 PM
Subject: Re: some issues about IMA in your draft

--On Monday, 25 July, 2005 10:53 +0800 YAO Jiankang
<[email-masked]> wrote:

>    I have finished reading your draft about IMA. It is really
> a good document, from which we can learn a lot of things. Some
> of the issues about IMA in this document are still needed to
> be discussed here.

Good.  And thank you for the kind words.

> In your draft, it said:” To be very specific about this, if
> the local part of an address is   encoded, e.g., with some ACE
> form as suggested in [JET-IMA], there is no practical way for
> the receiving system to know to decode it, rather than treat
> it as an ordinary mailbox name, unless it is   notified via a
> SMTP envelope extension.”

> My view: I don’t think so. For example, I have an email box
> with my name in cnnic.cn. my Chinese name with Chinese
> characters is “姚健康”, with punycode plus prefix
> “xn--” is “xn--nyQ63U02D”. for any receiver who has
> received my email address with [email-masked], it can
> chose to decode it if it can or keep it if it can not. Here we
> suggest that we use prefix to distinguish whether the local
> part of email address is encoded. This mechanism is like the
> mechanism we use it in IDNA.

Yes, it is very much like the IDNA mechanism.  The IDNA
mechanism was plausible because we were able to conduct a survey
of many DNS domains and discover that a sequence involving two
consecutive hyphen characters "--" was never used.  That was
unsurprising: the document on which key elements of the
"hostname" (LDH) specification were based prohibited that
sequence, but that text was, fortunately for IDNA, never picked
up.  For email use of a similar convention, there are three
problems:

(1) In the general case, your sending MUA cannot know, in the
general case, whether the receiving domain name can accept the
conversion convention and what it does to it.  Having the
sending system, or an intermediate one, knowing that it can
convert [email-masked] to [email-masked] requires
the same level of knowledge about the local part that deciding
that [email-masked] really indicates an address "abc" on
host "def" so that traffic can be routed to "def" directly,
rather than going through some.domain.

The above is obviously less of a problem, or no problem at all,
when you are communicating from your cnnic.cn address to another
cnnic.cn user.  But, if you are communicating across
(conceptual) domains, you need to somehow be assured that the
intermediate systems will not change the coding to meet their
needs.  We have avoided that problem, and kept Internet email
working, for the last 20 or 30 years, only by applying a very
strong "no one tries to figure out what the receiver is going to
do with an address other than the receiver".

That rule would work in this case if, for example, you always
typed the ACE form into your sending MUA, rather than expecting
it to do conversions.   It also would work in practice if your
MUA kept a list of receiving domains that it _knew_ would
enforce the convention and not permit automatic forwarding or
aliasing to systems that did not and made the conversions only
for those domains.  In general, that is a very difficult
requirement although it might work for many specific domains.
And it is not a requirement that would lead to a nice user
interface, since sometimes a Chinese-character local part would
be typed in, converted properly, and processed and, other times,
a similar name would be typed in but with a different mailbox
domain and be rejected as invalid.

(2) If one makes the distinction between peer-to-peer protocols
and client-server ones, IDNA is peer-to-peer (or, more
precisely, client-to-client).   The DNS acts only a passive
storage medium for something that neither it, nor any of its
protocols, try to parse or interpret.  One client encodes things
and puts them in, another client encodes things and goes looking
for a match.

Even if there were client-server elements of IDNA, we would
still have the conviction that, if a string is seen whose first
four characters are "xn--", it is an IDNA string (and, given
ICANN pronouncements and good sense, any other string starting
with two ASCII alphabetic characters followed by "--" is an
error or an unrecognized IDN-like conversion specification).
This isn't the case for email: real client-server issues are
involved, with the ACE system described in your document some
decoding is going to need to be done by the receiving MTA, and
so on.  

To illustrate this, suppose you were using subaddresses and, for
example, wanted to use "[email-masked]" to subscribe to,
and receive mail from, this list.  Now, as the sending user or
system, I can't tell whether "[email-masked]" represents
a mailbox, or a "JET" folder within the mailbox designated by
"[email-masked]", or as an indicator of special processing
that was to be done before the message was delivered to one
place or the other **(see below).  If the sending system encodes
"姚健康+JET" into a single ACE string, then:

(i) If the actual mailbox (or equivalent) in the message
store is named (or indexed) from the ACE string, the
receiving MTA/MDA does not need to do anything about
this protocol (at least assuming that the MDA can handle
Unicode strings).

(ii) If the actual mailbox (or equivalent) in the
message store is named (or indexed) from the UTF-8
string, and assuming that the MTA and MDA split is what
you assume it is (which will not always be the case) the
receiving MTA does not need to do any decoding, but the
MDA does.  Users typically have as little control over
MDAs as they do over MTAs.

(iii) If the message is to be delivered to the mailbox
named "姚健康", or some specific folder in that
mailbox, then the MTA must do the decoding so that it
can separate the address into mailbox and folder
elements.  In this case, the MDA does not need to have
any decoding logic for the ACE, but must support UTF-8
addresses.

In my environment, at least, a local-part such as klensin+smtp
actually goes into a separate folder, while klensin+mybank and
klensin+my-other-bank go to a separate mailbox (the same one for
both) and klensin+random-string goes into the "klensin" mailbox
and its "inbox" folder, but with some flags added to support
spam filtering.  Within the mailbox used for klensin+mybank and
klensin+my-other-bank, the two are separated from each other by
filtering and classification tools in the MUA.  The differences
among these similar-looking cases are not known to the senders
-- they are just told what address to use.  And I would consider
it a severe intrusion on my privacy, and an even more severe
intrusion on how I manage my personal and professional mail, if
the sender could even figure out what rules I use, much less
needing to understand them.  And the sender would need to
understand them if the local part on the wire was, for my
made-up version of your case, ACE(姚健康)+JET

-----
** (I need hypertext to write this... sorry).   That "special
processing" may be something like the following, again drawing
examples from how I manage my mail (but I am certainly not
unique).  In theory, the only party that should ever be using
the address [email-masked] is my bank.  Now, I know the
domains they use, the names of their sending servers, and the
address range allocated to them.   So, if something arrives for
that address, my mail server can validate the sender and, if
anything is amiss, color the message with a warning or route it
to a "probably phishing" folder.  Conversely, if something
supposedly comes from the bank that is not addressed to that
bank-specific address, it can be immediately discarded. Those
capabilities have, unfortunately, become an important feature
for me.
-----

(3) Finally, the sender really does not know the delimiters.
>From the above, you can guess that "klensin+smtp" is some sort
of tricky address, but it gives you no information, not even
enough to guess, about whether "[email-masked]" is as well.
If you are going to encode at the sending MUA, then the
structure must be exposed so that the receiving MTA can get hold
of the strings.  To the extent to which your desire is to use
all-Chinese local parts, you probably aren't going to want to
use "姚健康+JET" either -- you would presumable prefer a name
or abbreviation for JET in Chinese characters and a separator
that is in Chinese characters too.   Conversely, unlike the DNS
situation, "xn--nyQ63U02D" could be a perfectly valid local
part.  It could even designate 

* A folder, "nyQ63U02D", in the mailbox "xn" or

* "nyQ63U02D" could be a hash that designed a particular
command to be executed by the processor designed by "xn"
or

* "nyQ63U02D" could be an encoded digital signature to
authorize the "xn" action or, remembering that email
local parts are, unlike the DNS, not inherently
case-mapped, 

* it could be the ACE you anticipate, while
"XN--NYQ63U02D" might be something else entirely.

and so on.   In that context, the idea of an ESMTP option is
just to have the server tell the client "if you are interested
in using that convention, I (or the systems at my end) can
handle it" and then to have the client tell the server "ok, I'm
using that convention" (if the latter is needed, which it might
not be).  Since, in many cases, the server will need to be
modified anyway, and the sender-MUA definitely will (unless the
conversion is done in the sending MTA or Submission server), the
marginal costs of introducing that option are tiny.  Its biggest
impact is to prevent these encoding conventions from going
horribly astray, but the fact that it could eliminate the need
for them entirely is quite attractive to me.

> In your draft, you suggest a solution based on SMTP extension
> with an alt-address. You suggest that the alt-address should
> be gotten from other ascii address instead of ACE.
> 
> My view: it seems that we have to input two email addresses,
> one ascii address and the other IMA address if this mechanism
> is adopted. We can imagine that if we already know ascii
> adreess and have to input ascii address, why bother to input
> IMA address again. One purpose of using IMA is to avoid of
> using ascii address to convenient non-english speaking people.
> If we still need to input two, we have no convenience but
> increase un-convenience.   

Yes.  I keep circling around that one, and am not happy with any
of the solutions.  It also may not be much of an issue.  If you
are sending a Chinese address to your Chinese colleagues, and
all of you are upgraded as quickly as I would expect, it does
not make much difference what is in the Alt-Address: you are
just not going to use it and, indeed, leaving it off would be
perfectly safe.  By contrast, if you send a Chinese-character
address to me, I'm going to be in trouble: I can, to a limited
extent, cut and paste Chinese characters, but I can't read them,
look them up in a dictionary, and so on.  And, for those
purposes, I'm better off with the ACE than with the Chinese
characters, but I'll have trouble remembering one and trouble
even thinking about the other.

I assume you are probably in much the same state with Arabic,
Hebrew, Thai and hundreds of other scripts that I'm in with
Chinese.

The current "find an appropriate ASCII string and use it there"
proposal in the text of the I-D is not well-written (I had to
put the -03 draft together too rapidly to meet the deadline and
hence did not have time to reconsider that issue carefully).
Let me try to state it in a different way -- if you agree, we
can figure out how to write text:

(1) If you have an ASCII-based address that is widely known to
colleagues who communicate with you in English or other
languages using Roman-based scripts, it is probably best to use
it as the Alt-Address and encourage those who are sending you
mail to your Chinese-named address to use it as the alternative
if they want to.

(2) If you don't have such an address, and your address doesn't
have any special processing properties, subdivisions, or other
structuring, such as those outlined above, then the ACE form is
probably a perfectly good thing to use, as long as your
recipient system actually has a mailbox or local-alias using the
ACE form.

(3) If you use a  structured address form, then you need to make
up your own conventions about an Alt-Address, making sure that
it will work when received on a non-upgraded target system or
intermediary.

and, most important,

(4) If you and your correspondent are communicating in Chinese,
between Chinese-character-enabled systems (or IMA-enabled ones
more generally), you don't need to use the Alt-Address at all.

>   So I think that ACE address for Alt-address is better. 

See above.

> Another view from me is that whether we use server-ased
> solution or client-ased solution, both need to update to do
> some updating client software because some client software
> haven’t the function of recognizing the non-ascii email
> address. If non-ascii email address is used, it will report
> some error message.

I am not sure I understand what you are saying above.  But
anything we do will require client changes (to be able to enter
and understand non-ASCII addresses and to deal with some header
types or content that RFC 2822 now prohibits) and server changes
(to do some decoding at the receiver end).  

You should also understand that some of those "error messages"
may not be very attractive.  While one can hope that all of the
bugs have been eliminated from MUAs around the world, prior
experience leads me to believe that some MUAs will simply crash
when given a non-ASCII local part.  Also note that we are now
living in a world in which anti-spam software in assorted parts
of the email infrastructure will quietly drop any messages they
consider suspicious, and I would assume that some of them would
consider xn--gibberish to be quite suspicious.

> I appreciate your solution, but I think that alt-address
> should be ACE. So whether we use server-ased solution or
> client-ased solution, in some sense, we have to use  ACE in
> spite of how it is used.

As discussed above, it would be fine to have them be ACEs as
long as the conditions are met to make a whole-address ACE
appropriate.  Because there are circumstances in which that is
not true, the Alt-Address should be explicit, not [only]
calculated when needed.

regards,
    john
_______________________________________________
IMA mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ima