homepage

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, macfreek, r.david.murray
Date 2013年12月29日.01:57:18
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1388282240.23.0.294109826823.issue20084@psf.upfronthosting.co.za>
In-reply-to
Content
Hmm. Perhaps it would be better to close that one as a duplicate of this one, since this one doesn't start out as an error report that then got converted into an enhancement request...
The patch on that issue doesn't have anything to do with what the issue turned into, which is indeed a bit confusing.
I haven't given much thought to *how* to implement this support. Depending on utf8smtp capability being present seems the best course. If support isn't available, then the library should continue to raise an error, as it does now, but indeed the message could be improved.
In real life, of course, we want our message to get delivered regardless of whether or not smtputf8 is available. To make that work, it will be advisable for the application to use the send_message interface rather than the sendmail interface: pass in a Message object, which can be automatically serialized as utf8 if smtputf8 is available, and the normal CTE encoding dances if not. This of course will require support from the email package, specifically a 'utf8 only' serialization mode.
If one is using smtplib only, then the application is responsible both for checking for the smtputf8 capability and branching accordingly, and for getting all the data correct...when I said "string only" I was referring to the methods in question (RCPT, etc). DATA is a different story, and that has to handle both ascii-only strings or properly encoded (per the email RFCs) binary. Automatic encoding of non-ascii string DATA is dangerous, and would only work if the input is correctly formatted for the utf8 charset throughout. Personally I'd rather use the email package to ensure that...so if an application wants to bypass the email package, I think requiring it to manually encode the DATA string into utf8 is an acceptable interface requirement, to make it *clear* that there is no way to automatically encode an arbitrary email message (other than by using the email package).
These are just preliminary thoughts...there is probably more design work to be done before this can be implemented.
History
Date User Action Args
2013年12月29日 01:57:20r.david.murraysetrecipients: + r.david.murray, barry, macfreek
2013年12月29日 01:57:20r.david.murraysetmessageid: <1388282240.23.0.294109826823.issue20084@psf.upfronthosting.co.za>
2013年12月29日 01:57:20r.david.murraylinkissue20084 messages
2013年12月29日 01:57:18r.david.murraycreate

AltStyle によって変換されたページ (->オリジナル) /