On Sun, 2015-06-21 at 13:16 -0400, John C Klensin wrote:
>
> --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.
Hope I never suggested this was a bug. I agree - this is a new feature.
I'm doing this for personal reasons - benchmarking myself. I am not
discussing this in general with the meeting (yet).
> > 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.
The test I ran for "márk@???" was me sending the e-mail via
evolution (my MUA) on my linux powered laptop. This "submits" mail (via
submission) to my own server (Linux + exim) which then
"delivers" (SMTP) the email onwards... (to "diver.co.za")... another
Linux box I have in a data center.
Basically, I can type some accented characters easily from my
keyboard....
When trying with the Russian name, that was done by a Russian on his
laptop (I had no clue what to type)... via a Microsoft laptop, using a
web browser connecting to gmail...
This gave the SMTPUTF8 error.
I later cut'n'paste the Russian address into evolution on my laptop - as
with "márk@???".... and it (appears to) works just fine.
So it would appear that I may have enough things somehow working just
fine. I'd hate to break this by adding "SMTPUTF8" support....
(ie - Can one Offer SMTPUTF8 on receiving, but don't insist that its
there on Sending??? - unlike GMail)
I have not tried pop/imap via evolution to see if that works.
Worked fine in the systems webmail interface - which probably means that
imap works...
> 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).)
I'm a techie myself, currently feeling like a fish out of water...
--
Mark James ELKINS - Posix Systems - (South) Africa
mje@??? Tel: +27.128070590 Cell: +27.826010496
For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za
