You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
assignee=Noneclosed_at=<Date2015-05-16.18:05:28.417>created_at=<Date2014-07-21.21:29:00.766>labels= ['type-feature', 'expert-email']
title='RFC 6531 (SMTPUTF8) support in smtplib'updated_at=<Date2015-05-16.18:05:28.415>user='https://github.com/zvyn'
After blindly raising errors for 'SMTPUTF8' without 'BODY=.*' I found out that 'SMTPUTF8' alone is actually perfectly fine (for using international names in addresses but sending ASCII data). Which means I did a mistake in the smtpd patch :(
The attached 3rd version of the smtplib patch implements your suggestions, including re-factoring of the mail option parsing. One test is commented out until smtpd is fixed. I'll do that as -part of- bpo-21795 tomorrow.
Coming back to this, I noticed a number of things wrong with the logic that I'm not sure how I missed before. I had to rewrite pretty much all of the logic. The good news is the patch is now smaller :)
The new tests are failing, because they are wrong: the msg argument to sendmail/mail *must* be a byte string if smtputf8 is in effect, since an email message may contain multiple encodings as well as other binary data. (Well, the msg argument could be an ascii string, but what would be the point?)
I'm uploading this without fixing the tests because I'm out of time for now and may not get back to it before the weekend. Perhaps someone else will have time to work on the tests before then.
Rewrote the tests to keep all the existing tests working against an unmodified SimSMTPServer, so that we know backward compatibility is maintained. And as I said, I changed the tests to reflect that a non-ascii body must be provided as binary data, which means I deleted two tests.
(Note: in thinking about this, I vaguely remember some conversations where we thought it might make sense that if someone provided a message string that when encoded to utf-8 then conforms to the RFC, it would be OK to auto-encode it as utf-8, but I'm just not comfortable with that idea. It provides insufficient value compared to the danger of blindly encoding something that is not RFC conformant...if someone does build a such a unicode message, they should have to convert it themselves before passing it to smtplib, as a sign they know what they are doing :)