Re: short-circuit ALL_TRUSTED

[RW]

On Mon, 01 May 2017 12:26:55 -0400
micah anderson wrote: 

> internal_networks 10.0.
> 
> but things are not shortcircuiting, you can see it is finding the
> relay as trusted and internal in this line:
> 
> Apr 24 15:32:38.862 [29876] dbg: received-header: relay 10.0.1.163
> trusted? yes internal? yes msa? no
> 
> but I'm not clear how it decides if it should short circuit or not.
> Can anyone clarify?

> X-Spam-Status: No, ... UNPARSEABLE_RELAY

It's because the other received header is not parseable,
UNPARSEABLE_RELAY prevents ALL_TRUSTED from being hit.

Probably because it's missing "by "

>Received: from [127.0.0.1] (localhost [127.0.0.1])
>    (Authenticated sender: foodefai)
>    with ESMTPSA id 7492F1C05F2

Re: short-circuit ALL_TRUSTED

[David Jones]

From: micah anderson 

>I have trusted_networks and internal_networks configured, and have been
>short-circuiting spam processing when messages come from those
>networks. 

>I have:

>shortcircuit ALL_TRUSTED on

I would advise against this since you need to do proper outbound filtering.

>and I have internal_networks or trusted_networks configured, yet these
>messages don't shortcircuit, and I'm puzzling over the spamassassin -D
>output trying to understand why, does someone have some suggestions?

>For example, I have:

>internal_networks 10.0.

internal_networks 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 169.254.0.0/16
fe80::/10 [plus public IP ranges of your network]

trusted_networks [public IP ranges not in you network but you trust based
on some form of arrangement]

If you are using Postfix (which I am familiar with), then the internal_networks
plus trusted_networks will match pretty closely to 'postconf mynetworks'.

>but things are not shortcircuiting, you can see it is finding the relay
>as trusted and internal in this line:

>Apr 24 15:32:38.862 [29876] dbg: received-header: relay 10.0.1.163 trusted? 
>yes internal? yes msa? no

>but I'm not clear how it decides if it should short circuit or not. Can
>anyone clarify?

>Here is an example:

>Return-Path: 
>X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on towhee.riseup.net
>X-Spam-Level: *
>X-Spam-Pyzor:=20
>X-Spam-Status: No, score=3D1.5 required=3D6.0 tests=3DAM_TRUNCATED,BAYES_60,
>    NEAR_EMPTY,UNPARSEABLE_RELAY shortcircuit=3Dno autolearn=3Ddisabled 
>versio=
>n=3D3.4.1
>Delivered-To: mi...@riseup.net
>Received: from piha.riseup.net (unknown [10.0.1.163])
>    (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
>    (Client CN "*.riseup.net", Issuer "COMODO RSA Domain Validation Secure 
>Ser=
>ver CA" (verified OK))
>    by towhee.riseup.net (Postfix) with ESMTPS id 91445AD
>    for ; Wed,  5 Apr 2017 12:52:34 + (UTC)
>Received: from [127.0.0.1] (localhost [127.0.0.1])
>    (Authenticated sender: foodefai)
>    with ESMTPSA id 7492F1C05F2
>From: Food Defai 
>To: micah 
>Subject: here are a few tests
>Date: Wed, 05 Apr 2017 15:50:10 +0300
>Message-ID: <87fuhnc931@riseup.net>
>MIME-Version: 1.0
>Content-Type: text/plain

Create a meta rule based on ALL_TRUSTED and something unique about this message
that can not be forged by a spammer with control of a compromised account.  For 
example:

header  __MSGID_TRUST   Message-ID =~ /@riseup\.net/
header __AUTH_SENDER  Received =~ /Authenticated sender: foodefai/
metaINT_TRUSTED   ALL_TRUSTED && __MSGID_TRUST && 
__AUTH_SENDER
score   INT_TRUSTED   -0.001
priority   INT_TRUSTED   -900
shortcircuit  INT_TRUSTEDham
tflagsINT_TRUSTED noautolearn nice

Make sure you have "loadplugin Mail::SpamAssassin::Plugin::Shortcircuit" 
enabled in
v320.pre.

Of course key to this working is to setup meta rules that spammers don't know 
anything
about and this one was just published to a public mailing list so you may want 
to adjust
it a bit based on something else unique about the message headers.  If they got 
control
of an internal account on a server that sent outbound through this SA instance, 
then they
could forge some headers to match this rule then you will be listed on RBLs in 
no time.

Dave