Re: [EAI] Thinking about requirements / downgrade

[Shawn Steele <Shawn.Steele at microsoft.com>]

Somehow I missed John's message earlier :)

I get your point, I'm not sure it's going to matter to people trying to migrate to EAI email though.  If an email provider is pretty sure these don't apply to their scenario, then it may not influence them that some other person may do different things with IDN-like tokens...

- Shawn

------------------------------
Date: Wed, 16 Sep 2009 09:46:04 -0400
From: John C Klensin <klensin at jck.com>
Subject: Re: [EAI] Thinking about requirements / downgrade
To: Harald Alvestrand <harald at alvestrand.no>,	Ernie Dainow
	<edainow at ca.afilias.info>
Cc: Mark Davis ? <mark at macchiato.com>,	Shawn Steele
	<Shawn.Steele at microsoft.com>, ima at ietf.org
Message-ID: <CAEE5C9E257FD94FF9FDED9F at PST.JCK.COM>
Content-Type: text/plain; charset=us-ascii



--On Wednesday, September 16, 2009 08:16 +0200 Harald Alvestrand
<harald at alvestrand.no> wrote:

> Ernie Dainow wrote:
>> 
>> Harald Alvestrand wrote:
>>> The overarching issue found with variants of this proposal
>>> previously  rejected was:
>>> 
>>> Can we guarantee (for a sufficiently strong version of
>>> "guarantee")  that there are no valid mailboxes that "just
>>> happen to look like" the  Punycoded strings?

>> I'm not sure it is necessary for a standard to guarantee
>> this. I think  it is just the responsibility of email
>> administration to avoid name  collisions. Currently, when a
>> new email address is requested, the  email administrator for
>> the domain on which the name is requested (or  email admin
>> software) will not grant the email address if 1. the address
>> (local name) is assigned to someone else on the domain. 2.
>> the address is already in use as an alias on another email
>> account  on the domain.

> My worry is about what happens if the recipient tries to
> decode the left-hand side as if it was a Punycoded name when
> it is not. Unless one can tell the difference between those
> domains that use Punycoded LHS and those that do not, a
> recipient will apply the Punycode decoding to left-hand sides
> indiscriminately. This can lead to similar effects as the
> "Bush hid the facts" bug (see
> http://en.wikipedia.org/wiki/Bush_hid_the_facts for details).

Let me say what Harald, Bill, and others have said from a
different perspective and a little more strongly.  

Once upon a time, before the web and before we could assume that
almost every node connected to the network was well-connected
(end to end) with just about every other node,  the most common
method for transmitting command instructions from one host to
another (or a device connected to another) involved email
messages that could be received, stored, and forwarded by
intermediaries.  In many cases, local-part addresses were used
to encode information and to secure and/or authenticate the
commands with what amounted to shared-secret encryption and
anti-reply coding.

It may be worth noting that some very similar techniques have
emerged in the "delay-tolerant networking" area.  If one cannot
do end-to-end (or end-to-closely-coordinated-surrogate)
handshakes, there aren't that many options.

Those applications led to some email local parts that were truly
bizarre if one assumed that local parts are some stable
variation on a user name or ID/handle.  Worse, not only are
strings that look remarkably like IDNA ACEs plausible, it is
impossible to do the equivalent of sweeping the DNS tree or
inquiring of top-level registries to give some confidence that
choices are being made that don't conflict with existing uses
(such sweeps and questions were part of the process of selecting
the ACE prefix, and some candidate prefixes were eliminated on
the basis of existing usage).

There is at least anecdotal evidence that methods using local
parts to transmit command and control information (either coded
into the local-part or using the local part to authenticate the
message payload) have not dropped out of use, even though their
presence as a percentage of messages on the Internet has
certainly dropped.

For better or worse, little of this stuff is written down in,
e.g., the RFC series.  At least some of the reason is that many
similar, but certainly not identical, mechanisms have been
invented over and over again in different places and rely on
"security by (often rather extreme) obscurity", rather than
cryptographic integrity... but that doesn't make them less
problematic from our standpoint.

Those mechanisms are among the reasons why the email community
established the very strong "only the receiving system can
interpret a local part and it MUST NOT be messed with in
transit" rules that appear in RFC 5321 and its predecessors and
has been unwilling to change them.  IMO, even if this WG reached
the conclusion that such tag-identified encodings were a good
idea, the proposal would be destroyed on IETF Last Call.

Finally, while such address-encoded information is certainly
still in use, the odds of showing up on, e.g., a search through
Google databases are just about zip --the data aren't archived,
the messages don't refer to each other, many of the addresses
are one-time-use, and natural language processing mechanisms
don't work because these addresses are about as far from natural
language as one can get.  And, finally, anyone who can't
dedicate a host, or at least a domain or primary address and
family of subaddresses, under their control to the particular
control tasks at issue is just not in the game... so the more
relevant and sophisticated methods are not using public/free
email systems of the AOL/ Hotmail/ Gmail/ Yahoo/ etc persuasions.

It just isn't a worthwhile path to try to follow.

      john