>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
