M. Ede via Mailman-users writes:
The triggering rule states:
SPOOFED_UNAUTH (50) and is determined as follows:
(1) !MAILCOW_AUTH & (2) !MAILCOW_WHITE & (3) !RSPAMD_HOST & (4) !SIEVE_HOST & (5) MAILCOW_DOMAIN_HEADER_FROM & (6) !WHITELISTED_FWD_HOST & (7) -g+:policies (50)
This means that nothing is checked here with signatures (DKIM, ARC, SPF), etc.
(1) mailman and mailcow are integrated via a Docker network, meaning mailman is not logged in as SMTP user. In my case, this should always be TRUE (the sender is "not authorized"). (2), (3), (4), (6) Exception IPs that are allowed to send emails for various reasons. (5) This is FALSE for a non-anonymized list (which is why I don't have a problem with non-anonymized lists). For an anonymized list, this is TRUE.
This analysis is correct.
As a solution, I now entered the delivering IP in (6) (this can be done via the Mailcow UI as a forwarding host).
This will work for you.
The only thing I might do different: I've set up a system where the MTA and Mailman are on different VMs, both visible from a large number of "internal" hosts, and the MTA visible from the public Internet. In that case I used SMTP AUTH both incoming and outgoing (paranoia, justified in the case of that client), but in your case with all the relevant nodes running in containers on a single host I don't think that even gives any extra security.
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan