M.Ede via Mailman-users writes:
Mark Sapiro wrote:
The following patch will remove the header.
Thanks for the hint, I removed authentication-results header as well as arc-authentication-results with your patch, but rspamd still results in SPOOFED_UNAUTH.
I don't think Mark was suggesting that would help with the SPOOFED_UNAUTH problem. I read his mail as saying that it needs to be fixed because it breaks anonymous_list. I don't think that rspamd is paying attention to any of the smtp.*from information because the one that matters is the one in the SMTP MAIL FROM command, which only appears in the message header by accident. (It could be some kind of machine learning thing, but I doubt that would get dinged for 50 points.)
If you're still having issues
- Does your problem resemble any of those in the links Mark sent?
- Where is rspamd running? On your host or at Mailcow?
- Who is sender@t-online.de, is it a placeholder for a random user, or is it an address associated with your Mailcow account?
- Are my.mailserv.er and lists.list.domain the same host? If not, what is their relationship?
- Where are you running the ARC and DKIM processors?
- Do you have Mailman set to strip DKIM signatures? (I find it hard to believe that a major ESP like t-online doesn't sign outgoing email.)
- What is the list address? Specifically, is it @lists.list.domain, or is it @list.domain? You need a DKIM public key record in DNS for the exact domain of the list as it is added to From.
- Do you have a non-permissive DMARC policy for lists.list.domain?
- How do you send list mail to Mailcow? (a) Regular SMTP directly to the Mailcow MX (b) Regular SMTP indirectly via a different host that is not authorized in SPF to send mail for your list domain (c) Authenticated SMTP (usually SASL on port 587)?
Something is definitely odd about your ARC installation. It should not be possible for ARC verification to fail within the administrative domain that applied the ARC headers, because in theory the ARC signature and seal are performed on the *outgoing* message at the administrative boundary. Also, in the example in your third post[1] the server names in the ARC headers doesn't match:
ARC-Message-Signature: i=1; d=lists.serv.er;
ARC-Authentication-Results: i=1; mailserv.er;
ARC-Seal: i=1; s=dkim; d=lists.serv.er;Maybe that's just a typo, but if not that could be the problem, I'm pretty sure those are expected to match.
I think the missing DKIM signature may be important. One interpretation of "SPOOFED_UNAUTH" is "I think it's spoofed because I can't authenticate it". In question 9 above, if you send mail via (a) SPF *could* authenticate it, and via (c) that's pretty good authentication, but DKIM is best and Mailcow may insist on it.
[1] <175750349214.87167.13924287800652306747@mail.mailman3.org> Aaargh, gmx.de has a non-permissive DMARC policy -- hope you're not deleting dupes because that almost always means you don't get the list version.
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan