Thanks for the reply.
John Hardin <jhar...@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
