[issue6153] email parsing - Rare Failure

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc amaur...@gmail.com added the comment:

This is a duplicate of issue170.

--
nosy: +amaury.forgeotdarc
resolution:  - duplicate
status: open - closed
superseder:  - email parser incorrectly breaks headers with a CRLF at 8192

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6153
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6153] email parsing - Rare Failure

[Antoine Pitrou]

Changes by Antoine Pitrou pit...@free.fr:


--
assignee:  - barry
nosy: +barry

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6153
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6153] email parsing - Rare Failure

[Winston Ewert]

New submission from Winston Ewert winstonew...@gmail.com:

I was using email.message_from_string which eventually feeds block of
8192 bytes into the actual e-mail parsing code. However, in my case one
the blocks split the \r\n at the end of a submessage. This caused the
code to identify it as two newlines and thus the submessage headers were
interpreted as being content.

For my purposes I've changed:
NLCRE_crack = re.compile('(\r\n|\r|\n)')
to
NLCRE_crack = re.compile('(\r\n)')

Which prevents the problem.

I suspect that is not a good fix but I do not know the standard well
enough to know what would be a good fix.

--
components: Library (Lib)
messages: 88593
nosy: WinstonEwert
severity: normal
status: open
title: email parsing - Rare Failure
type: behavior
versions: Python 2.6

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6153
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com