On Tue, Apr 10, 2018 at 11:32 AM John R Levine <jo...@taugh.com> wrote:

> >> The Gmail and Hotmail support handles other people's UTF-8 addresses
> >> in mail but they still don't provide UTF-8 addresses on their own
> >> systems.
> >
> > From what I can tell, Gmail and outlook.com's support is basically
> "just send
> > UTF-8", that is, it will send EAI messages without the server offering
> the
> > extension.
> I know the people involved and can check.

I can confirm.  We even serve SMTPUTF8 messages to POP & IMAP without
POP clients really don't care, and it turns out that trying to downgrade on
the fly for IMAP is
incredibly expensive because of the annoying FETCH parameter kitchen soup,
and storing two copies
of the message depending on whether the client was capable or not... not to
mention most clients
not supporting it directly, just not worth it.

As Ned alludes to, downgrading is actually a worse experience (hello DKIM &
DMARC), which I imagine is
why it was dropped in the move from UTF8SMTP to SMTPUTF8.

> > I agree that this isn't difficult. What's difficult is keeping track of
> the
> > EAI-ness of a message as it goes through processing like alias
> expansion, which
> > can turn an non-EAI message into an EAI message or vice versa.
> > Support for the nested encodings message/global creates may also be
> > nontrivial.
> I don't even try.  In the places where it matters, I scan the envelope and
> message headers for characters with the high bit set.  This is wrong, but
> it doesn't seem much wronger than far more complex approaches.  Haven't
> thought too much about message/global but in the MTAs I use, it's only a
> MUA problem.

Everyone jumped on me when I asked why there wasn't a header that specified
that a message was 6532 vs 5322.  I solved it by just changing our default
that 8bit messages were iso-8859-1 to UTF-8, which happens to be true even
without 6532.

As for whether nested encodings are hard, that probably heavily depends on
your mime parser.
None of the one's I've used have had any issues.

> >> The hardest part, which I haven't done yet, is generalizing
> >> the address mapping that MTAs do on incoming mail. ...
> > This I frankly don't care about, as I believe that doing it in a
> meaningful
> > language-specific way is impossible.
> I meant interpreting addresses in mail to my own mailboxes, the
> generalized version of case folding and subaddresses.  Maybe you're right
> that undotted i's won't work in a lot of places, but I'd be surprised if
> they didn't work in Turkey.

Aren't there standards for doing this?  I'm sure they're not perfect, and
they suffer from
the problem that they aren't symmetrical, but its not something we have to

mailop mailing list

Reply via email to