>From: Reindl Harald <h.rei...@thelounge.net> >Sent: Saturday, March 28, 2015 6:13 AM >To: users@spamassassin.apache.org >Subject: Re: Uptick in spam
>Am 28.03.2015 um 12:04 schrieb David Jones: >> I know that but I choose to use the "traditional" method in the Postfix >> smtpd_recipient_restrictions so I can specify the order. I have such a >> high volume of mail for more than 100,000 mailboxes, I want to check >> in a specific order using my local rbldnsd feed to prevent abuse of other >> RBLs further down the list Thank you for the recommendation and I will research the impact that my high volume mail filters would cause to other RBLs that I do not have a local rbldnsd feed for. I have a local caching DNS server pointed to a set of private DNS servers hosting my rbldnsd zones so the impact should be as low as possible to the "external" RBL lookups. I have to be mindful of their free use limitations and abuse policies. (I have received emails from a few of them for excessive usage and had to discontinue using those.) >the problem with this approach is that with each RBL you raise the >false-positive rates extremely, until now i did not see any RBL without >FP be it Zen, Barracuda or Spamcop You are correct. This method does give complete power to each RBL to reject a message. If there were a way to specify the order of RBL checks then I could eliminate this problem. I will research this. >another thing is performance: "smtpd_recipient_restrictions" is >sequential while postscreen asks all RBLs parallel, if one or more have >a timeout it don't block, they are just not taken into account at that >moment, when you have enough RBL's the result is still good I have very fast, low latency connections to the Internet so speed is not my problem. My typical batch processing time (30 emails) is under 5 seconds in MailScanner which is very good running 2 AV scanners. Postfix is a tiny fraction of that processing time and most of it is AV and SA. In SA, I have DCC (local DCC peer), Razor, Pyzor, Bayes in a redis DB, CRM114, and BOGOFILTER enabled. I have tuned SA from taking around 30 seconds to under 4 seconds per batch using safe shortcircuit rules and safe whitelist_from_* entries. The only spam I have a problem with is from compromised accounts for the first 30 minutes or so until RBLs kick in. I am still able to block most of the compromised account spam. I know I could turn on grey- listing and help with this but I feel that greylisting is not worth the delay _in our environment_ for the small gain that I would get. I want to look into selective greylisting when I get some time to build it out properly for our environment that is acceptable for our customers.
