-
-
Notifications
You must be signed in to change notification settings - Fork 30k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
email 3.0+ stops parsing headers prematurely #42984
Comments
given the following input: Received: by main.example.com; Sun Nov 4 02:45:50 2001
followed by more headers and message body, the email
line as the body of the message with only the first two
or Some arbitrary text encountered in the headers to be MalformedHeaderDefect. |
The email module has several problems. RDM is working on overhauling the email module for 3.2. Existing issues may not get individual attention. |
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.) |
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:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: