Re: rough sketch of a potential solution

At 19:22 03/11/15 -0500, Keith Moore wrote:

> > 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)?
>
>With those, you get the fallback behavior of encoding everything
>in IMAA.  Either that or for unsigned messages the lookup can be
>deferred until the message is injected into the Internet mail system.
>
> > * 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.
>
>The proposal specifically mentions this.  MUAs only look up
>alternatives when composing messages, not when reading them,
>and this is one of the reasons.
>
> > * Secure e-mail.  What should MUAs display as the sender address?  The
> >   ASCII version or non-ASCII, looked up via the service you propose?
>
>They should show the address in the sender's certificate as the party
>who signed the message, which shouldn't have to be the same as the From
>address anyway.  The addresses in the message header should be displayed
>separately.
>
>Again, MUAs don't do the address mapping lookup when displaying a message.
>
> >   How do you secure the service connection?
>
>If necessary, TLS should be sufficient.
>
> >   What should be stored in
> >   OpenPGP or S/MIME attributes; the ASCII version or non-ASCII
> >   version?
>
>This needs more thinking, but I think you want to use either the
>ASCII fallback address or the IMAA form of the "native" address
>as the principal name.   If the signature format can support
>multiple names for a principal, any of the alternative addresses
>could also be used, provided that all principal names are included in the
>sender's certificate.  Naturally the devil is in the details.
>
> > * Internationalization of MTAs?  Having ASCII in MTA configuration
> >   files or log files is not sufficient.
>
>MTAs are free to log alternative address forms if they wish.
>
>Log file format is in any event a locale-specific issue, so it's not clear
>that it would be appropriate for an MTA to log an unencoded UTF-8 address to a
>log file on a system that used some other charset in its locale.

First, it's not a system that uses a locale, it's just a certain
user/application/whatever. Also, encodings are more and more
being separated from the concept of locale.

In addition to that, assuming addresses in many different (languages
and) scripts, you better use UTF-8 or another encoding that is able
to encode all of Unicode/ISO 10646.


> > 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.
>
>Even if we were designing a new mail system from scratch to handle these
>requirements, I think we would need a lookup across the net at the time
>that the message is composed (or submitted) in order to handle the case where
>at least one recipient can't transcribe the sender's "native" address.

As I tried to explain in another mail, I'm not really clear on this.
The sender should not send an address that the receiver doesn't know
how to read. If they did, reply functions and so on should still
work on such an address. The only thing that wouldn't work would be
handing over this address to a third party via paper.
[It may easily work electronically in that the address can just
be copy-pasted into an email to the third party.]

Regards,    Martin.