Hi Rob,
Configuring a mailing list with regards to DMARC, SKIM/SPF is indeed a problem!
The issue stems from that fact that if someone sends an email from a domain that has a published DMARC policy, and is DKIM signed, then in order for that DMARC policy to be passed by the recipient, the From address, Subject and Body of the message must not be altered, otherwise the DKIM signing fails.
The 44Net mailing list changes the Subject by pre-pending "[44net]”, it also alters the body by appending the list information block of text. So right away DKIM will always fail.
The mailman authors added an option to get around this by munging the From address header. So if I send an email from: chris@ardc.net this gets changed to: 44net@mailman.ampr.org mailto:44net@mailman.ampr.org
My address gets added on as a CC: field (unless I specifically switch that off in my personal settings) so generally you can see who originally sent the email, which gives you the option to reply direct if you wish to.
However, there are better ways of doing this, without “munging” headers that are not supposed to get touched, like the From header, which was designed to never change as it identifies the original source of the email. One way of doing this would be to leave the From, Subject and Body alone and instead add a Sender header with the 44net@mailman.ampr.org mailto:44net@mailman.ampr.org address in. The Sender header was designed to identify someone sending an email on behalf of someone else, which is effectively what a mailing list is doing.
TBH, I haven’t touched the mailing list server (except to keep it updated) since Brian set it up. How Brian set it up was the best option at the time, but things change, technology moves on, often quite quickly in the internet world!
The munging of the From header does generally work, although, as you correctly pointed out, it does cause issues with recipients that check DMARC policies and DKIM signatures. Also, the mailing list server has never been setup to sign outgoing emails, there is an SPF record in place, but no DKIM for the mailing list server. We do have DMARC, DKIM & SPF for the top domain ampr.org http://ampr.org/ and all outgoing mails from @ampr.org will be signed and there should be alignment with DKIM and SPF, but we could never apply a policy to subdomains of ampr.org http://ampr.org/ as all the membership use it, e.g. I can setup chris@g1fef.ampr.org mailto:chris@g1fef.ampr.org etc. As the mailing list server uses a subdomain: mailman.ampr.org http://mailman.ampr.org/ this also created a problem.
This is one of the reasons ARDC moved to @ardc.net for emails, as we can fully control the domain without worrying about subdomains. Even though there is a mechanism for setting the policy on the top domain and subdomains separately, a lot of MTA’s still don’t honour these and we got an awful lot of issues with email deliverability when we used @ampr.org now we are on @ardc.net the problems have mostly gone away.
Perhaps we should move the mailing list to ardc.net http://ardc.net/ and set it up to interact better with today’s email environment? Just a thought.
Chris - G1FEF
On 1 Aug 2021, at 10:30, Rob PE1CHL via 44Net 44net@mailman.ampr.org wrote:
I think one reason for bounces could be that the mailman mailing list does not handle DKIM properly. When a user sends a mail to the list, it passes through the DKIM signature, but it also modifies the mail (adding a standard footer as the mimimum, probably more) As a result, the DKIM signature of messages received via the list is invalid, and maybe some mail servers see it as a reason to reject the mail (as if it is spoofed). In my mail system, most mails in this list get a red color because that is what some rule processing here does to get my attention to falsified mails.
In fact this should be solved by mailman, but some googling seems to indicate that the mailman people know that, but have not yet come into action. So likely there is no setting in the admin panel to easily solve this. Maybe some extra software or feature of the existing software could be used to work around this. That would at the minimum have to delete any DKIM-Signature: header on incoming mail (unfortunately this is a multiline header so it will require more than passing through some simple grep or sed), and additionally it could add a new DKIM signature afer all mailman processing, for the mailman.ampr.org domain. But the latter is optional.
Rob