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 apollo13
Recipients apollo13
Date 2013-09-21.19:22:28
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1379791348.59.0.547034800598.issue19063@psf.upfronthosting.co.za>
In-reply-to
Content
Take the following example:

>>> from email.mime.nonmultipart import *
>>> from email.charset import *
>>> msg = MIMENonMultipart('text', 'plain')
>>> cs = Charset('utf-8')
>>> cs.body_encoding = None
>>> msg.set_payload('А Б В Г Д Е Ж Ѕ З И І К Л М Н О П.', cs)
>>> msg.as_string()
'MIME-Version: 1.0\nContent-Type: text/plain; charset="utf-8"\nContent-Transfer-Encoding: 7bit\n\nА Б В Г Д Е Ж Ѕ З И І К Л М Н О П.'

Till python 3.3.2 this created the email as 8bit, which is in line with what Thunderbird creates on my box. And if I understand the RFC correctly (https://tools.ietf.org/html/rfc2045#section-2.7) 7bit should only be used for ASCII. This issue was introduced by http://hg.python.org/cpython/rev/64e004737837 -- I changed orig = msg.get_payload(decode=True) back to it's original value (decode=False) in encode_7or8bit and get the "correct" behavior again. Running the tests didn't cause any errors (I hope I ran the correct one).
History
Date User Action Args
2013-09-21 19:22:28apollo13setrecipients: + apollo13
2013-09-21 19:22:28apollo13setmessageid: <1379791348.59.0.547034800598.issue19063@psf.upfronthosting.co.za>
2013-09-21 19:22:28apollo13linkissue19063 messages
2013-09-21 19:22:28apollo13create