Re: Fw: [idn] IDNs in email message bodies

["Adam M. Costello" <amc@cs.berkeley.edu>]

Edmon <edmon@neteka.com> wrote:

> But if we are talking about an IDNA approach, "A"pplications or
> "A"gents are assumed to have to change.  I would not expect that a non
> IDNA aware browser to be able to resolve an IDNA name even if it was
> cut and pasted from an IDNA aware MUA...

This explains why we've been having trouble understanding each other.
As I see it, one of the biggest reasons to use ACE is that it allows
someone with today's non-IDN-aware software to reply to a message from
someone with an IDN-address.  I don't see how else you're going to
deploy IDN.  If people try out the new & improved IDN stuff and discover
that some of the messages they send cannot not be replied to, a lot of
them will probably give up on the IDN stuff and go back to using what
worked.

"Eric A. Hall" <ehall@ehsco.com> wrote:

> > If the MUA and MTA are not IDN-aware, and the address in the From:
> > field is a non-ACE IDN, then this lookup will fail.
>
> But this specific scenario won't fail due to ACE, it will fail due to
> the mailer not conforming with the standards which were already in
> place (ASCII only in domain names).

Yes, I totally agree.  I'm trying to convince Edmon that domain names in
message headers need to be ACE.

> In this case, the original sender (which the reply is being directed
> to) should not have specified their address as a charset-encoded IDN,
> but instead should have written it as a charset@ASCII sequence and
> rejected anything that wasn't @ASCII.

Well, it's not clear whether the local part should use RFC 2047
encoded-words.  RFC 2047 forbids the use of encoded-words in any part of
an addr-spec.  Encoded-words are designed for parts of the headers that
are strictly for human consumption, not the machine-readable parts.  ACE
might be better choice for the local part of email addresses (but with a
slightly different nameprep that allows all ASCII characters).

> More problematic is extra-config data, such as a hand-coded Reply-To
> header field in the message, as this data will bypass the mailer's
> boundary checks.

I don't see why.  According to RFC 822 the Reply-To: field has the exact
same syntax as the To: field, and MUAs routinely do syntax checking on
the To: field, so they should do the same checking on the Reply-To:
field.

AMC