This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author dandre
Recipients dandre, r.david.murray
Date 2011-07-28.15:29:38
SpamBayes Score 3.8418234e-06
Marked as misclassified No
Message-id <1311866979.15.0.523800971747.issue12649@psf.upfronthosting.co.za>
In-reply-to
Content
Thanks again for the clarification.

I may not look like it ;), but my fanciness has to go even further. So, for the sake of completeness, it appears that the world is now up to UTF-8 local parts of email addresses, and punycode for the domain?

https://bugzilla.mozilla.org/show_bug.cgi?id=614930

But then there's RFC 5335 which seems to go further, although, frankly speaking, I'd love to see examples in RFCs every now and then, and it sounds like it's not exactly supported by too many mailers along the way.

http://tools.ietf.org/html/rfc5335

Either way, if the Mozilla example is something to live up to, I hope I'll be allowed to have WS between a non-UTF-8 '<', the UTF-8 local part and the '@', because email.Headers will always create that, right?

Is there a place I can register such a fancy email address (AND understand the website and webmailer's UI) for testing purposes?

Hats off to you who is dealing with these ugly compromises, keeping an outdated underlying standard on life support.
History
Date User Action Args
2011-07-28 15:29:39dandresetrecipients: + dandre, r.david.murray
2011-07-28 15:29:39dandresetmessageid: <1311866979.15.0.523800971747.issue12649@psf.upfronthosting.co.za>
2011-07-28 15:29:38dandrelinkissue12649 messages
2011-07-28 15:29:38dandrecreate