Massive amounts of bounces after setting munge_from for dmarc compliance
Mailman 2.1.26. I modified all our lists that did not have munge_from set for DMARC compliance. I ran a few tests and was able to send and receive email from my test list. Now I’m getting reports that large numbers of emails are bouncing and members are being unsubscribed. I had someone forward a bounce message to me and it says it was rejected because it was suspected as spam. In this sample email the headers show the original sender has some DKIM headers and I do not have mailman set to remove DKIM headers. From the docs I found on the mailman wiki it said to not remove the DKIM headers.
This particular list server is on a domain that does not use DKIM but does have an SPF record set to soft fail and the DMARC is set to p=none for monitoring only. The headers in the sample email shows “dkim=fail (signature did not verify)” so I’m thinking I may need to have mailman strip out the DKIM headers from the original sender. Before I modified this particular list I created a test list and added some members from one particular organization. The test list worked fine even though the original DKIM signatures were not removed.
I also found this post where this guy says you need to remove the DKIM headers: https://blog.dogan.ch/2016/11/24/making-mailman-dmarc-compatible/
On Nov 19, 2019, at 9:39 AM, Andy Cravens acravens@uen.org wrote:
Mailman 2.1.26. I modified all our lists that did not have munge_from set for DMARC compliance. I ran a few tests and was able to send and receive email from my test list. Now I’m getting reports that large numbers of emails are bouncing and members are being unsubscribed. I had someone forward a bounce message to me and it says it was rejected because it was suspected as spam. In this sample email the headers show the original sender has some DKIM headers and I do not have mailman set to remove DKIM headers. From the docs I found on the mailman wiki it said to not remove the DKIM headers.
This particular list server is on a domain that does not use DKIM but does have an SPF record set to soft fail and the DMARC is set to p=none for monitoring only. The headers in the sample email shows “dkim=fail (signature did not verify)” so I’m thinking I may need to have mailman strip out the DKIM headers from the original sender. Before I modified this particular list I created a test list and added some members from one particular organization. The test list worked fine even though the original DKIM signatures were not removed.
I also found this post where this guy says you need to remove the DKIM headers: https://blog.dogan.ch/2016/11/24/making-mailman-dmarc-compatible/
Mailman-Users mailing list Mailman-Users@python.org https://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-users/acravens%40uen.org
I meant to say our default setting for all lists is to set from_is_list to munge_from. I also realized that some list managers (who’s domain uses DKIM) have added footers to their mailing list so I’ll have to strip the DKIM headers no matter what. Finally, in the documentation I have found I see two variations for setting REMOVE_DKIM_HEADERS.
REMOVE_DKIM_HEADERS = 1 REMOVE_DKIM_HEADERS = Yes
Which one is correct?
Hi,
On 2019/11/20 2:27, Andy Cravens wrote:
<snip>
I meant to say our default setting for all lists is to set from_is_list to munge_from. I also realized that some list managers (who’s domain uses DKIM) have added footers to their mailing list so I’ll have to strip the DKIM headers no matter what. Finally, in the documentation I have found I see two variations for setting REMOVE_DKIM_HEADERS.
REMOVE_DKIM_HEADERS = 1 REMOVE_DKIM_HEADERS = Yes
Which one is correct?
I only answer to the last question (I don't know whether your judgement is appropriate or not).
In Mailman/Defaults.py.in (on 2.1.29, not changed since rev.1655, before 2.1.23): # Some list posts and mail to the -owner address may contain DomainKey or # DomainKeys Identified Mail (DKIM) signature headers http://www.dkim.org/. # Various list transformations to the message such as adding a list header or # footer or scrubbing attachments or even reply-to munging can break these # signatures. It is generally felt that these signatures have value, even if # broken and even if the outgoing message is resigned. However, some sites # may wish to remove these headers. Possible values and meanings are: # No, 0, False -> do not remove headers. # Yes, 1, True -> remove headers only if we are munging the from header due # to from_is_list or dmarc_moderation_action. # 2 -> always remove headers. # 3 -> always remove, rename and preserve original DKIM headers. REMOVE_DKIM_HEADERS = No
So, both are equivalent.
Cheers,
Yasuhito FUTATSUKI futatuki@poem.co.jp
On 11/19/19 9:27 AM, Andy Cravens wrote:
I meant to say our default setting for all lists is to set from_is_list to munge_from. I also realized that some list managers (who’s domain uses DKIM) have added footers to their mailing list so I’ll have to strip the DKIM headers no matter what. Finally, in the documentation I have found I see two variations for setting REMOVE_DKIM_HEADERS.
REMOVE_DKIM_HEADERS = 1 REMOVE_DKIM_HEADERS = Yes
Which one is correct?
They are equivalent. I don't know what documentation you found, but I think the documentation of this setting in Defaults.py should be clear.
On 11/19/19 8:39 AM, Andy Cravens wrote:
Mailman 2.1.26. I modified all our lists that did not have munge_from set for DMARC compliance. I ran a few tests and was able to send and receive email from my test list. Now I’m getting reports that large numbers of emails are bouncing and members are being unsubscribed. I had someone forward a bounce message to me and it says it was rejected because it was suspected as spam. In this sample email the headers show the original sender has some DKIM headers and I do not have mailman set to remove DKIM headers. From the docs I found on the mailman wiki it said to not remove the DKIM headers.
It says that because https://www.rfc-editor.org/rfc/rfc6376.html#section-6.1 says in part:
Survivability of signatures after transit is not guaranteed, and signatures can fail to verify through no fault of the Signer. Therefore, a Verifier SHOULD NOT treat a message that has one or more bad signatures and no good signatures differently from a message with no signature at all.
This particular list server is on a domain that does not use DKIM but does have an SPF record set to soft fail and the DMARC is set to p=none for monitoring only.
Relying on SPF only to pass DMARC is very fragile because if the message is relayed at all in transit to the destination, the final sending server's SPF if any probably won't align with the From: domain.
The headers in the sample email shows “dkim=fail (signature did not verify)” so I’m thinking I may need to have mailman strip out the DKIM headers from the original sender. Before I modified this particular list I created a test list and added some members from one particular organization. The test list worked fine even though the original DKIM signatures were not removed.
I also found this post where this guy says you need to remove the DKIM headers: https://blog.dogan.ch/2016/11/24/making-mailman-dmarc-compatible/
It says that, but gives no reason or rationale for doing so.
That said, https://www.rfc-editor.org/rfc/rfc6377.html#section-5.7 suggests verifying incoming DKIM, optionally removing incoming Authentication-Results:, adding Authentication-Results: for the results of DKIM validation, removing existing DKIM sigs and finally adding your own.
Mark Sapiro writes:
I also found this post where this guy says you need to remove the DKIM headers: https://blog.dogan.ch/2016/11/24/making-mailman-dmarc-compatible/
It says that, but gives no reason or rationale for doing so.
I know several mail admins (small-scale, not any of the big freemail providers!) who have spam filters set to give spam points when signature verification or SPF fail, in outright nonconformance to the RFCs. if you have subscribers at such sites, the "remove broken signatures and Authentication-Results, then add your own" procedure can be useful.
OTOH, I've had occasional cases (not even one a year) where it was useful to reconstruct originals (ie, by stripping forwarding decorations) and DKIM verify. (People wanting to claim they didn't send abusive mail. :-( )
Steve
participants (4)
-
Andy Cravens -
Mark Sapiro -
Stephen J. Turnbull -
Yasuhito FUTATSUKI