On 5/26/20 9:10 PM, Alan So wrote:
Thanks again for the work and just notice that the issue has been closed already. Looks like unfolding the header line is a logical way but it seems that >=3.3 email package unfold the header before parsing the header according to the following python issue:
Yes, the issue is closed because the fix has been merged and will be in Mailman Core 3.3.2.
I agree that it appears that there would have been no issue if Mailman
created messages using the SMTP policy and retrieved the addresses
using the addresses attribute of the headers.
However, for historical reasons, Mailman Core still uses the compat32
policy (Python 3.2 compatibility) and uses email.utils.getaddresses()
to get the addresses from the header value, so the "fix" for
<https://bugs.python.org/issue11050> doesn't apply.
Changing Mailman Core to use email.EmailMessage() objects rather than the legacy email.Message() objects is a worthwhile goal, but would require extensive changes to fix all the things that broke as a result.
Anyway, I really appreciate your diligence in following through repeatedly on this issue. Were it not for that, I wouldn't have been motivated to fix it. For a look at why even a trivial change is not trivial, see the commits at <https://gitlab.com/mailman/mailman/-/merge_requests/652/commits>. The first of these is developing good tests for the issue and then fixing the code so the tests pass, and the second, unanticipated one was due to the fact that Python 3.5 didn't maintain the original ordering of the addresses in Cc: so I couldn't compare against a fixed result. This is due to the fact that the underlying code uses dictionaries, and prior to Python 3.6 dictionaries didn't preserve order.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan