Re: rough sketch of a potential solution

Some immediate concerns with your proposals:

* Disconnected mail clients?  Mail clients that sit behind a gateway
  (e.g., UUCP, Enterprise e-mail solutions like Outlook)?

* Privacy leaks?  I would not want my client to hit the net every to
  look up a internationalized name for an incoming message, or even
  the first time.  It would reveal what I'm reading, when I'm reading
  it, and could be abused for many purposes -- e.g., spammers could
  find out which messages are read by sending messages from unique
  sender address.

* Secure e-mail.  What should MUAs display as the sender address?  The
  ASCII version or non-ASCII, looked up via the service you propose?
  How do you secure the service connection?  What should be stored in
  OpenPGP or S/MIME attributes; the ASCII version or non-ASCII
  version?

* Internationalization of MTAs?  Having ASCII in MTA configuration
  files or log files is not sufficient.

Essentially this proposal appear to add a i18n-layer for e-mail, a
"presentation" layer if you wish, on top of RFC 2822 and SMTP.  While
this may be preferable for ASCII people, having i18n as an "add-on"
appear rather fragile to me.  But that's only my initial reaction.

Fortunately, your proposal seems simple to deploy without touching
existing mail servers.  So, like IMAA, you could easily implement
this, and try to get a growing community to use it.  It would help in
answering if the problems listed above are real or not.

Regards,
Simon