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.

classification
Title: email parser does not register a defect for invalid Content-Transfer-Encoding on multipart messages
Type: enhancement Stage: resolved
Components: Library (Lib) Versions: Python 3.3
process
Status: closed Resolution: accepted
Dependencies: Superseder:
Assigned To: Nosy List: Sharebear, barry, python-dev, r.david.murray, seocam, vinibaggio
Priority: normal Keywords: easy, patch

Created on 2008-01-19 18:37 by Sharebear, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
issue1874.patch Sharebear, 2008-01-19 18:38 Failing test case, diff against trunk r60086
issue1874-fixed-2.6.patch seocam, 2008-05-11 00:57 Patch including the fix and the test case submitter as issue1874.patch review
Messages (4)
msg60207 - (view) Author: Jonathan Share (Sharebear) Date: 2008-01-19 18:37
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
msg66594 - (view) Author: Sergio Oliveira Campos (seocam) Date: 2008-05-11 00:57
Added check to conform RFC2045 (section 6.4) for Python 2.6
msg138826 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2011-06-22 17:48
New changeset 5a2602939d5d by R David Murray in branch 'default':
#1874: detect invalid multipart CTE and report it as a defect.
http://hg.python.org/cpython/rev/5a2602939d5d
msg138827 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2011-06-22 17:53
Thanks for the patches.  I didn't use them, but they were helpful references.

This is in a grey area between a bug and a feature request.  The fact is, though, that for the most part the email module currently doesn't make extra effort to detect defects, it just reports the ones it has to work around.  The only exception I found to this was taking an extra step to report a defect that represented a defect in the constructed model of the message.

Now, in the next version of email (targeted for 3.3), one of the design goals is to detect as many RFC conformance defects as practical.  So, I'm treating this as a feature request, and have checked it in to 3.3 (default).
History
Date User Action Args
2022-04-11 14:56:29adminsetgithub: 46182
2011-06-22 17:53:18r.david.murraysetstatus: open -> closed
versions: + Python 3.3, - Python 3.1, Python 2.7, Python 3.2
type: behavior -> enhancement
messages: + msg138827

resolution: accepted
stage: resolved
2011-06-22 17:48:28python-devsetnosy: + python-dev
messages: + msg138826
2010-09-20 07:52:11BreamoreBoysetnosy: + r.david.murray

versions: - Python 2.6
2010-06-09 22:15:03terry.reedysetversions: + Python 3.1, Python 2.7, Python 3.2, - Python 2.5, Python 3.0
2008-05-11 01:06:09vinibaggiosetnosy: + vinibaggio
2008-05-11 00:57:57seocamsetfiles: + issue1874-fixed-2.6.patch
nosy: + seocam
messages: + msg66594
2008-01-20 20:03:36christian.heimessetpriority: normal
keywords: + patch, easy
2008-01-19 18:38:16Sharebearsetfiles: + issue1874.patch
2008-01-19 18:37:20Sharebearcreate