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

Added check to conform RFC2045 (section 6.4) for Python 2.6

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

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).