As stated, the email.Parser class uses '\n' to add the 
firstbodyline to the rest of the message. This is done 
*AFTER* the splitlines() have been used to remove the 
first line from the body of a multipart message. 
 
Even though this is not a problem in many cases, it can 
be a great problem when you are dealing with signed 
files, as in my case. 
 
I've indeed a multipart message where I have: 
 
a pdf file 
 
a pkcs7 signature 
 
 
If I use the parser to analyze the message, the pdf file 
is actually one byte less, because the original file was 
\r\n terminated, rather than \n. When the parser tries 
to parse, it splits the first line (containing the 
%PDF1.4\r\n), and translates it to %PDF1.4, and then it 
is joined to the rest of the PDF file using a simple \n. In 
this way, the file is exactly one byte less of the original 
file, and, therefore, the signature can't be verified. 
 
I think we could avoid this problem using a  
 
splitlines(1)[0][:-1] 
 
which would keep the original \r\n, remove the \n, 
which can then be safely added. 

Logged In: YES 
user_id=12800

Doesn't this only happen if there is no separating blank
line between the headers and the body, as mandated by RFC
2822?  I'm not inclined to fix such problems because 1) it's
not standard compliant; 2) Python 2.4's parser is completely
rewritten so this analysis won't be relevant anymore.