Mailing List Archive

On 1/5/2022 11:19 PM, Jered Floyd wrote:
>
> 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?
>
> 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.
>
> 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...
>
> Thanks,
> --Jered

Pursuant to Henrik K, SA-Users post, 7/22/2021:

SA removes all X-Spam-* headers from the message, it's not possible to match
on them.

Maybe rewrite the Subject on the upstream server to something unique and
trigger on that.  Beware that KAM rules (eg. KAM_MARKSPAM) might detect
most "standard" methods of Subject rewriting and add more points to the
message.

$0.02,

-- Jared Hall

>On 1/5/2022 11:19 PM, Jered Floyd wrote:
>>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?
>>
>>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.
>>
>>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...

On 06.01.22 00:11, Jared Hall wrote:
>Pursuant to Henrik K, SA-Users post, 7/22/2021:
>
>SA removes all X-Spam-* headers from the message, it's not possible to match
>on them.
>
>Maybe rewrite the Subject on the upstream server to something unique
>and trigger on that.? Beware that KAM rules (eg. KAM_MARKSPAM) might
>detect most "standard" methods of Subject rewriting and add more
>points to the message.

yes, OTOH it would be great to be able to re-process matched rules, possibly
with different (e.g. per-user) scores.

But this must to be implemented yet.
--
Matus UHLAR - fantomas, uhlar@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.
A day without sunshine is like, night.

On 2022-01-05 at 23:19:59 UTC-0500 (Wed, 5 Jan 2022 23:19:59 -0500
(EST))
Jered Floyd <jered@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
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire

On 1/5/22 9:19 PM, Jered Floyd wrote:
> 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). ...
>
> Is there a way to do this within Spamassassin config?

I don't know if it would work in your scenario or not, but it might work
to have the upstream system send to the downstream mailhub on a
different IP+port pair wherein SpamAssassin is not integrated. In
Sendmail, this could be as simple as an additional DaemonPort that
doesn't include the InputMailFilter (milter) that's interfacing with
SpamAssassin.

> 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...

So ... you want /conditional/ filtering between the upstream and
downstream mailhub.

Q: Does the upstream MSA not do filtering of inbound messages from
clients? I would think that this filtering would cover messages
originating from the upstream organization to the downstream organization.



--
Grant. . . .
unix || die

> I don't know if it would work in your scenario or not, but it might work
> to have the upstream system send to the downstream mailhub on a
> different IP+port pair wherein SpamAssassin is not integrated. In
> Sendmail, this could be as simple as an additional DaemonPort that
> doesn't include the InputMailFilter (milter) that's interfacing with
> SpamAssassin.

Yeah, this is how I ended up doing it. I use Postfix so I set up another smtpd listener on a different port with "-o {smtpd_client_restrictions=check_client_a_access cidr:/etc/postfix/upstreamrelays,reject}". Then on the upstream I set transport rules for the downstream domains that relay via that port rather than the MX record.

(And then I documented it all -- "Documentation is a love letter that you write to your future self.")

To your other question, the upstream does not do outbound spam filtering. I do have relatively aggressive rate limiting for authenticated (i.e. relay-allowed) senders using policyd-rate-limit.

--Jered

On 2022-01-06 18:20, Grant Taylor wrote:

> Q: Does the upstream MSA not do filtering of inbound messages from
> clients? I would think that this filtering would cover messages
> originating from the upstream organization to the downstream
> organization.

that header should be on same host as the email clients read there
mails, if its trusted outside of local mta, then its forged say
X-Spam-Flag: NO

do we want to trust it ?

spamassassin removes upstream results, to make X-Spam-Flag trusted to be
local

> that header should be on same host as the email clients read there mails,
> if its trusted outside of local mta, then its forged say X-Spam-Flag: NO
>
> do we want to trust it ?

I have a somewhat similar situation where the mail provider for my personal
account runs filtering software that usually puts classification headers in
the mail I recieve from them. I ignore any statement they make about the
mail being clean, but if they say it is spam, I add 2 points in SA. So far
that has rarely resulted in FPs for me.

I think it is perfectly reasonable policy to trust a (semi)trusted upstream
system that says the message is spam, and award points for that decision:
either the upstream system's original score, or a new score on the closer
host, as you wish. But unless it is a completely trusted host I'd never
trust it's decision of ham.

Unfortunately it is difficult (without trickery of some sort) to do that if
the upstream system is also SA, since SA removes the incoming X-Spam-*
headers.

Loren

On 2022-01-06 21:07, Loren Wilton wrote:

> Unfortunately it is difficult (without trickery of some sort) to do
> that if the upstream system is also SA, since SA removes the incoming
> X-Spam-* headers.

https://stackoverflow.com/questions/29182749/define-header-rule-for-x-spam-flag-in-spamassassin

if needed to trust upstream spamassassin headers, it works with that
postfix config

On 2022-01-06 11:13, Benny Pedersen wrote:
> On 2022-01-06 18:20, Grant Taylor wrote:
>
>> Q:  Does the upstream MSA not do filtering of inbound messages from
>> clients?  I would think that this filtering would cover messages
>> originating from the upstream organization to the downstream
>> organization.
>
> that header should be on same host as the email clients read there
> mails, if its trusted outside of local mta, then its forged say
> X-Spam-Flag: NO
>
> do we want to trust it ?
>
> spamassassin removes upstream results, to make X-Spam-Flag trusted to be
> local

Personally, I'll always trust anyone that declares "X-Spam-Flag: YES" or
similar, because if even the sender says it is spam, who am I to argue?

In the past I had some rules that tripped on M365 mail that they decided
was spam but sent anyway and had minimal false positives here, and I
think I dabbled with reading SA's header and assigning some points on
that basis for those senders who ran SA on outbound mail.

I was lucky enough to be able to read the original headers, and make
scoring decisions outside of just SA too.

Still, I would happily trust nearly any "this is likely spam" signal a
sender cares to forge into their messages, because who would do that on
mail that actually should be delivered?

And since the vast majority of delivery attempts are spam, if the
concern is some sort of resource consumption, trusting an upstream's
"this is spam" signal is probably your biggest resource saver.

Trusting a not-spam signal is more complicated and I don't think I would
try in SA alone, unless the upstream adds some clues that would let me
identify messages that passed through their system specifically.