email.Parser uses LF as line sep.

[bthooper]

BPO	513683
Nosy	@warsaw

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/warsaw'
closed_at = <Date 2002-03-15.16:51:27.000>
created_at = <Date 2002-02-06.09:35:21.000>
labels = ['library']
title = 'email.Parser uses LF as line sep.'
updated_at = <Date 2002-03-15.16:51:27.000>
user = 'https://bugs.python.org/bthooper'

bugs.python.org fields:

activity = <Date 2002-03-15.16:51:27.000>
actor = 'barry'
assignee = 'barry'
closed = True
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2002-02-06.09:35:21.000>
creator = 'bthooper'
dependencies = []
files = []
hgrepos = []
issue_num = 513683
keywords = []
message_count = 4.0
messages = ['9148', '9149', '9150', '9151']
nosy_count = 2.0
nosy_names = ['barry', 'bthooper']
pr_nums = []
priority = 'normal'
resolution = 'wont fix'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue513683'
versions = ['Python 2.2']

[bthooper]

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

[warsaw]

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.

[bthooper]

Logged In: YES
user_id=450505

OK, that seems like a satisfactory answer.
I do actually happen to be
using Postfix on FreeBSD, albeit a little old (maybe a year or so), and am
piping mails to a Python script, which is where I observed this problem.
Maybe something with my local setup? (I didn't set up Postfix, but I don't
see why it wouldn't be doing the default thing)

Maybe it would be safer
not to make assumptions about the input message, and process line endings
to native before parsing? This would be my vote anyways (I tend to avoid
thoroughly reading documentation unless something doesn't work as I
intuit it should :-)

[warsaw]

Logged In: YES
user_id=12800

Closing this as Won't Fix because the email package's
philosophy is to process messages uses native line endings.
Any conversions to/from RFC line endings must happen
outside the package (e.g. by the delivering MTA, or by
smtplib for outgoing mail).