[issue1822] email.mime.multipart.MIMEMultipart.is_multipart() returns false before items have been added.
New submission from Jonathan Share: Steps to reproduce == >>> from email.mime.multipart import MIMEMultipart >>> foo = MIMEMultipart() >>> foo.is_multipart() False Expected Result === True should be returned from MIMEMultipart.is_multipart() Notes = Looking at the implementation of is_multipart() in email.Message it would appear that if self._payload was initialised to an empty list in the constructor of MIMEMultipart when _subparts is None, this would be a sufficient fix for this issue. However, from an outsider looking into this code for the first time, this doesn't look like the best architecture, shouldn't the issue of whether a message has multiple parts, and logic specific to this be handled through inheritance. With the current implementation the superclass makes assumptions about how a subclass is implemented, this just feels wrong. Have I missed something, is there a good reason for things being as they are today? Feel free to take the discussion to the python-dev list, I have just subscribed, and I am interested in fixing this issue myself in the next bug day if someone can answer my questions above. -- components: Library (Lib) messages: 59895 nosy: Sharebear severity: normal status: open title: email.mime.multipart.MIMEMultipart.is_multipart() returns false before items have been added. type: behavior versions: Python 2.5 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1822> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1823] Possible to set invalid Content-Transfer-Encoding on email.mime.multipart.MIMEMultipart
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 "", line 1, in
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
[issue1823] Possible to set invalid Content-Transfer-Encoding on email.mime.multipart.MIMEMultipart
Jonathan Share added the comment: Martin, I can almost agree with you _if_ I was setting the Content-Transfer- Encoding myself, however I am not. I am setting the charset and the library chooses an appropriate Content-Transfer-Encoding to represent the mime part with. Currently I can't see any way other than reading the source or writing a test case (and that would require understanding what the email.mime module was doing "under the hood") for a developer to find out which Content-Transfer-Encoding was going to be used. Also, just from a usability point of view I would expect that creating an invalid mime part would be a little more difficult. Especially considering the fix should be as small as adding "if not encoding in valid encodings: raise SensibleException". __ 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
[issue1822] email.mime.multipart.MIMEMultipart.is_multipart() returns false before items have been added.
Jonathan Share added the comment: Attaching a patch for the quick fix I proposed below. I would still like to see some feedback regarding making the design of the mime module more object oriented. email.Message really shouldn't be making assumtions about how subclasses represent their state. Added file: http://bugs.python.org/file9214/issue1822.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1822> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1822] email.mime.multipart.MIMEMultipart.is_multipart() returns false before items have been added.
Changes by Jonathan Share: -- nosy: +facundobatista __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1822> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1823] Possible to set invalid Content-Transfer-Encoding on email.mime.multipart.MIMEMultipart
Jonathan Share added the comment: I'm beginning to realise this is slightly bigger than I first thought ;-) Trying to make a nice test case for this issue, I thought it would be a good idea for the parser to register a defect for invalid content- transfer-encoding so I can test against that in the test case rather than fragile substring tests. Unfortunately the parser code isn't the easiest code to get your head around on a first look. __ 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
[issue1823] Possible to set invalid Content-Transfer-Encoding on email.mime.multipart.MIMEMultipart
Jonathan Share added the comment: Run out of time to look at this today. In order to write a nice test case for this issue I need the parser to notice this error in messages. I've filed issue1874 for the parser not reporting the invalid cte in the msg.defects __ 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
[issue1874] email parser does not register a defect for invalid Content-Transfer-Encoding on multipart messages
New submission from Jonathan Share: Although the documentation of FeedParser states that "It will populate a message object's defects attribute with a list of any problems it found in a message." no defect is found in the test case I am about to upload. The message in the test case is broken because it specifies a Content-Transfer-Encoding that is not valid for multipart/* messages[1]. I've spent some time today looking at the parser and cannot see where the parser is doing anything with the Content-Transfer-Encoding of a multipart message, leading me to believe that there might be another bug here with regards to not honoring Content-Transfer-Encoding at all for multipart/* messages but I don't have any more time today to look at it, I'll have to go away and read the rfc really well. If someone can guide me on how to get this test to pass then I can probably get a good test case and fix written for issue1823 as well. [1] http://tools.ietf.org/html/rfc2045#section-6.4 -- components: Library (Lib) messages: 60207 nosy: Sharebear, barry severity: normal status: open title: email parser does not register a defect for invalid Content-Transfer-Encoding on multipart messages type: behavior versions: Python 2.5, Python 2.6, Python 3.0 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1874> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1874] email parser does not register a defect for invalid Content-Transfer-Encoding on multipart messages
Changes by Jonathan Share: Added file: http://bugs.python.org/file9227/issue1874.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1874> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
