Issue 1443866: email 3.0+ stops parsing headers prematurely (original) (raw)
given the following input:
Received: by main.example.com; Sun Nov 4 02:45:50 2001 X-From_: postmaster@example.com Sun Nov 4 02:45:50 2001
From bob Sun Nov 4 02:45:50 2001 Return-Path: <postmaster@example.com> Delivered-To: bob@example.com
followed by more headers and message body, the email 3.0+ parser parses everything beginning with the
From bob Sun Nov 4 02:45:50 2001
line as the body of the message with only the first two lines as the header. RFC 2822 is clear that the message headers are separated from the body by an empty line, so I think the parser should continue parsing everything as headers until an empty line or the end of input is encountered, and should consider lines such as
From bob Sun Nov 4 02:45:50 2001
or
Some arbitrary text
encountered in the headers to be MalformedHeaderDefect. A complete example message is atteched.
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.)