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 r.david.murray
Recipients barry, christian.heimes, jesstess, macfreek, r.david.murray, sdaoden, torsten.becker, zvyn
Date 2017-06-02.15:41:34
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1496418094.8.0.239275226012.issue11783@psf.upfronthosting.co.za>
In-reply-to
Content
The email package currently forces explicit IDNA use currently.  The new policies are supposed to support it automatically but I they currently don't.  I'm not sure we should add it to the old interface (parseaddr/formataddr) any longer, but I don't object to doing it, either.

Not handling idna automatically would go against the entire design of the new email policies, which is to produce unicode from the wire encoding for programs to work with, and convert back to wire protocol on output.

The work on resolving the idna2008 issue belongs in issue #17305, where MvL (who wrote the original idna codec) points to IMO the correct solution (a uts46 codec) in msg217218.
History
Date User Action Args
2017-06-02 15:41:34r.david.murraysetrecipients: + r.david.murray, barry, macfreek, christian.heimes, jesstess, sdaoden, torsten.becker, zvyn
2017-06-02 15:41:34r.david.murraysetmessageid: <1496418094.8.0.239275226012.issue11783@psf.upfronthosting.co.za>
2017-06-02 15:41:34r.david.murraylinkissue11783 messages
2017-06-02 15:41:34r.david.murraycreate