diff options
author | Miss Islington (bot) <31488909+miss-islington@users.noreply.github.com> | 2020-05-18 00:57:42 (GMT) |
---|---|---|
committer | GitHub <noreply@github.com> | 2020-05-18 00:57:42 (GMT) |
commit | c1f1ddf30a595c2bfa3c06e54fb03fa212cd28b5 (patch) | |
tree | eaf147b7a9a36163917ece7bfbdefe50c9778d6c /Python/thread_pthread.h | |
parent | 7a3522d478d456b38ef5e647c21595904bea79df (diff) | |
download | cpython-c1f1ddf30a595c2bfa3c06e54fb03fa212cd28b5.zip cpython-c1f1ddf30a595c2bfa3c06e54fb03fa212cd28b5.tar.gz cpython-c1f1ddf30a595c2bfa3c06e54fb03fa212cd28b5.tar.bz2 |
bpo-40597: email: Use CTE if lines are longer than max_line_length consistently (gh-20038) (gh-20084)
raw_data_manager (default for EmailPolicy, EmailMessage)
does correct wrapping of 'text' parts as long as the message contains
characters outside of 7bit US-ASCII set: base64 or qp
Content-Transfer-Encoding is applied if the lines would be too long
without it. It did not, however, do this for ascii-only text,
which could result in lines that were longer than
policy.max_line_length or even the rfc 998 maximum.
This changeset fixes the heuristic so that if lines are longer than
policy.max_line_length, it will always apply a
content-transfer-encoding so that the lines are wrapped correctly.
(cherry picked from commit 6f2f475d5a2cd7675dce844f3af436ba919ef92b)
Co-authored-by: Arkadiusz Hiler <arek.l1@gmail.com>
Diffstat (limited to 'Python/thread_pthread.h')
0 files changed, 0 insertions, 0 deletions