--On Sunday, June 21, 2015 17:50 +0200 Mark Elkins
<mje@???> wrote:
> I'm sitting in the "Universal Acceptance Steering Group
> Workshop" at ICANN in Buenos Aries. Decided to test the email
> of my own home grown systems.
>
> I run exim (4.84) on Gentoo.
> User names are stored in MySQL.
> I found a friendly Russian and he created the user
> "андрей@diver.co.za" in my Database.
>
> He found that GMAIL was able to attempt the delivery of a test
> mail to this address but came back with...
>...
> Is there a fix for this yet???
First, I hope you and the folks at that workshop are clear that
this is a feature enhancement (see Jeremy's note) but it is not
a bug to be fixed.
> I guess I'm looking for full EAI compliance in my mail
> systems.. (EAI - Email Address Internationalised)
While MTA support is essential in reaching that goal, it turns
out to be the easy part. Depending on how the rest of your
systems are set up, compliance in mailstores, IMAP and POP
servers, MUAs, and MUA functions like address books are
considerably more complex. Equally important, because of the
way things work a delivery MTA operator would almost certainly
be ill-advised (words like "insane" come to mind) to enable
production SMTPUTF8 support without first having upgraded and
competent versions of those post-delivery systems under control,
including having worked out plans for what to do when a user
tries to access a message that contains non-ASCII addresses or
headers from an IMAP or POP server or client that does not
support them.
> A similar test with "márk@???" worked just fine.
That would indicate that you've somehow gotten support for
"Latin" characters outside the ASCII repertoire but not for (at
least some) non-Latin repertoires. The SMTPUTF8 (aka "EAI")
specifications don't allow for that case, so there is a bug
somewhere... and it is more likely that the second case works
than that the first one does not.
Good luck,
john
(for identification only, I co-chaired the WG that created the
SMTPUTF8 specs and am co-author of the "framework" spec that
lays a lot of the above out (RFC 6530).)
