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 <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan