Mailing List Archive: shortcircuit internal mail

shortcircuit internal mail

May 19, 2020, 11:44 AM

Post #1 of 3 (402 views)

Hi,

I've already got short-circuit setup, and it works, but not for mail
that goes like this:

gmail user sends to a mailing list on a mailing list server we
host, that server does some spamassassin scanning, and if it passes it
then delivers to our users subscribed to that mailing list, which is
sent via our internal mx server and then to our internal storage server,
where spamassassin scans it again.

The final stage I thought would be short-circuited, because it was
relayed through our internal network, and we already do spam filtering
at the list server stage, we don't want to do it again.

I've set: add_header all RelaysUntrusted _RELAYSUNTRUSTED_

and see that the final SA looks at the message that is delivered and
sees that it is coming from gmail, so internal_networks,
trusted_networks, and whitelist_to do not apply.

Is there a way I can actually short-circuit this?

This is what I have configured for short-circuit:

ifplugin Mail::SpamAssassin::Plugin::Shortcircuit
#
# default: strongly-whitelisted mails are *really* whitelisted now, if the
# shortcircuiting plugin is active, causing early exit to save CPU load.
# Uncomment to turn this on
#
shortcircuit USER_IN_WHITELIST on
shortcircuit USER_IN_DEF_WHITELIST on
shortcircuit USER_IN_ALL_SPAM_TO on
shortcircuit SUBJECT_IN_WHITELIST on

# the opposite; blacklisted mails can also save CPU
shortcircuit USER_IN_BLACKLIST on
shortcircuit USER_IN_BLACKLIST_TO on
shortcircuit SUBJECT_IN_BLACKLIST on

# if you have taken the time to correctly specify your "trusted_networks",
# this is another good way to save CPU
#
shortcircuit ALL_TRUSTED on

score ALL_TRUSTED -5

# simple, non-network-based whitelists, locally-generated messages,
# messages via a trusted relay chain, simple
meta SC_HAM (USER_IN_WHITELIST||USER_IN_DEF_WHITELIST||USER_IN_ALL_SPAM_TO||NO_RELAYS||ALL_TRUSTED)
priority SC_HAM -1000
shortcircuit SC_HAM ham
score SC_HAM -30

meta SC_SPAM (USER_IN_BLACKLIST_TO||USER_IN_BLACKLIST)
priority SC_SPAM -950
shortcircuit SC_SPAM spam
score SC_SPAM 20

# slower, network-based whitelisting -- need to enable DKIM/SPF stuff before we can short circuit here
meta SC_NET_HAM (USER_IN_DKIM_WHITELIST||USER_IN_DK_WHITELIST||USER_IN_SPF_WHITELIST||USER_IN_DEF_DK_WL||USER_IN_DEF_DKIM_WL||USER_IN_DEF_SPF_WL)
priority SC_NET_HAM -500
shortcircuit SC_NET_HAM ham
score SC_NET_HAM -20

# bounce messages: always ignored if the vbounce plugin is active
priority ANY_BOUNCE_MESSAGE -700
shortcircuit ANY_BOUNCE_MESSAGE spam
score ANY_BOUNCE_MESSAGE 20

# ClamAV support: no need to scan viruses/malware
priority CLAMAV -900
shortcircuit CLAMAV spam
score CLAMAV 20

endif # Mail::SpamAssassin::Plugin::Shortcircuit

--
micah

Re: shortcircuit internal mail [ In reply to ]

jhardin at impsec

May 19, 2020, 12:33 PM

Post #2 of 3 (402 views)

Permalink

On Tue, 19 May 2020, micah anderson wrote:

> The final stage I thought would be short-circuited, because it was
> relayed through our internal network, and we already do spam filtering
> at the list server stage, we don't want to do it again.

Nope. SA scans whatever you give it to scan, and that is driven by the
MTA. All you can do in SA is tune the scoring behavior.

> Is there a way I can actually short-circuit this?

Configure the second internal MTA to entirely skip passing the message to
SA for messages received from the first internal-only MTA, which has
already scanned them.

You'll need to provide more-specific information about which MTA you're
using before we can provide more-specific advice than that.

Also be aware: "short-circuit" in the SA context doesn't *quite* mean what
you're asking.

--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
Campuses today are a theatrical mashup of
1984 and Lord of the Flies, performed by people
who don't understand these references. -- David Burge
-----------------------------------------------------------------------
169 days until the Presidential Election

Re: shortcircuit internal mail [ In reply to ]

micah at riseup

May 20, 2020, 4:40 AM

Post #3 of 3 (399 views)

Permalink

Thanks for the reply.

John Hardin <jhardin@impsec.org> writes:

> On Tue, 19 May 2020, micah anderson wrote:
>
>> The final stage I thought would be short-circuited, because it was
>> relayed through our internal network, and we already do spam filtering
>> at the list server stage, we don't want to do it again.
>
> Nope. SA scans whatever you give it to scan, and that is driven by the
> MTA. All you can do in SA is tune the scoring behavior.

Indeed, you are right. I had a fundamental misunderstanding in the
architecture.

>> Is there a way I can actually short-circuit this?

One way, which isn't particularly great, is to do something like this:

# if it comes from our list server, we don't want to scan it again
describe __LOCAL_OUR_LISTS Was delivered to our lists
priority __LOCAL_OUR_LISTS -100
header __LOCAL_OUR_LISTS Delivered-To =~ /\@lists\.example\.com/
shortcircuit __LOCAL_OUR_LISTS on

of course someone can forge the Delivered-To, there are some other list
specific headers that could also be found as well.

> Configure the second internal MTA to entirely skip passing the message to
> SA for messages received from the first internal-only MTA, which has
> already scanned them.
>
> You'll need to provide more-specific information about which MTA you're
> using before we can provide more-specific advice than that.

That is an interesting idea, I'm running postfix, and doing the
following in master.cf right now:

dovecot unix - n n - - pipe
flags=DRhu user=mail argv=/usr/bin/spamc --connect-retries=1 -H -d 10.0.1.90 -s 10240000 -t 100 -u ${recipient} -e /usr/lib/dovecot/dovecot-lda -f ${sender} -d ${user}@${domain}

and dovecot is a virtual_transport.

> Also be aware: "short-circuit" in the SA context doesn't *quite* mean what
> you're asking.

Yeah, I am aware... it still fires up all of spamassassin and begins
processing, but at least with the priority level high, it should
determine things quickly and bail out.

--
micah