summaryrefslogtreecommitdiff
path: root/odoo/addons/test_new_api/security/ir.model.access.csv
diff options
context:
space:
mode:
authorJulien Castiaux <juc@odoo.com>2019-10-29 13:41:04 +0000
committerOlivier Dony <odo@odoo.com>2019-11-14 12:29:36 +0000
commit7bf2dd43393be3758b3d8d6eeb94c877517c1bcf (patch)
treed2d755d514aa93acf06e515fe5e648605d1dda93 /odoo/addons/test_new_api/security/ir.model.access.csv
parent7b65a63c97d185d9b6e6f1b0bfbc7968d1e4de49 (diff)
[FIX] ir.mail.server: squash redundant CRs (bpo-34424)
Problem description: Using the chatter, send an email to someone having non-ascii characters in their name: the body of the received email looks like it contains a mix of the original body and headers. Python encodes the name into either base64 or quoted-printable but leaves some redundant carriage returns at the end of the header. Those redundant carriage returns are not RFC conformant but are interpreted as newlines by some email clients, thus are read like a headers/body separator and the next headers are considered part of the body, corrupting the email structure. This problem is internal to Python and has been fixed in 3.8, cfr bpo-34424 [1], and later backported to 3.7.4. As we also support 3.6 and earlier 3.7 and it is not possible to easily monkey-patch the function, we fixed it by squashing duplicate carriage returns. (There is no case where a series of bare CRs can occur in a normal RFC5322 email message) Task: 2003936 [1]: https://bugs.python.org/issue34424
Diffstat (limited to 'odoo/addons/test_new_api/security/ir.model.access.csv')
0 files changed, 0 insertions, 0 deletions