diff options
| author | Petr Viktorin <encukou@gmail.com> | 2024-08-06 17:07:19 (GMT) |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2024-08-06 17:07:19 (GMT) |
| commit | 4766d1200fdf8b6728137aa2927a297e224d5fa7 (patch) | |
| tree | d33e20829d88f473731bb6d612e35383618ccf83 /Python/pythonrun.c | |
| parent | 01db0e404de0226f106dc674981f31a6df9c19bf (diff) | |
| download | cpython-4766d1200fdf8b6728137aa2927a297e224d5fa7.zip cpython-4766d1200fdf8b6728137aa2927a297e224d5fa7.tar.gz cpython-4766d1200fdf8b6728137aa2927a297e224d5fa7.tar.bz2 | |
[3.12] gh-121650: Encode newlines in headers, and verify headers are sound (GH-122233) (#122599)
* 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>
(cherry picked from commit 097633981879b3c9de9a1dd120d3aa585ecc2384)
* Document changes as made in 3.12.5
Diffstat (limited to 'Python/pythonrun.c')
0 files changed, 0 insertions, 0 deletions
