diff options
author | Petr Viktorin <encukou@gmail.com> | 2024-07-31 00:19:48 +0200 |
---|---|---|
committer | GitHub <noreply@github.com> | 2024-07-31 00:19:48 +0200 |
commit | 097633981879b3c9de9a1dd120d3aa585ecc2384 (patch) | |
tree | bd7d04f28e53f8df28dd57213e09619cc1666b9d /Lib/email/errors.py | |
parent | 5912487938ac4b517209082ab9e6d2d3d0fb4f4d (diff) | |
download | cpython-097633981879b3c9de9a1dd120d3aa585ecc2384.tar.gz cpython-097633981879b3c9de9a1dd120d3aa585ecc2384.zip |
gh-121650: Encode newlines in headers, and verify headers are sound (GH-122233)
## Encode header parts that contain newlines
Per RFC 2047:
> [...] these encoding schemes allow the
> encoding of arbitrary octet values, mail readers that implement this
> decoding should also ensure that display of the decoded data on the
> recipient's terminal will not cause unwanted side-effects
It seems that the "quoted-word" scheme is a valid way to include
a newline character in a header value, just like we already allow
undecodable bytes or control characters.
They do need to be properly quoted when serialized to text, though.
## Verify that email headers are well-formed
This should fail for custom fold() implementations that aren't careful
about newlines.
Co-authored-by: Bas Bloemsaat <bas@bloemsaat.org>
Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
Diffstat (limited to 'Lib/email/errors.py')
-rw-r--r-- | Lib/email/errors.py | 4 |
1 files changed, 4 insertions, 0 deletions
diff --git a/Lib/email/errors.py b/Lib/email/errors.py index 3ad00565549..02aa5eced6a 100644 --- a/Lib/email/errors.py +++ b/Lib/email/errors.py @@ -29,6 +29,10 @@ class CharsetError(MessageError): """An illegal charset was given.""" +class HeaderWriteError(MessageError): + """Error while writing headers.""" + + # These are parsing defects which the parser was able to work around. class MessageDefect(ValueError): """Base class for a message defect.""" |