>From: Martin Gregorie <mar...@gregorie.org>
>Sent: Thursday, December 15, 2016 1:39 PM
>To: users@spamassassin.apache.org
>Subject: Re: recent increase in spam getting through
    
>On Thu, 2016-12-15 at 18:23 +0000, David Jones wrote:
>> There are many valuable SMTP realtime checks that must be done at
>> the edge MTA.  Since you don't have control of this, then you have to
>> resort to tuning SA constantly which is a never-ending game of
>> cat-n-mouse since spam changes characteristics all of the time.
>> 
>It doen't *have* to be done at the edge MTA provided you are happy to
>accept and then bin the junk rather than rejecting it. My system has
>been working this way for years..

True but one would have to know to put your ISP's mail server range into
the trusted_networks/internal_networks in SA.  This is advanced SA
knowledge that takes a while to learn by experience or by this mailing list.
The typical person that is using SA to block spam on a single personal
mailbox is not going to know all of the tweaks that have to be done to
SA configs when retrieving email like this.

What makes SA so powerful is it's flexibility.  This flexibility also makes SA
so hard for most to wrap their heads around.  It's also hard to document
due to this flexibility.  There are so many ways to "glue" SA into the mail
flow which changes SA's perspective for things like "lastexternal" checks
that need to be setup properly to fully take advantage of SA's built-in RBL
rules.

It's still best to do RBL and DNS checks at the MTA in realtime and reject the
email so legit senders get feedback that the email was not delivered.  If you
pull email later from an ISP mailbox, then RBLs could have changed during
that time.  Also the DNS server used by client running SA post-MTA could
cause the dreaded URIBL_BLOCKED hit.  In my opinion, it makes a complex
software twice as complex to run it post-MTA.

Dave

Reply via email to