-
-
Notifications
You must be signed in to change notification settings - Fork 31.7k
email.message.EmailMessage accepts invalid header field names without error, which raise an error when parsed #127794
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
Comments
@TauPan Are you working on it? Shall I work on it? |
I'd appreciate if you could work on it. Thanks! |
I am on it. Thanks. |
…ly printable ascii characters
As you observed, the missing header separator error is python's equivalent of the other email programs displaying the broken headers in the body: we register the defect and then start the body starting with the broken header, which is the correct behavior per the rfcs. feedparser uses its own regex which incorporates the one from the rfc but extends it for internal code reasons. The one in email.headers (old API) is probably a refactoring leftover. |
`email.message.Message` objects now validate header names specified via `__setitem__` or `add_header` according to RFC 5322, §2.2 [1]. In particular, callers should expect a ValueError to be raised for invalid header names. [1]: https://datatracker.ietf.org/doc/html/rfc5322#section-2.2 --------- Co-authored-by: Bénédikt Tran <[email protected]> Co-authored-by: R. David Murray <[email protected]>
🚀 🚀 @TauPan We have merged the PR into main. Thanks a lot to @bitdancer and @picnixz . Appreciate it. We can close this issue. |
Rationale for the non-backports: #127820 (comment). |
…ython#127820) `email.message.Message` objects now validate header names specified via `__setitem__` or `add_header` according to RFC 5322, §2.2 [1]. In particular, callers should expect a ValueError to be raised for invalid header names. [1]: https://datatracker.ietf.org/doc/html/rfc5322#section-2.2 --------- Co-authored-by: Bénédikt Tran <[email protected]> Co-authored-by: R. David Murray <[email protected]>
Bug report
Bug description:
email.message.EmailMessage
accepts invalid header field names without error, which raise an error when parsed, regardless of policy and causes corrupt emails.Case in point (with python 3.13.1 installed via pyenv, occurs in 3.11
and earlier as well):
The illegal header field name is accepted by EmailMessage without a defect, but when the resulting message is parsed, regardless of policy, it looks to me like header parsing stops at that point and the line with the defect header is viewed as first line of the body, which leads to the
MissingHeaderBodySeparatorDefect
.It's interesting that
email.headers
contains the following:which is the correct regex according to the rfc, including the final colon, which apparently isn't used anywhere in the code.
A MUA (such as claws or mutt) will display the resulting email with the remaining headers as part of the body, breaking any mime multipart rendering.
CPython versions tested on:
3.11, 3.13
Operating systems tested on:
Linux
Linked PRs
The text was updated successfully, but these errors were encountered: