Mailman3 breaking DKIM signatures
Hi,
I have configured a mailman3 mailinglist to not modify the headers and body (e.g. no footer, no subject prefix, etc) to avoid breaking DKIM signatures. This worked well, until I encountered an email where the DKIM signature was still broken. After some debugging, the problem is caused by an attachment, where the mime header is changed by mailman3.
The original mail contains this:
--------------nYYjj8vJ8CNKuoHJZKVOQh20 Content-Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet; name="filename.xlsx" Content-Disposition: attachment; filename="filename.xlsx" Content-Transfer-Encoding: base64
Mailman3 modified these into this:
--------------nYYjj8vJ8CNKuoHJZKVOQh20 Content-Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet; name="filename.xlsx" Content-Disposition: attachment; filename="filename.xlsx" Content-Transfer-Encoding: base64
The Content-Type header is modified (word-wrapped), and this breaks the DKIM signature.
How can I prevent this from happening and configure mailman to not modify the email?
Jef
Hi,
I have configured a mailman3 mailinglist to not modify the headers and body (e.g. no footer, no subject prefix, etc) to avoid breaking DKIM signatures. This worked well, until I encountered an email where the DKIM signature was still broken. After some debugging, the problem is caused by an attachment, where the mime header is changed by mailman3.
The original mail contains this:
--------------nYYjj8vJ8CNKuoHJZKVOQh20 Content-Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet; name="filename.xlsx" Content-Disposition: attachment; filename="filename.xlsx" Content-Transfer-Encoding: base64
Mailman3 modified these into this:
--------------nYYjj8vJ8CNKuoHJZKVOQh20 Content-Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet; name="filename.xlsx" Content-Disposition: attachment; filename="filename.xlsx" Content-Transfer-Encoding: base64
The Content-Type header is modified (word-wrapped), and this breaks the DKIM signature.
How can I prevent this from happening and configure mailman to not modify the email?
Jef
On 1/21/25 4:40 AM, jefdriesen@hotmail.com wrote:
Hi,
I have configured a mailman3 mailinglist to not modify the headers and body (e.g. no footer, no subject prefix, etc) to avoid breaking DKIM signatures. This worked well, until I encountered an email where the DKIM signature was still broken. After some debugging, the problem is caused by an attachment, where the mime header is changed by mailman3. ... The Content-Type header is modified (word-wrapped), and this breaks the DKIM signature.
How can I prevent this from happening and configure mailman to not modify the email?
You could try a patch like ``` --- a/src/mailman/runners/lmtp.py +++ b/src/mailman/runners/lmtp.py @@ -186,7 +186,8 @@ class LMTPHandler: listnames = set(getUtility(IListManager).names) # Parse the message data. If there are any defects in the # message, reject it right away; it's probably spam. - msg = email.message_from_bytes(envelope.content, Message) + msg = email.message_from_bytes(envelope.content, Message, + policy=email.policy.Compat32(max_line_length=0)) msg.set_unixfrom(envelope.mail_from) except Exception: elog.exception('LMTP message parsing') ``` This should prevent folding headers, but this is problematic. It may be that the incoming message contains a folded header and this change will not fold it in the outgoing message. I think not, but I don't know for sure. You'll have to test this. -- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark Sapiro writes:
This should prevent folding headers, but this is problematic. It may be that the incoming message contains a folded header and this change will not fold it in the outgoing message. I think not, but I don't know for sure. You'll have to test this.
Mailman definitely can refold header fields differently from the original. This happens with Asian scripts all the time.
Hi Mark, чт, 23 янв. 2025 г., 03:15 Mark Sapiro <mark@msapiro.net>:
You could try a patch like ``` --- a/src/mailman/runners/lmtp.py +++ b/src/mailman/runners/lmtp.py @@ -186,7 +186,8 @@ class LMTPHandler: listnames = set(getUtility(IListManager).names) # Parse the message data. If there are any defects in the # message, reject it right away; it's probably spam. - msg = email.message_from_bytes(envelope.content, Message) + msg = email.message_from_bytes(envelope.content, Message, + policy=email.policy.Compat32(max_line_length=0)) msg.set_unixfrom(envelope.mail_from) except Exception: elog.exception('LMTP message parsing') ``` This should prevent folding headers, but this is problematic. It may be that the incoming message contains a folded header and this change will not fold it in the outgoing message.
Doesn't this parameter fits better? https://docs.python.org/3/library/email.policy.html#email.policy.EmailPolicy... Danil
On 1/23/25 12:53 AM, Danil Smirnov via Mailman-users wrote:
чт, 23 янв. 2025 г., 03:15 Mark Sapiro <mark@msapiro.net>:
You could try a patch like ``` --- a/src/mailman/runners/lmtp.py +++ b/src/mailman/runners/lmtp.py @@ -186,7 +186,8 @@ class LMTPHandler: listnames = set(getUtility(IListManager).names) # Parse the message data. If there are any defects in the # message, reject it right away; it's probably spam. - msg = email.message_from_bytes(envelope.content, Message) + msg = email.message_from_bytes(envelope.content, Message, + policy=email.policy.Compat32(max_line_length=0)) msg.set_unixfrom(envelope.mail_from) except Exception: elog.exception('LMTP message parsing') ``` This should prevent folding headers, but this is problematic. It may be that the incoming message contains a folded header and this change will not fold it in the outgoing message.
Doesn't this parameter fits better?
https://docs.python.org/3/library/email.policy.html#email.policy.EmailPolicy...
That would be better except Mailman uses the legacy email.message.Message class whose policy is Compat32 and the Compat32 policy doesn't accept refold_source. -- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark Sapiro writes:
On 1/23/25 12:53 AM, Danil Smirnov via Mailman-users wrote:
Doesn't this parameter fits better?
https://docs.python.org/3/library/email.policy.html#email.policy.EmailPolicy...
That would be better except Mailman uses the legacy email.message.Message class whose policy is Compat32 and the Compat32 policy doesn't accept refold_source.
I would welcome a patch, especially if (a) tested on a system offering lists to the general public (or some organization large and diverse enough to support the span of the MUAs cat(1), mutt, Thunderbird, and Outlook), and (b) enabling owners at some level to select policy.
I don't promise to apply (it's not my call), but I've personally been interested in a number of issues that can probably be addressed via email.policy tweaks.
Steve
participants (5)
-
Danil Smirnov -
Jef Driesen -
jefdriesen＠hotmail.com
-
Mark Sapiro -
Stephen J. Turnbull