Configuring ARC with multiple domains in Mailman3

I'm working on setting up MailMan 3 on an Ubuntu 24.04 LTS server. I've got everything running and working with docker-mailman. Now I'm looking at configuring ARC and am a bit lost.
How is ARC configured in a mailman3 with multiple domains?
Do I set it up to use the hostname of the server Mailman is running on?
Thanks for any assistance, --[Lance]

Lance A. Brown writes:
I'm working on setting up MailMan 3 on an Ubuntu 24.04 LTS server. I've got everything running and working with docker-mailman. Now I'm looking at configuring ARC and am a bit lost.
How is ARC configured in a mailman3 with multiple domains?
It shouldn't be. It should be configured in your MTAs. Mailman can't do SPF, and it can't make the decision to distribute or not based on ARC validation without a preexisting ARC-Authentication-Results field from your host. Neither of those is fatal, but implementing in the MTA is preferable.
ARC was originally added as a proof of concept. But I have to admit setting it up in Mailman is easier than doing it in the MTA, it's not as easy as throwing a switch in Postfix or Amavis (although it should be!)
Do I set it up to use the hostname of the server Mailman is running on?
That's arbitrary. Here's the theory of ARC:
- I saw it come in. ARC (all the way back) was valid as of last hop. Here are current SPF and DKIM results. Trust me!
- It wasn't Evil when it came in and I didn't do anything Evil to it. Trust me!
- Here's my signatures. Validate them!
So the question is, "why do other systems trust you, and what identity do you want your trustworthiness to bind to?" Could be an organizational reputation you already have, in which case you might want to use that domain. One of your Mailman domains (eg, the one with the widest distribution) might serve as a representative. Or none of the above has a reputation to the general public, and you need to build it from scratch. In that case, the host name is as good a place as any to start I guess.
Note, I have no experience inside the big email providers who are generally the important consumers of ARC, so you should take the advice above as a place to start thinking, rather than authoritative. Unfortunately they tend to be very close-mouthed about how they evaluate messages or sites, and their published advice amounts to "follow best practices such as DKIM signing and ARC".
Note that as far as I know Mailman's ARC implementation doesn't do anything except implement validation and signing. Some other part of the process needs to decide what to do about a broken ARC chain or other authentication failures, but I don't see a way to do it in current Mailman -- the decision to reject, hold, or distribute takes place before ARC handlers are invoked as far as I can tell.

I think it's worth moving email validations from handlers into rules, thus:
https://gitlab.com/mailman/mailman/-/issues/1200
is the bare bones of the idea. Please take technical discussion there. Any matters of asking the community's preferences of course belong here.

I found a solution by arranging for outbound mail to go through a dedicated service which handles the ARC sealing and such-like for me. It's working nicely! I was even able to turn off the DMARC munging on my test list without problems.
--[Lance]
Stephen J. Turnbull wrote on 2/5/2025 7:54 AM:
It shouldn't be. It should be configured in your MTAs. Mailman can't do SPF, and it can't make the decision to distribute or not based on ARC validation without a preexisting ARC-Authentication-Results field from your host. Neither of those is fatal, but implementing in the MTA is preferable.
ARC was originally added as a proof of concept. But I have to admit setting it up in Mailman is easier than doing it in the MTA, it's not as easy as throwing a switch in Postfix or Amavis (although it should be!)

Lance A. Brown writes:
I found a ... a dedicated service which handles the ARC sealing. It's working nicely!
Great! That's a perfectly acceptable solution, and you have access to the ARC-Authentication-Results which can be checked in Mailman's "Header Filter" configuration section with
Header | Pattern | Action
ARC-Authentication-Results | authserv-id=$SERVICE.*(arc|dkim)=fail | Hold
where $SERVICE is a token provided by your service, I definitely recommend holding and checking the message if ARC failed. There's no safe reason for that to happen that I know of. DKIM and especially DMARC do fail for various reasons, so you have to judge if there are too many false positives. You can remove the "|dkim" part or add additional protocols with "|spf" (for example) inside the parentheses.
I was even able to turn off the DMARC munging on my test list without problems.
Be careful about this in production. Monitor your bounces and the RBLs, this is the kind of change that warrants a period of heightened attention. There are free "pull" services for multiple RBLs that you have to check, and of course you can pay for "push" services that do the monitoring and notify you of events.
Steve
participants (2)
-
Lance A. Brown
-
Stephen J. Turnbull