Martin Gregorie:
Have you set the 'internal_networks' configuration parameter (in
local.cf)? If not, try that first.
On 18.05.21 12:07, David Bürgin wrote:
Thanks, but I don’t think this helps here. I don’t know what I could add
to internal_networks that would somehow change the behaviour. The
problem is with how milters for SpamAssassin operate.
this is more an issue of how milter itself operates.
the milter is supposed to see e-mail as it was received from (smtp) client -
even without Received: headers, just with other milters' modifications.
If SpamAssassin (SA from now) has to see Authentication-Results: headers
from other milter, the other milter must run before milter using SA
(spamass-milter, amavisd-milter, etc)
SA milter has to synthetize the Received: header it passsed with mail to
SpamAssassin. If it prepends Received: header (as expected), the
Authentication-Results: header(s) added by the former milter appear after
Received: and SA doesn't trust it.
...nobody sees the synthetized Received: header later, they see Received:
added by MTA, before Authentication-Results added by mentioned milter.
Possible workarounds require trusting the Authentication-Results: header
either via SA milter (which would add synthetized Received: header after
it), or via SpamAssassin itself (trust headers added by "host" immediately
after last trusted/internal "Received" header.)
I prefer the second setup, as it's possible to re-check SA score for such
e-mail later.
I have tried receiving mail with fake Authentication-Results: header and it
got deleted by opendkim-milter, to opendkim-milter may be trusted for this
setup.
SA would need an option which hosts to trust Authentication-Results: from.
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
BSE = Mad Cow Desease ... BSA = Mad Software Producents Desease
