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 Sharebear
Recipients Sharebear
Date 2008-01-14.11:17:10
SpamBayes Score 0.0028079702
Marked as misclassified No
Message-id <>
Steps to Reproduce
>>> from email.mime.multipart import MIMEMultipart
>>> from email.mime.text import MIMEText
>>> multipart = MIMEMultipart()
>>> multipart.set_charset('UTF-8')
>>> text = MIMEText("sample text")
>>> multipart.attach(text)
>>> print multipart.as_string()
MIME-Version: 1.0
Content-Type: multipart/mixed; charset="utf-8";
Content-Transfer-Encoding: base64

Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

sample text
>>> multipart = MIMEMultipart()
>>> multipart.attach(text)
>>> multipart.set_charset('UTF-8')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/
email/", line 262, in set_charset
    self._payload = charset.body_encode(self._payload)
  File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/
email/", line 384, in body_encode
    return email.base64mime.body_encode(s)
  File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/
email/", line 148, in encode
    enc = b2a_base64(s[i:i + max_unencoded])
TypeError: b2a_base64() argument 1 must be string or read-only buffer, 
not list

The first example above demonstrates that if you call set_charset('UTF-
8') on a MIMEMultipart instance before adding child parts then it is 
possible to generate a multipart/* message with an illegal Content-
Transfer-Encoding as specified by RFC 2045[1] "If an entity is
   of type "multipart" the Content-Transfer-Encoding is not permitted to
   have any value other than "7bit", "8bit" or "binary"."

In the second example, I demonstrate that if you try and call 
set_charset after adding child parts, the code exceptions. The user 
should at least be provided with a more targeted exception.

Where should this be fixed? The smallest fix would be to add a check to 
set_charset to see if it is dealing with with a multipart message but 
as I express in issue1822 I feel the better design would be to move 
this subtype specific logic into the appropriate subclass.

Again, this is something I'm willing to work on in next saturday's bug 
day if I can get some feedback on my architectural concerns.

Date User Action Args
2008-01-14 11:17:14Sharebearsetspambayes_score: 0.00280797 -> 0.0028079702
recipients: + Sharebear
2008-01-14 11:17:14Sharebearsetspambayes_score: 0.00280797 -> 0.00280797
messageid: <>
2008-01-14 11:17:11Sharebearlinkissue1823 messages
2008-01-14 11:17:10Sharebearcreate