[issue1443866] email 3.0+ stops parsing headers prematurely

[R. David Murray]

R. David Murray <rdmurray at bitdance.com> added the comment:

It's not clear to me that this is a valid bug.  It is true that the RFC says that a blank line preceeds the body.  However, the line in question is not a valid header line.  Mail parsers trying to implement the "be liberal in what you accept" portion of Postel's law should parse messages that where the blank line between the headers and body is missing.  With the input given, there are three valid Postel interpretations: the body starts at the >From line, the >From line is missing a folding indent and is part of the value of the preceding header, and the >From line is garbage and should be discarded.

Since a leading >From is a token that occurs validly with reasonable frequency in message bodies and is never valid in message headers, I think the current choice is a sane one.  A smarter heuristic might look at the subsequent line and note that they look like headers, but headers can occur in the body of messages, so that heuristic would probably be wrong more often than it was right.  Especially considering that putting headers in a message body is the time when you are most likely to see the leading '>From ' token, since it would be quoting the mbox 'From ' header.

So, I'm closing this bug as rejected.  (Rejected rather than invalid, since reasonable people can certainly disagree about the best heuristics for handling invalid data.)

----------
resolution:  -> rejected
stage: unit test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1443866>
_______________________________________