On Sun, 2015-06-21 at 13:16 -0400, John C Klensin wrote: > > --On Sunday, June 21, 2015 17:50 +0200 Mark Elkins > <[email protected]> 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á[email protected]" 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á[email protected]" 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á[email protected]".... 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 [email protected] Tel: +27.128070590 Cell: +27.826010496 For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za
smime.p7s
Description: S/MIME cryptographic signature
-- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
