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 _______________________________________________ Mailman-users mailing list -- [email protected] To unsubscribe send an email to [email protected] https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ Archived at: https://lists.mailman3.org/archives/list/[email protected]/message/7VWNL53LAJMTBTN773YMIL7ECPDHBUP7/ This message sent to [email protected]
