Matus UHLAR - fantomas:
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.
Thank you, this is a good summary of the problem.
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.
To the SpamAssassin developers: Would you consider adding a
configuration option to trust *all* Authentication-Results headers with
a certain authserv-id
(https://www.rfc-editor.org/rfc/rfc8601#section-2.5)? That would be very
helpful for setups that (securely) manage Authentication-Results headers
themselves.
