[FIX] base: prevent Subject header folding to avoid strict mail server rejections#243119
[FIX] base: prevent Subject header folding to avoid strict mail server rejections#243119Ricardoalso wants to merge 1 commit intoodoo:18.0from
Conversation
|
|
…r rejections Yahoo and other strict mail servers reject emails with folded Subject headers containing RFC 2047 encoded-words when the folding occurs at inappropriate positions, resulting in "554 Invalid Subject header" errors. This commit extends the existing IdentificationFieldsNoFoldPolicy to also prevent Subject header folding, keeping long subjects on a single line (up to 998 characters per RFC 5322 MUST requirement). The solution follows the same pattern already established for identification headers (Message-ID, In-Reply-To, References) where Odoo prevents folding to avoid MTAs rewriting these critical headers and breaking email threading.
d37e88f to
92a9fe0
Compare
guewen
left a comment
There was a problem hiding this comment.
I confirm yahoo rejects emails under these conditions, thanks @Ricardoalso for the correction
Julien00859
left a comment
There was a problem hiding this comment.
If Yahoo rejects valid emails generated by the standard library of Python, then the problem is on Yahoo's side. Did you try and reach for their own support team?
Don't get me wrong, I hate folding, but I am highly confident that "Subject" of all headers must be folded. I'm pretty sure other "strict" email services are gonna reject our emails if we don't fold the subject.
Also, no test, no merge. I wanna see how the system behave with a long ASCII subject, and another with a long unicode subject (e.g. the french one you got). If we are to merge this one I wanna make sure the unicode one if base64 or %-encoded.
|
Since we have this problem in production, I'd like to add some context.
Actually, Yahoo is the strict one here. They do respect the RFC, whereas other email providers are more lax. Here is a real email subjet that is rejected by yahoo once encoded The bounce message is The raw header is With a slight different number of chars The raw header is the following and is valid Let's look at what happens in the first, invalid, header. Okay, so now let's take a look at https://www.rfc-editor.org/rfc/rfc2047
Where encoded-word is defined as
The encoded words in the header is then actually invalid because it lacks the "linear-white-space", and yahoo's parser respects strictly the RFC. I suppose other parsers are more flexible, but we cannot really blame yahoo on this one, at least we can't really report this to their support. This is actually a bug in the Python's Now regarding
Of course I can't be sure, but I'm not that pessimist about this, because the RFC 5322 (https://datatracker.ietf.org/doc/html/rfc5322#section-2.1.1) states
According to this, I see no reason why they would reject a unfolded subject that is less than 998 chars (or 1000 including the final It is worth noting that the line length section of RFC 5322 that I quoted above applies on all headers, and the implementation in odoo already disables the folding for "message-id", "in-reply-to", "references", "resent-msg-id". I tend to think that if the email parsers in the wild accept these unfolded headers, there is quite a chance they'd accept the subject as well. Of course, the bug should be fixed in Python's standard lib (still looking if I find a matching issue or if I should create one). But then, not sure this is going to be corrected soon and patched in all Python versions, so it may be a workaround to remove folding. Let me know if this is something you may consider or not (if it is worth spending time to write the tests). I would understand if you prefer not to apply the patch as there is no guarantee regarding the compliance of emails servers. Still, I find useful to document what I found in case others experiment the same issues. |
|
Python issue: python/cpython#144156 |
|
For information, we removed the folding of the subject after successful tests on the main email services, running on our production server with success so far. |
Indeed I see that, thanks for the exact subject line!
Thank for that!
Actually we could, but just to let them know that emails generated by Python's stdlib are tripping on their validator, with a reference to the Python issue (and maybe this one). We gotta get a higher chance to fix the root issue in Python if many players are complaining about it.
Nice catch, it is not the first time we spot errors in python's email module. Do you know if previous python versions are impacted as well? |
|
@Abridbus @tde-banana-odoo @beledouxdenis I'm done with Python's shitty folding crap, last time we reported a bug (and filled a PR to fix it) we had to wait several years before it got fixed, with no backport. The RFC states "SHOULD be bellow 78, MUST be bellow 998". Here @guewen tested various big email providers, they all seem to accept long (shorter than 998) header. Let's just change the max header length to 998, in master, and merge this PR. What's do you think? |
|
To me I do not believe this is a bad idea, though I have the same reserve as you: Maybe some provider / implementation would reject longer subjects. Rather than discussing this for months, maybe we can proceed in steps, we first merge this in 19.1 to test the patch on a smaller set of databases, to impact less customers in case there is an issue. if no issue after 2 weeks / a month we proceed with the backport in 18 and previous stable releases. We can maybe take the opportunity to also add the
as that last PR in cpython was not (yet?) backported in the python packages of Debian / Ubuntu. For information: from email.message import EmailMessage
from email.policy import SMTP
m = EmailMessage(SMTP.clone(max_line_length=40))
m['reply-to'] = '"Exfiltrator <spy@example.org> (unclosed comment?" <to@example.com>'
print(m.as_string())In Ubuntu 24.04, with Python 3.12.3, the above outputs While with Python 3.12.12 (e.g. Notice the double quotes difference. To me, I do not really care if it's the |
I just tested on version 3.7 and up, interestingly, it was ok (at least this particular issue) in version 3.7.x to 3.11.x, started misbehaving in 3.12.x. That being said, maybe it was broken in an other way. Details here: python/cpython#144156 (comment) Some news from our production: we have 12.5k customer service emails sent to our customers on a great range of mailboxes (still with a geographical bias) with the patch and no rejection. |
…r rejections Yahoo and other strict mail servers reject emails with folded Subject headers containing RFC 2047 encoded-words when the folding occurs at inappropriate positions, resulting in "554 Invalid Subject header" errors. The root cause is in Python's stdlib (bpo-144156). In an ideal world we would be fixing the issue there, but experience tells us that they are very slow to fix bugs / merge PRs in the email module, and even when they do they usually don't backport the fixes in the python versions we use. This commit extends the existing IdentificationFieldsNoFoldPolicy to also prevent Subject header folding, keeping long subjects on a single line (up to 998 characters per RFC 5322 "MUST" requirement, from the 98 "SHOULD" limit). Since at it, include the other "user defined" smtp headers: to, from, ... The solution follows the same pattern already established for identification headers (Message-ID, In-Reply-To, References) where Odoo prevents folding to avoid MTAs rewriting these critical headers and breaking email threading. Co-authored-by: Julien Castiaux <juc@odoo.com> See-also: odoo#243119
…r rejections Yahoo and other strict mail servers reject emails with folded Subject headers containing RFC 2047 encoded-words when the folding occurs at inappropriate positions, resulting in "554 Invalid Subject header" errors. The root cause is in Python's stdlib (bpo-144156). In an ideal world we would be fixing the issue there, but experience tells us that they are very slow to fix bugs / merge PRs in the email module, and even when they do they usually don't backport the fixes in the python versions we use. This commit extends the existing IdentificationFieldsNoFoldPolicy to also prevent Subject header folding, keeping long subjects on a single line (up to 998 characters per RFC 5322 "MUST" requirement, from the 98 "SHOULD" limit). Since at it, include the other "user defined" smtp headers: to, from, ... The solution follows the same pattern already established for identification headers (Message-ID, In-Reply-To, References) where Odoo prevents folding to avoid MTAs rewriting these critical headers and breaking email threading. closes #247057 See-also: #243119 Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com> Co-authored-by: Julien Castiaux <juc@odoo.com>
…r rejections Yahoo and other strict mail servers reject emails with folded Subject headers containing RFC 2047 encoded-words when the folding occurs at inappropriate positions, resulting in "554 Invalid Subject header" errors. The root cause is in Python's stdlib (bpo-144156). In an ideal world we would be fixing the issue there, but experience tells us that they are very slow to fix bugs / merge PRs in the email module, and even when they do they usually don't backport the fixes in the python versions we use. This commit extends the existing IdentificationFieldsNoFoldPolicy to also prevent Subject header folding, keeping long subjects on a single line (up to 998 characters per RFC 5322 "MUST" requirement, from the 98 "SHOULD" limit). Since at it, include the other "user defined" smtp headers: to, from, ... The solution follows the same pattern already established for identification headers (Message-ID, In-Reply-To, References) where Odoo prevents folding to avoid MTAs rewriting these critical headers and breaking email threading. See-also: odoo#243119 X-original-commit: 368fe4c Co-authored-by: Julien Castiaux <juc@odoo.com>
…r rejections Yahoo and other strict mail servers reject emails with folded Subject headers containing RFC 2047 encoded-words when the folding occurs at inappropriate positions, resulting in "554 Invalid Subject header" errors. The root cause is in Python's stdlib (bpo-144156). In an ideal world we would be fixing the issue there, but experience tells us that they are very slow to fix bugs / merge PRs in the email module, and even when they do they usually don't backport the fixes in the python versions we use. This commit extends the existing IdentificationFieldsNoFoldPolicy to also prevent Subject header folding, keeping long subjects on a single line (up to 998 characters per RFC 5322 "MUST" requirement, from the 98 "SHOULD" limit). Since at it, include the other "user defined" smtp headers: to, from, ... The solution follows the same pattern already established for identification headers (Message-ID, In-Reply-To, References) where Odoo prevents folding to avoid MTAs rewriting these critical headers and breaking email threading. See-also: odoo#243119 X-original-commit: 368fe4c Co-authored-by: Julien Castiaux <juc@odoo.com>
…r rejections Yahoo and other strict mail servers reject emails with folded Subject headers containing RFC 2047 encoded-words when the folding occurs at inappropriate positions, resulting in "554 Invalid Subject header" errors. The root cause is in Python's stdlib (bpo-144156). In an ideal world we would be fixing the issue there, but experience tells us that they are very slow to fix bugs / merge PRs in the email module, and even when they do they usually don't backport the fixes in the python versions we use. This commit extends the existing IdentificationFieldsNoFoldPolicy to also prevent Subject header folding, keeping long subjects on a single line (up to 998 characters per RFC 5322 "MUST" requirement, from the 98 "SHOULD" limit). Since at it, include the other "user defined" smtp headers: to, from, ... The solution follows the same pattern already established for identification headers (Message-ID, In-Reply-To, References) where Odoo prevents folding to avoid MTAs rewriting these critical headers and breaking email threading. closes #250388 See-also: #243119 X-original-commit: 368fe4c Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com> Co-authored-by: Julien Castiaux <juc@odoo.com>
|
Hello @Ricardoalso @guewen, I see that both our PR that changed the folding limit to 1k and the PR in cpython fixing the underlying issues have been merged. Thank you both for your thorough investigation and for testing the patch on your own infrastructure! I am now closing this PR, thanks! |
|
Wow, thanks! |
…r rejections Yahoo and other strict mail servers reject emails with folded Subject headers containing RFC 2047 encoded-words when the folding occurs at inappropriate positions, resulting in "554 Invalid Subject header" errors. The root cause is in Python's stdlib (bpo-144156). In an ideal world we would be fixing the issue there, but experience tells us that they are very slow to fix bugs / merge PRs in the email module, and even when they do they usually don't backport the fixes in the python versions we use. This commit extends the existing IdentificationFieldsNoFoldPolicy to also prevent Subject header folding, keeping long subjects on a single line (up to 998 characters per RFC 5322 "MUST" requirement, from the 98 "SHOULD" limit). Since at it, include the other "user defined" smtp headers: to, from, ... The solution follows the same pattern already established for identification headers (Message-ID, In-Reply-To, References) where Odoo prevents folding to avoid MTAs rewriting these critical headers and breaking email threading. closes odoo#250388 See-also: odoo#243119 X-original-commit: 368fe4c Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com> Co-authored-by: Julien Castiaux <juc@odoo.com>
…r rejections Yahoo and other strict mail servers reject emails with folded Subject headers containing RFC 2047 encoded-words when the folding occurs at inappropriate positions, resulting in "554 Invalid Subject header" errors. The root cause is in Python's stdlib (bpo-144156). In an ideal world we would be fixing the issue there, but experience tells us that they are very slow to fix bugs / merge PRs in the email module, and even when they do they usually don't backport the fixes in the python versions we use. This commit extends the existing IdentificationFieldsNoFoldPolicy to also prevent Subject header folding, keeping long subjects on a single line (up to 998 characters per RFC 5322 "MUST" requirement, from the 98 "SHOULD" limit). Since at it, include the other "user defined" smtp headers: to, from, ... The solution follows the same pattern already established for identification headers (Message-ID, In-Reply-To, References) where Odoo prevents folding to avoid MTAs rewriting these critical headers and breaking email threading. closes odoo#250388 See-also: odoo#243119 X-original-commit: 368fe4c Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com> Co-authored-by: Julien Castiaux <juc@odoo.com>
…r rejections Yahoo and other strict mail servers reject emails with folded Subject headers containing RFC 2047 encoded-words when the folding occurs at inappropriate positions, resulting in "554 Invalid Subject header" errors. The root cause is in Python's stdlib (bpo-144156). In an ideal world we would be fixing the issue there, but experience tells us that they are very slow to fix bugs / merge PRs in the email module, and even when they do they usually don't backport the fixes in the python versions we use. This commit extends the existing IdentificationFieldsNoFoldPolicy to also prevent Subject header folding, keeping long subjects on a single line (up to 998 characters per RFC 5322 "MUST" requirement, from the 98 "SHOULD" limit). Since at it, include the other "user defined" smtp headers: to, from, ... The solution follows the same pattern already established for identification headers (Message-ID, In-Reply-To, References) where Odoo prevents folding to avoid MTAs rewriting these critical headers and breaking email threading. Co-authored-by: Julien Castiaux <juc@odoo.com> See-also: odoo#243119
…r rejections Yahoo and other strict mail servers reject emails with folded Subject headers containing RFC 2047 encoded-words when the folding occurs at inappropriate positions, resulting in "554 Invalid Subject header" errors. The root cause is in Python's stdlib (bpo-144156). In an ideal world we would be fixing the issue there, but experience tells us that they are very slow to fix bugs / merge PRs in the email module, and even when they do they usually don't backport the fixes in the python versions we use. This commit extends the existing IdentificationFieldsNoFoldPolicy to also prevent Subject header folding, keeping long subjects on a single line (up to 998 characters per RFC 5322 "MUST" requirement, from the 98 "SHOULD" limit). Since at it, include the other "user defined" smtp headers: to, from, ... The solution follows the same pattern already established for identification headers (Message-ID, In-Reply-To, References) where Odoo prevents folding to avoid MTAs rewriting these critical headers and breaking email threading. closes odoo#250388 See-also: odoo#243119 X-original-commit: 368fe4c Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com> Co-authored-by: Julien Castiaux <juc@odoo.com>
…r rejections Yahoo and other strict mail servers reject emails with folded Subject headers containing RFC 2047 encoded-words when the folding occurs at inappropriate positions, resulting in "554 Invalid Subject header" errors. The root cause is in Python's stdlib (bpo-144156). In an ideal world we would be fixing the issue there, but experience tells us that they are very slow to fix bugs / merge PRs in the email module, and even when they do they usually don't backport the fixes in the python versions we use. This commit extends the existing IdentificationFieldsNoFoldPolicy to also prevent Subject header folding, keeping long subjects on a single line (up to 998 characters per RFC 5322 "MUST" requirement, from the 98 "SHOULD" limit). Since at it, include the other "user defined" smtp headers: to, from, ... The solution follows the same pattern already established for identification headers (Message-ID, In-Reply-To, References) where Odoo prevents folding to avoid MTAs rewriting these critical headers and breaking email threading. closes odoo#250388 See-also: odoo#243119 X-original-commit: 368fe4c Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com> Co-authored-by: Julien Castiaux <juc@odoo.com>
…r rejections Yahoo and other strict mail servers reject emails with folded Subject headers containing RFC 2047 encoded-words when the folding occurs at inappropriate positions, resulting in "554 Invalid Subject header" errors. The root cause is in Python's stdlib (bpo-144156). In an ideal world we would be fixing the issue there, but experience tells us that they are very slow to fix bugs / merge PRs in the email module, and even when they do they usually don't backport the fixes in the python versions we use. This commit extends the existing IdentificationFieldsNoFoldPolicy to also prevent Subject header folding, keeping long subjects on a single line (up to 998 characters per RFC 5322 "MUST" requirement, from the 98 "SHOULD" limit). Since at it, include the other "user defined" smtp headers: to, from, ... The solution follows the same pattern already established for identification headers (Message-ID, In-Reply-To, References) where Odoo prevents folding to avoid MTAs rewriting these critical headers and breaking email threading. closes odoo#250388 See-also: odoo#243119 Backport: odoo#247057
…r rejections Yahoo and other strict mail servers reject emails with folded Subject headers containing RFC 2047 encoded-words when the folding occurs at inappropriate positions, resulting in "554 Invalid Subject header" errors. The root cause is in Python's stdlib (bpo-144156). In an ideal world we would be fixing the issue there, but experience tells us that they are very slow to fix bugs / merge PRs in the email module, and even when they do they usually don't backport the fixes in the python versions we use. This commit extends the existing IdentificationFieldsNoFoldPolicy to also prevent Subject header folding, keeping long subjects on a single line (up to 998 characters per RFC 5322 "MUST" requirement, from the 98 "SHOULD" limit). Since at it, include the other "user defined" smtp headers: to, from, ... The solution follows the same pattern already established for identification headers (Message-ID, In-Reply-To, References) where Odoo prevents folding to avoid MTAs rewriting these critical headers and breaking email threading. closes #250388 closes #254670 See-also: #243119 Backport: #247057 Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
…r rejections Yahoo and other strict mail servers reject emails with folded Subject headers containing RFC 2047 encoded-words when the folding occurs at inappropriate positions, resulting in "554 Invalid Subject header" errors. The root cause is in Python's stdlib (bpo-144156). In an ideal world we would be fixing the issue there, but experience tells us that they are very slow to fix bugs / merge PRs in the email module, and even when they do they usually don't backport the fixes in the python versions we use. This commit extends the existing IdentificationFieldsNoFoldPolicy to also prevent Subject header folding, keeping long subjects on a single line (up to 998 characters per RFC 5322 "MUST" requirement, from the 98 "SHOULD" limit). Since at it, include the other "user defined" smtp headers: to, from, ... The solution follows the same pattern already established for identification headers (Message-ID, In-Reply-To, References) where Odoo prevents folding to avoid MTAs rewriting these critical headers and breaking email threading. closes odoo#250388 See-also: odoo#243119 Backport: odoo#247057 X-original-commit: cf98058
…r rejections Yahoo and other strict mail servers reject emails with folded Subject headers containing RFC 2047 encoded-words when the folding occurs at inappropriate positions, resulting in "554 Invalid Subject header" errors. The root cause is in Python's stdlib (bpo-144156). In an ideal world we would be fixing the issue there, but experience tells us that they are very slow to fix bugs / merge PRs in the email module, and even when they do they usually don't backport the fixes in the python versions we use. This commit extends the existing IdentificationFieldsNoFoldPolicy to also prevent Subject header folding, keeping long subjects on a single line (up to 998 characters per RFC 5322 "MUST" requirement, from the 98 "SHOULD" limit). Since at it, include the other "user defined" smtp headers: to, from, ... The solution follows the same pattern already established for identification headers (Message-ID, In-Reply-To, References) where Odoo prevents folding to avoid MTAs rewriting these critical headers and breaking email threading. closes odoo#250388 See-also: odoo#243119 Backport: odoo#247057 X-original-commit: cf98058
…r rejections Yahoo and other strict mail servers reject emails with folded Subject headers containing RFC 2047 encoded-words when the folding occurs at inappropriate positions, resulting in "554 Invalid Subject header" errors. The root cause is in Python's stdlib (bpo-144156). In an ideal world we would be fixing the issue there, but experience tells us that they are very slow to fix bugs / merge PRs in the email module, and even when they do they usually don't backport the fixes in the python versions we use. This commit extends the existing IdentificationFieldsNoFoldPolicy to also prevent Subject header folding, keeping long subjects on a single line (up to 998 characters per RFC 5322 "MUST" requirement, from the 98 "SHOULD" limit). Since at it, include the other "user defined" smtp headers: to, from, ... The solution follows the same pattern already established for identification headers (Message-ID, In-Reply-To, References) where Odoo prevents folding to avoid MTAs rewriting these critical headers and breaking email threading. closes odoo#250388 See-also: odoo#243119 Backport: odoo#247057 X-original-commit: cf98058
…r rejections Yahoo and other strict mail servers reject emails with folded Subject headers containing RFC 2047 encoded-words when the folding occurs at inappropriate positions, resulting in "554 Invalid Subject header" errors. The root cause is in Python's stdlib (bpo-144156). In an ideal world we would be fixing the issue there, but experience tells us that they are very slow to fix bugs / merge PRs in the email module, and even when they do they usually don't backport the fixes in the python versions we use. This commit extends the existing IdentificationFieldsNoFoldPolicy to also prevent Subject header folding, keeping long subjects on a single line (up to 998 characters per RFC 5322 "MUST" requirement, from the 98 "SHOULD" limit). Since at it, include the other "user defined" smtp headers: to, from, ... The solution follows the same pattern already established for identification headers (Message-ID, In-Reply-To, References) where Odoo prevents folding to avoid MTAs rewriting these critical headers and breaking email threading. closes odoo#250388 See-also: odoo#243119 Backport: odoo#247057 X-original-commit: cf98058
…r rejections Yahoo and other strict mail servers reject emails with folded Subject headers containing RFC 2047 encoded-words when the folding occurs at inappropriate positions, resulting in "554 Invalid Subject header" errors. The root cause is in Python's stdlib (bpo-144156). In an ideal world we would be fixing the issue there, but experience tells us that they are very slow to fix bugs / merge PRs in the email module, and even when they do they usually don't backport the fixes in the python versions we use. This commit extends the existing IdentificationFieldsNoFoldPolicy to also prevent Subject header folding, keeping long subjects on a single line (up to 998 characters per RFC 5322 "MUST" requirement, from the 98 "SHOULD" limit). Since at it, include the other "user defined" smtp headers: to, from, ... The solution follows the same pattern already established for identification headers (Message-ID, In-Reply-To, References) where Odoo prevents folding to avoid MTAs rewriting these critical headers and breaking email threading. closes odoo#250388 See-also: odoo#243119 Backport: odoo#247057 X-original-commit: cf98058
…r rejections Yahoo and other strict mail servers reject emails with folded Subject headers containing RFC 2047 encoded-words when the folding occurs at inappropriate positions, resulting in "554 Invalid Subject header" errors. The root cause is in Python's stdlib (bpo-144156). In an ideal world we would be fixing the issue there, but experience tells us that they are very slow to fix bugs / merge PRs in the email module, and even when they do they usually don't backport the fixes in the python versions we use. This commit extends the existing IdentificationFieldsNoFoldPolicy to also prevent Subject header folding, keeping long subjects on a single line (up to 998 characters per RFC 5322 "MUST" requirement, from the 98 "SHOULD" limit). Since at it, include the other "user defined" smtp headers: to, from, ... The solution follows the same pattern already established for identification headers (Message-ID, In-Reply-To, References) where Odoo prevents folding to avoid MTAs rewriting these critical headers and breaking email threading. closes #250388 closes #255383 See-also: #243119 Backport: #247057 X-original-commit: cf98058 Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
…r rejections Yahoo and other strict mail servers reject emails with folded Subject headers containing RFC 2047 encoded-words when the folding occurs at inappropriate positions, resulting in "554 Invalid Subject header" errors. The root cause is in Python's stdlib (bpo-144156). In an ideal world we would be fixing the issue there, but experience tells us that they are very slow to fix bugs / merge PRs in the email module, and even when they do they usually don't backport the fixes in the python versions we use. This commit extends the existing IdentificationFieldsNoFoldPolicy to also prevent Subject header folding, keeping long subjects on a single line (up to 998 characters per RFC 5322 "MUST" requirement, from the 98 "SHOULD" limit). Since at it, include the other "user defined" smtp headers: to, from, ... The solution follows the same pattern already established for identification headers (Message-ID, In-Reply-To, References) where Odoo prevents folding to avoid MTAs rewriting these critical headers and breaking email threading. closes #250388 closes #255302 See-also: #243119 Backport: #247057 X-original-commit: cf98058 Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
…r rejections Yahoo and other strict mail servers reject emails with folded Subject headers containing RFC 2047 encoded-words when the folding occurs at inappropriate positions, resulting in "554 Invalid Subject header" errors. The root cause is in Python's stdlib (bpo-144156). In an ideal world we would be fixing the issue there, but experience tells us that they are very slow to fix bugs / merge PRs in the email module, and even when they do they usually don't backport the fixes in the python versions we use. This commit extends the existing IdentificationFieldsNoFoldPolicy to also prevent Subject header folding, keeping long subjects on a single line (up to 998 characters per RFC 5322 "MUST" requirement, from the 98 "SHOULD" limit). Since at it, include the other "user defined" smtp headers: to, from, ... The solution follows the same pattern already established for identification headers (Message-ID, In-Reply-To, References) where Odoo prevents folding to avoid MTAs rewriting these critical headers and breaking email threading. closes #250388 closes #255425 See-also: #243119 Backport: #247057 X-original-commit: cf98058 Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
…r rejections Yahoo and other strict mail servers reject emails with folded Subject headers containing RFC 2047 encoded-words when the folding occurs at inappropriate positions, resulting in "554 Invalid Subject header" errors. The root cause is in Python's stdlib (bpo-144156). In an ideal world we would be fixing the issue there, but experience tells us that they are very slow to fix bugs / merge PRs in the email module, and even when they do they usually don't backport the fixes in the python versions we use. This commit extends the existing IdentificationFieldsNoFoldPolicy to also prevent Subject header folding, keeping long subjects on a single line (up to 998 characters per RFC 5322 "MUST" requirement, from the 98 "SHOULD" limit). Since at it, include the other "user defined" smtp headers: to, from, ... The solution follows the same pattern already established for identification headers (Message-ID, In-Reply-To, References) where Odoo prevents folding to avoid MTAs rewriting these critical headers and breaking email threading. closes #250388 closes #255413 See-also: #243119 Backport: #247057 X-original-commit: cf98058 Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
…r rejections Yahoo and other strict mail servers reject emails with folded Subject headers containing RFC 2047 encoded-words when the folding occurs at inappropriate positions, resulting in "554 Invalid Subject header" errors. The root cause is in Python's stdlib (bpo-144156). In an ideal world we would be fixing the issue there, but experience tells us that they are very slow to fix bugs / merge PRs in the email module, and even when they do they usually don't backport the fixes in the python versions we use. This commit extends the existing IdentificationFieldsNoFoldPolicy to also prevent Subject header folding, keeping long subjects on a single line (up to 998 characters per RFC 5322 "MUST" requirement, from the 98 "SHOULD" limit). Since at it, include the other "user defined" smtp headers: to, from, ... The solution follows the same pattern already established for identification headers (Message-ID, In-Reply-To, References) where Odoo prevents folding to avoid MTAs rewriting these critical headers and breaking email threading. closes #250388 closes #255352 See-also: #243119 Backport: #247057 X-original-commit: cf98058 Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
…r rejections Yahoo and other strict mail servers reject emails with folded Subject headers containing RFC 2047 encoded-words when the folding occurs at inappropriate positions, resulting in "554 Invalid Subject header" errors. The root cause is in Python's stdlib (bpo-144156). In an ideal world we would be fixing the issue there, but experience tells us that they are very slow to fix bugs / merge PRs in the email module, and even when they do they usually don't backport the fixes in the python versions we use. This commit extends the existing IdentificationFieldsNoFoldPolicy to also prevent Subject header folding, keeping long subjects on a single line (up to 998 characters per RFC 5322 "MUST" requirement, from the 98 "SHOULD" limit). Since at it, include the other "user defined" smtp headers: to, from, ... The solution follows the same pattern already established for identification headers (Message-ID, In-Reply-To, References) where Odoo prevents folding to avoid MTAs rewriting these critical headers and breaking email threading. closes #250388 closes #255352 See-also: #243119 Backport: #247057 X-original-commit: cf98058 Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
…r rejections Yahoo and other strict mail servers reject emails with folded Subject headers containing RFC 2047 encoded-words when the folding occurs at inappropriate positions, resulting in "554 Invalid Subject header" errors. The root cause is in Python's stdlib (bpo-144156). In an ideal world we would be fixing the issue there, but experience tells us that they are very slow to fix bugs / merge PRs in the email module, and even when they do they usually don't backport the fixes in the python versions we use. This commit extends the existing IdentificationFieldsNoFoldPolicy to also prevent Subject header folding, keeping long subjects on a single line (up to 998 characters per RFC 5322 "MUST" requirement, from the 98 "SHOULD" limit). Since at it, include the other "user defined" smtp headers: to, from, ... The solution follows the same pattern already established for identification headers (Message-ID, In-Reply-To, References) where Odoo prevents folding to avoid MTAs rewriting these critical headers and breaking email threading. closes odoo#250388 closes odoo#255352 See-also: odoo#243119 Backport: odoo#247057 X-original-commit: cf98058 Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
…r rejections Yahoo and other strict mail servers reject emails with folded Subject headers containing RFC 2047 encoded-words when the folding occurs at inappropriate positions, resulting in "554 Invalid Subject header" errors. The root cause is in Python's stdlib (bpo-144156). In an ideal world we would be fixing the issue there, but experience tells us that they are very slow to fix bugs / merge PRs in the email module, and even when they do they usually don't backport the fixes in the python versions we use. This commit extends the existing IdentificationFieldsNoFoldPolicy to also prevent Subject header folding, keeping long subjects on a single line (up to 998 characters per RFC 5322 "MUST" requirement, from the 98 "SHOULD" limit). Since at it, include the other "user defined" smtp headers: to, from, ... The solution follows the same pattern already established for identification headers (Message-ID, In-Reply-To, References) where Odoo prevents folding to avoid MTAs rewriting these critical headers and breaking email threading. closes odoo#250388 closes odoo#255425 See-also: odoo#243119 Backport: odoo#247057 X-original-commit: cf98058 Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com> Co-authored-by: vvro <8414969+vvro@users.noreply.github.com>
Description of the issue/feature this PR addresses:
Yahoo and other strict mail servers reject emails with
554 Invalid Subject headerwhen Subject headers are folded at 78 characters and contain RFC 2047 encoded-words representing non-ASCII characters.The issue occurs because:
email.policy.SMTPfolds these headers at 78 characters per RFC 5322 SHOULD recommendationCurrent behavior before PR:
This subject:
While this is technically RFC 2822 compliant, Yahoo's strict validation rejects it.
Python's
email.policy.SMTPfolds headers at 78 characters to follow RFC 5322's SHOULD recommendation. However, when subjects contain non-ASCII characters that get RFC 2047 encoded, the folding can create patterns that strict mail servers reject.Desired behavior after PR is merged:
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr