David Bürgin:
Bother. I think I will try to modify my SpamAssassin milter, so that it will add a synthetic ‘internal’ Received header right after the Authentication-Results headers … that should trick SpamAssassin into recognising them as internal.
Here’s the plan to address this in SpamAssassin Milter (https://crates.io/crates/spamassassin-milter): Add an option that takes a regular expression which matches headers *after which* the synthetic ‘internal’ Received header should be inserted. --trusted-relay-after <regex> Then one would use this like this: --trusted-relay-after '^(?i)authentication-results:[\t ]*mail\.gluet\.ch;' The effect this would have is that a message that is sent to SpamAssassin in this form currently: Received: from m43-8.mailgun.net by mail.gluet.ch (Postfix) ... Authentication-Results: mail.gluet.ch; dmarc=pass ... [← untrusted!] Authentication-Results: mail.gluet.ch; dkim=pass ... [← untrusted!] Authentication-Results: mail.gluet.ch; spf=pass ... [← untrusted!] Message-ID: <1...@execute-api.eu-central-1.amazonaws.com> ... Would now be sent to SpamAssassin in this form: Authentication-Results: mail.gluet.ch; dmarc=pass ... [← now trusted] Authentication-Results: mail.gluet.ch; dkim=pass ... [← now trusted] Authentication-Results: mail.gluet.ch; spf=pass ... [← now trusted] Received: from m43-8.mailgun.net by mail.gluet.ch (Postfix) ... Message-ID: <1...@execute-api.eu-central-1.amazonaws.com> ... I’m interested to hear what comments others might have about the problem and this solution. (Also a bit surprised that no one seems to have noticed this before.) To highlight the problem once more: When used as a milter, SpamAssassin cannot take into account Authentication-Results added by earlier milters, because it does not trust them.
