On 2022-01-05 at 23:19:59 UTC-0500 (Wed, 5 Jan 2022 23:19:59 -0500
(EST))
Jered Floyd <je...@convivian.com>
is rumored to have said:
I have an upstream mail server running spamassassin as part of a
relatively complex mail flow. This server will flag mail identified as
spam with X-Spam-Flag: YES (among other standard headers).
Some of this mail gets forwarded to another organization (also
partially under my control) which has a mailhub also running
spamassassin.
I would like the downstream spamassassin to skip scanning on messages
flagged as spam, rather than wrapping in another layer of SA (or
deciding that the message is now ham after forwarding). I'm ambivalent
on if I want to re-scan messages identified as ham -- likely not,
since less information about delivery is available at this stage.
Is there a way to do this within Spamassassin config?
Not exactly. There is no mechanism for authenticating the X-Spam-*
headers that SA adds, so SA removes them before analysis so that they
cannot cause problems in Bayes or in other downstream tools that might
blindly pick up patterns that should not be trusted.
A way around this is to make the trusted scanning system add a unique
header (or headers) NOT starting with X-Spam-* to carry its judgment.
The downstream SA an detect this and shortcircuit a high-score rule to
save on processing.
Notes:
1) I don't want to simply have a rule that gives existing
"X-Spam-Flag: YES" a high score -- that would generate new headers and
further MIME wrapping. I just want the original message passed on
un-edited.
So set report_safe=0. The whole MIME-wrapping thing is more trouble than
it is worth (in my strictly personal opinion) and you're better off
without it. Adding headers or not is a local config choice, but if you
have the upstream add custom headers, you can let the downstream one add
the default X-Spam-* headers or its own custom headers.
2) I can get a similar result by having my downstream MTA skip the
spamassassin pipeline part for messages from the upstream mailhub
(probably by establishing an authenticated alternate delivery port),
but this is less ideal as it won't filter messages originating from
the upstream organization (and not scanned) and also seems more
brittle...
Check whatever mechanism you use for SA integration. Some (e.g.
MIMEDefang, MailMunge) put your custom code between the MTA and SA, so
you can choose whether or not to put a message throuygh SA at
end-of-DATA time, based on anything you can detect in the message. It's
also common with Postfix to put SA in a script called via the
content_filter setting, and whatever intermediate glue script you use
could filter for arbitrary aspects of messages.
--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
