New submission from Jonathan Share:
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";
boundary="===============0973828728=="
Content-Transfer-Encoding: base64
--===============0973828728==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
sample text
--===============0973828728==--
>>> 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/message.py", line 262, in set_charset
self._payload = charset.body_encode(self._payload)
File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/
email/charset.py", line 384, in body_encode
return email.base64mime.body_encode(s)
File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/
email/base64mime.py", 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
Explanation
===========
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.
Notes
=====
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.
[1] http://tools.ietf.org/html/rfc2045#section-6.4
----------
components: Library (Lib)
messages: 59896
nosy: Sharebear
severity: normal
status: open
title: Possible to set invalid Content-Transfer-Encoding on
email.mime.multipart.MIMEMultipart
type: behavior
versions: Python 2.5
__________________________________
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1823>
__________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
