Subject: Automatic address remapping with and without EAI (was: Re: [EAI] i18n of localpart versus i18n of email RFC standards)

From: John C Klensin <[email-masked]>
Date: Fri, 01 Dec 2006 09:02:46 -0500

Because this is off-topic for the WG mailing list and because my
private explanation had no effect, it will be my last posting on
the subject.  However...

--On Friday, 01 December, 2006 13:29 +0900 Soobok Lee
<[email-masked]> wrote:

>> so after EAI protocols are published, it is not our design
>> aim that  some email address form will be dis-allowed. 
> 
> in your example, "+" can be added as a legal delimiter for
> localparts. /=_! can be added as legal delimiters likewise.
> For my example, "[SOOBOK in UTF8].[LEE in
> UTF8][email-masked] can be autoconverted into
> "[email-masked]. No loss of
> information. dot and + and underbar was not lost. The
> receiving SMTP server parses it back to NONASCII in order to
> find data/instruction for whitelisting filtering. Even the
> receiving server can work directly on
> [email-masked]   without NON-ASCII version if it
> is already registered as an ascii *alias* for NON_ASCII in the
> server alias database.   Still I can find no problem at all.

This suggestion, too, was explored at some length on the old
IMAA mailing list.  There is no way to know that either "--" or
"+" are delimiters in the protocol sense and, as a base SMTP
issue, the IETF has consistently rejected proposals to
standardize _any_ syntax or syntax elements for the local-part,
including delimiters.    So while, in principle, "+" could be
"added as a legal delimiter for localparts", the IETF has
consistently rejected that idea (for, IMO, good reasons and
after bad experiences when such things have been tried).  

Even "--" is much more likely to have been used with specific
semantics in an email address than it was in domain names.

In addition, based on observation of discussions about IDNs over
the last few years, there is every reason to expect the argument
to be raised, loudly, that if the local-part cannot be
_entirely_ in a non-ASCII script, without loss of functionality,
then the effort is a failure.  If a local-part of
<utf8-string>+<ascii-string> was globally acceptable, then we
would expect IDN1.IDN2.<ascii-tld> to be globally acceptable.
Many people and countries have argued, very loudly, that it is
not and should not be.

Also note that "special delimiter in the middle of the local
part", particularly with a requirement to switch scripts, can
raise very complex issues with the presentation of the address
(and how the user enters the address given a particular
presantation) when one of the scripts runs right to left.

These are fairly typical of the issues with these sorts of
proposals.  Any given one of them makes considerable sense in
one or more local contexts.  But, if one looks at it globally,
there is just no way to standardize the delimiters or the
mechanism without either restricting functionality in the
i18nemail case or making rather basic changes in the historical
email protocols.

>> > moreover, ACE encoding for downgrading may be geared to
>> > have minimum loss of information. For interoperability,
>> > some default ace encoding is good for MUA/MTA.
>> 
>> Yes, as you have already said, the EAI WG has not exclude
>> some MUA/MTA which may use its own version of  ACE encoding.
> 
> Yes. it's better we have one default ace encoding rather than
> having nothing ,  even though it can not be perfect and has
> some costs.

For email address local parts, "minimum loss of information" is
not good enough.  Either the information loss must be zero or it
is safer to reject or bounce the message and let the sender
correct the addressing (just as would probably be the case if I
tried sending mail to [email-masked]).  

Some of the same issues apply to "localprep".  We've given mail
system administrators advice for years that they should
interpret local parts in a case-insensitive way and avoid the
more complex quoting conventions permitted by the protocols if
they want messages to get through.  We've also advised them
that, while very long local parts are permitted, using them may
not be smart, or it might be wise to accept seven- or
eight-character truncations as  aliases (see below).  But we
have never changed the underlying rules.

For non-ASCII addresses, I think it would be silly for a mail
administrator who wants as many messages to get through to the
intended destinations as possible to specify addresses that are
not in NFKC form.  Probably we will discover that some
characters are a bad idea, or that setting up certain aliases
(perhaps according to a JET-like model) is wise because systems
elsewhere might inadvertently change what is typed.   But,
unless rather basic changes are made to how we do mail, it would
be a terrible idea to turn those conventions about mailbox
naming into a global rule that senders or intermediaries could
depend on.

Those issues about rules for name formation and alternate
addresses are the oddity in the whole downgrade discussion.
I've actually got a half-dozen email addresses, some of which
might be deliverable when another one is not.  And I've used
some in the past that won't work at all any more or, worse,
might reach someone else.   If you send to an address that isn't
working today, it is either held until it can be delivered or a
non-delivery message is sent back to you (and, with current
practices, you may or may not get the non-delivery message).  If
you sent to an address that isn't working at all, the attempt
will probably be rejected.

I'd argue that the same situation applies to telephone numbers.
If I put two or three of them on a business card, and you are
trying to reach me, you pick one and call it.  If it doesn't
work, you might try another.  You don't expect the network to
know what is on the business card and to try another one
automatically, nor do you transmit all of the numbers at once,
expecting the network to sort it out.  Of course, you might be
able to program your phone to try the numbers in sequence, but
that would be like putting the alternate addresses in an address
book and telling the MUA to try both addresses (assuming
canonical non-delivery messages, a problem that has been
discussed on this list before).  Or I might be able to set up
the network to do automatic forwarding, but that implies that
the number you dialed is reachable, at least in the sense of
reaching a switch that has the right database.

In any event, if you find out that the address you sent over the
wire isn't working, you either give up or figure out another
address to try, possibly after contacting me in some way that
does not involve the email system.   We don't have protocols for
guessing at different addresses, nor for transporting alternate
addresses along with the preferred ones.  And, for the last
30-odd years, I'm not aware of anyone thinking that was unusual.

regards,
  john

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