Re: rough sketch of a potential 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.

I don't know that problem3 is a real problem.  Do users really care what
the on-the-wire encoding looks like?  If so, why?

> > - 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.

you might could use CNAMEs or maybe DNAMEs to make domain names equivalent.
(that makes the lookup trickier - you have to lookup a.example.com to see
if it's a CNAME pointing somewhere else before you can lookup 
_ams._tcp.a.example.com for a SRV record because both records cannot exist
at the same time.)

I need to reread stuff about DNAMEs to know whether they'd work.

But it would really help to avoid being able to say that any email
address at any domain is equivalent to another address at a different
domain.  That introduces lots of problems.

> 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?

I've been wondering the same thing.  I put the note about signatures in
there before I got the idea to make all mappings within the same domain.
I left in the idea in case it might be useful for some other reason.

It might be desirable to provide for it, because we're moving
toward needing more and more authentication in email.  We might end
up needing a way to authenticate MXes too.  And of course we might
eventually start using DNSSEC in a big way (even though it's hanging
by a thread on the t-shirts)

> (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.)

no, they're not obvious to me yet.  but I haven't tried to do a 
thorough security analysis.