Re: rough sketch of a potential solution

>> > 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?
>
> The absolutely final, non-expert end-user doesn't care
> (as long as the MUA does the right job, which to some
> extent is dependent on how convoluted the encoding is).
> But as soon as somebody wants to do anything like a perl
> script working on their mails, a procmail script, or anything
> in that direction, or even just use 'more' or 'less' to peek into
> their mail folders, it starts to matter big time.

for better or worse we departed from that direction a long time ago.  
for that matter, so has the most widely used operating system, which 
really doesn't acknowledge anymore that there is such a thing as plain 
text.

>> 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.
>
> I'm a big affraid that using CNAME or DNAME for a domain name such
> as company.com might have rather restricting consequences on other
> domains such as www.company.com and others. That would be due to
> the specific usage patterns of domain names for email addresses,
> which I think we should not assume people would be ready to give
> up.

you're probably right, though I think this problem could be solved in 
other ways.  for instance, consider a.example.com and b.example.com 
that were intended to be equivalents.  each would have a SRV record 
pointing to the same hostname/port.
sender types <stuff>@a.example.com but the distinguished domain is 
b.example.com. sender's MUA does the following.

- lookup SRV for _ams._tcp.a.example.com, gets back ams.example.com 
port NNN
- contacts ams.example.com port NNN
- >>> I'm looking for address lookups on "a.example.com"
- <<< distinguished domain is "b.example.com"
- >>> lookup equivalents for "<stuff>"
- <<< equivalents are ...
- >>> (close connection)
- sender then looks up SRV for _ams._tcp.b.example.com.  if it gets 
back the same
   result as the original SRV record, it considers the results valid 
(after all, it was just
   talking to that server).  if not, it considers the entire lookup 
invalid and falls back to
   IMAA encoding