Re: rough sketch of a potential solution

Keith Moore <[email protected]> wrote:

> This is intended to be a rough sketch of something which I'm wondering
> might be a solution.

This is interesting.  We have now identified three distinct and largely
separable problems:

problem1: Allow non-ASCII addresses to interoperate with existing
          ASCII-only software and protocols.
solution: Some sort of ASCII-Compatible Encoding (ACE).

problem2: Allow non-ASCII addresses to interoperate with existing humans
          who don't share a common script/language.
solution: Some sort of address-mapping service.

problem3: Allow non-ASCII addresses to appear literally on the wire.
solution: Some sort of new versions/extensions of the message header
          format, SMTP, and other mail-related protocols.

The solution to problem 1 is incrementally deployable on its own because
it uses the existing infrastructure and allows individual users to begin
using non-ASCII addresses immediately.  The solutions to problems 2 and
3, which add value by building new infrastructure or updating existing
infrastructure, can leverage the incremental deployability of the ACE
solution by using it as a fallback.

> - Every address in a message header would have a distinguished,
>   "fallback" address expressed in (hopefully transcribable) ASCII.
>   These addresses would go in the normal From/Reply-To/To/CC/Bcc etc.
>   fields.
>
> - Each of those addresses could optionally have zero or more
>   equivalent local-parts listed, which could be expressed in various
>   languages/scripts.
>
>   (I say equivalent local-parts instead of equivalent addresses,
>   because it minimizes the potential for problems.

But how useful is it to have many equivalent local parts in many
different scripts/languages, if they are all constrained to share the
same domain part with its single script/language?  How would this
accomplish the goal of making addresses memorable and transcribable?  If
you want to sell this idea, I think it needs to provide alternate forms
for the entire address, not just the local part.

Also, I think the proposal can be simplified by eliminating the stuff
about signatures.  In the message header, I don't see how signing the
mappings would be helpful.  Today when someone sends me a message,
they can put whatever addresses they like in the To/Cc fields that
are going to be displayed to me (regardless of the actual set of
recipients), and every MTA/router along the way has the opportunity to
alter those addresses without me being able to detect it.  Why should
the binding between the fallback form and the alternate form have
stronger protection than a regular ASCII recipient address?

You also suggested having signatures on the mappings returned by the
mapping server.  What good does it do to have stronger protection
against the mapping server than the SMTP server?  If I'm trusting the
DNS to point me to a mail exchanger that will honestly deliver mail for
that domain, then I might as well trust the DNS to point me to a mapping
server that will honestly provide correct alternate forms for local
parts within that domain.

(Or maybe there are very good reasons for the signatures that you
thought were too obvious to mention, and I'm just missing the point.)

AMC