[Python-bugs-list] [ python-Bugs-513683 ] email.Parser uses LF as line sep.

[noreply@sourceforge.net]

Bugs item #513683, was opened at 2002-02-06 01:35
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=513683&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Brian Takashi Hooper (bthooper)
Assigned to: Nobody/Anonymous (nobody)
Summary: email.Parser uses LF as line sep.

Initial Comment:
I'm not sure what the best solution is for this, but some email 
clients sent multipart MIME messages using CRLF as the line 
separator instead of just LF, which seems to be assumed in 
email.Parser.Parser._parsebody. Maybe I'm reading the RFC 
wrong, but it seems like it says that lines of a mail message should be 
separated using CRLF (although I'm sure many clients don't do that 
either)...


----------------------------------------------------------------------

>Comment By: Barry Warsaw (bwarsaw)
Date: 2002-02-06 04:32

Message:
Logged In: YES 
user_id=12800

My philosophy so far (and I *think* this is documented in
the latest rev of the .tex file), is that the email package
should deal with native line endings, and that it is the job
of a delivering mta to convert from rfc line endings (crlf)
to native.  It is certainly the case that smtplib converts
from native to rfc line endings when sending the message
out.  Most mtas (e.g. postfix) when piping the message to a
process or onto a file will convert to native line endings,
at least in my experience.

This may not be a very useful assumption though, and it is
probably more robust to be able to deal with either line
endings.  There have been some movements in this direction
in the cvs snapshot of the mimelib/email package where
support for multibyte charsets (e.g. Japanese) have been
added.  You might want to check out that project's cvs trunk
and see if it helps your situation, or submit a bug report
there and we'll prototype the fix in that project first. 
Eventually all that code will be ported back to the Python
2.3 tree.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=513683&group_id=5470