[issue41599] get/set_payload deprecated, but get_set_content do not provide full replacement functionality
New submission from Erik Quaeghebeur : >From Python 3.6 onwards, get/set_payload methods are deprecated on the basic >email message class, email.message.EmailMessage (changed from >email.message.Message). The get/set_content methods are suggested instead. >However, with get/set_payload one can ‘transplant’ whole MIME subtrees, while >get/set_content cannot deal with multipart parts. I would like to suggest to not remove get/set_payload until its functionality is present in other methods. Perhaps they should even be un-deprecated. -- components: email messages: 375696 nosy: barry, equaeghe, r.david.murray priority: normal severity: normal status: open title: get/set_payload deprecated, but get_set_content do not provide full replacement functionality type: behavior versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue41599> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41585] policy.max_line_length is incorrectly assumed to never be None
Erik Quaeghebeur added the comment: The script that triggered the issue can be found at https://github.com/equaeghe/mailfilters/blob/master/html2alternative.py You'll have to remove ", cte='8bit'" on line 68 to expose the bug (that was added as a workaround for this bug). I was consistently able to trigger the bug when applying it to a mail with a multipart/alternative with text and html parts already present. It should replace that html part by a (nested) multipart/alternative part, but it crashes unless you keep the workaround. -- ___ Python tracker <https://bugs.python.org/issue41585> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41585] policy.max_line_length is incorrectly assumed to never be None
New submission from Erik Quaeghebeur :
I got the following error (Python 3.7.8):
Traceback (most recent call last):
File "/home/equaeghe/.local/bin/html2alternative.py", line 68, in
replaceable.add_alternative(plain)
File "/usr/lib/python3.7/email/message.py", line 1153, in add_alternative
self._add_multipart('alternative', *args, **kw)
File "/usr/lib/python3.7/email/message.py", line 1144, in _add_multipart
part.set_content(*args, **kw)
File "/usr/lib/python3.7/email/message.py", line 1171, in set_content
super().set_content(*args, **kw)
File "/usr/lib/python3.7/email/message.py", line 1101, in set_content
content_manager.set_content(self, *args, **kw)
File "/usr/lib/python3.7/email/contentmanager.py", line 37, in set_content
handler(msg, obj, *args, **kw)
File "/usr/lib/python3.7/email/contentmanager.py", line 185, in
set_text_content
cte, payload = _encode_text(string, charset, cte, msg.policy)
File "/usr/lib/python3.7/email/contentmanager.py", line 154, in _encode_text
max(len(x) for x in lines) <= policy.max_line_length):
TypeError: '<=' not supported between instances of 'int' and 'NoneType'
This is triggered because it is incorrectly assumed that policy.max_line_length
cannot be None. This issue is still present in current master:
https://github.com/python/cpython/blob/c3dd7e45cc5d36bbe2295c2840faabb5c75d83e4/Lib/email/contentmanager.py#L149
--
components: email
messages: 375625
nosy: barry, equaeghe, r.david.murray
priority: normal
severity: normal
status: open
title: policy.max_line_length is incorrectly assumed to never be None
type: behavior
versions: Python 3.10
___
Python tracker
<https://bugs.python.org/issue41585>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41553] encoded-word abused for header line folding causes RFC 2047 violation
Erik Quaeghebeur added the comment: We also shouldn't forget Resent-Message-Id. So in the header registry <https://github.com/python/cpython/blob/2a9f709ba23c8f6aa2bed821aacc4e7baecde383/Lib/email/headerregistry.py#L562>, 'message-id': MessageIDHeader, should be replaced by 'message-id': UniqueSingleMessageIDHeader, 'resent-message-id': SingleMessageIDHeader, 'in-reply-to': UniqueMessageIDHeader, 'references': UniqueMessageIDHeader, with Unique/Single used as for the other Headers. -- ___ Python tracker <https://bugs.python.org/issue41553> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41553] encoded-word abused for header line folding causes RFC 2047 violation
Erik Quaeghebeur added the comment: Note that In-Reply-To can also contain multiple message ids: <https://tools.ietf.org/html/rfc5322#section-3.6.4>. It should be treated the same as References. When you say that a message_id parser exists, then that means it is not applied to the Message-Id header by default yet, because my example shows that the Message-Id header gets mangled. Applying encoded-word encoding to (unknown) unstructured fields may break workflows. These are often X-… headers and one cannot assume that the application generating and consuming them apply decoding. (Just as with message ids.) The most reliable approach would be to not encode them, but apply white-space folding and then leave them to go beyond the limit set (78 characters, typically). As headers, the increased line length is not that big of a problem. (The 78 limit is for visual reasons.) In case the lines still go beyond 998 characters, an error should be raised, as that is an RFC violation. Tools generating such headers are severely broken and should not get a free pass. Users could get the option to allow such lines and take their chances when the message is submitted and transported. -- ___ Python tracker <https://bugs.python.org/issue41553> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41553] encoded-word abused for header line folding causes RFC 2047 violation
New submission from Erik Quaeghebeur :
Encoded-word is apparently used for header line folding sometimes. This appears
to me as an abuse of this encoding technique. However, that is not the main
issue: it also causes a violation of RFC 2074, as it also encodes message id's:
https://tools.ietf.org/html/rfc2047#section-5 says “An
'encoded-word' MUST NOT appear in any portion of an
'addr-spec'.” and
https://tools.ietf.org/html/rfc5322#section-3.6.4 says
“The message identifier (msg-id) syntax is a limited
version of the addr-spec construct enclosed in the angle
bracket characters, "<" and ">".”
This causes actual problems. Namely, email clients cannot parse the message id
and so have trouble with generation of In-Reply-To and References headers or
problems with thread reconstruction using these headers containing encoded-word
versions of message ids.
Minimal example:
---
>>> import email
>>> import email.policy
>>> msg = email.message_from_string("""From: t...@example.com
To: t...@example.org
Subject: Test
Date: Mon, 10 Aug 2020 22:52:53 +
Message-ID:
X-Some-Blobby-Custom-Header:
DIZEglcw6TIh1uC2UrnNjWYqe8l/bYo0oxKG7mBX38s1urzvCwQD30Q07DDJFgTVZWKbThu6hVjR53MTYAHYClHPt8UvyFPkAUIc8Ps1/R+HuSQ8gbR1R03sKoFAgPZKO+FKJ9bNbBb60THl81zSCsZiALwi4LLOqnf9ZIB111G4/shFuWxRlPcsPJt72sn+tTHZqK9fRAyoK1OZCZMJmjQGysovicz1Xc6nOXHMQr2+suRwOJwSUqvsfkj8EEtzJGj7ICQ2GbgBaOjcof1AML4RCFy/vD5bG0Y8HQ2KET3SraTki4dPo+xMYSZVFEy/va4rYeynOXPfxXfHSyIFwB6gnH74Ws/XPk8ZxhAQ2wSy7Hvgg3tZ7HOmlLWg4A/vUGN+8RJlgn+hHtuCXnglv+fIKEhW36wcFotngSrcXULbTlqdE5zjuV5O7wNfgIShZnNhnPdLipslmZJGaa6RQpIonZbwUWCM8g9DZmSwo8g0On0l20IVS9s6bUCddwRZ5erHx4eUZ4DGh4YyR2fgm0WsNVW8pVsAdFMClfAJYqyPEqrDN91djfPYRZPMvzYWTAm8MAip6vDa1ZvzywDpGJYD3VwapLfgFy+AR0S/q/V1HHRmSXx1oNLEedhAt0OkIxWxO8FvqNeEfMLVhxTk1g==
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset="utf-8"
BODY
""")
>>> print(msg.as_bytes(policy=email.policy.SMTPUTF8).decode())
From: t...@example.com
To: t...@example.org
Subject: Test
Date: Mon, 10 Aug 2020 22:52:53 +
Message-ID: =?utf-8?q?=3CVI1PR09MB41911D8371E899C1FE78EE48FA440=40abcdefghij?=
=?utf-8?q?klm=2Enmopqrst=2Euvwx=2Eexample=2Ecom=3E?=
X-Some-Blobby-Custom-Header: =?utf-8?q?DIZEglcw6TIh1uC2UrnNjWYqe8l/bYo0oxKG7?=
=?utf-8?q?mBX38s1urzvCwQD30Q07DDJFgTVZWKbThu6hVjR53MTYAHYClHPt8UvyFPkAUIc8P?=
=?utf-8?q?s1/R+HuSQ8gbR1R03sKoFAgPZKO+FKJ9bNbBb60THl81zSCsZiALwi4LLOqnf9ZIB?=
=?utf-8?q?111G4/shFuWxRlPcsPJt72sn+tTHZqK9fRAyoK1OZCZMJmjQGysovicz1Xc6nOXHM?=
=?utf-8?q?Qr2+suRwOJwSUqvsfkj8EEtzJGj7ICQ2GbgBaOjcof1AML4RCFy/vD5bG0Y8HQ2KE?=
=?utf-8?q?T3SraTki4dPo+xMYSZVFEy/va4rYeynOXPfxXfHSyIFwB6gnH74Ws/XPk8ZxhAQ2w?=
=?utf-8?q?Sy7Hvgg3tZ7HOmlLWg4A/vUGN+8RJlgn+hHtuCXnglv+fIKEhW36wcFotngSrcXUL?=
=?utf-8?q?bTlqdE5zjuV5O7wNfgIShZnNhnPdLipslmZJGaa6RQpIonZbwUWCM8g9DZmSwo8g0?=
=?utf-8?q?On0l20IVS9s6bUCddwRZ5erHx4eUZ4DGh4YyR2fgm0WsNVW8pVsAdFMClfAJYqyPE?=
=?utf-8?q?qrDN91djfPYRZPMvzYWTAm8MAip6vDa1ZvzywDpGJYD3VwapLfgFy+AR0S/q/V1HH?=
=?utf-8?q?RmSXx1oNLEedhAt0OkIxWxO8FvqNeEfMLVhxTk1g=3D=3D?=
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset="utf-8"
BODY
---
--
components: email
messages: 375397
nosy: barry, equaeghe, r.david.murray
priority: normal
severity: normal
status: open
title: encoded-word abused for header line folding causes RFC 2047 violation
type: behavior
versions: Python 3.7
___
Python tracker
<https://bugs.python.org/issue41553>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11245] Implementation of IMAP IDLE in imaplib?
Changes by Erik Quaeghebeur <pyt...@equaeghe.nospammail.net>: -- nosy: +equaeghe ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue11245> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
