From: Roderick A. Anderson (no email)
Date: Fri May 28 2010 - 13:52:50 EDT
Andy Dills wrote:
> On Thu, 27 May 2010, Wietse Venema wrote:
>> Andy Dills:
>>> I've been investigating postscreen, as we've been address probed/bombed
>>> for years, as we have a few domains that are very old (well, early 90s)
>>> that had a lot of users back in the dialup days. Our approach was to just
>>> throw hardware at the problem, and we've had a whole cluster of servers
>>> just sending out 550s all day long for years now.
>>> We don't do any RBL checks at the postfix level; we have amavisd-new
>>> handle all of that via spamassassin. I'm hesitant to allow a single
>>> blacklist to determine the fate of mail acceptance, especially when we
>>> have a very low false negative rate with amavisd/SA. Essentially, we'd
>>> rather throw hardware at the problem than potentially reject legit mail.
>>> My primary question is, would we see significant improvement by using
>>> postscreen if we don't use RBLs?
>> In my experience, the "pregreet" check kills off 50% of the zombies.
>> Of course malware will "improve" and I expect to add deeper protocol
>> checks (command pipelining, greylist) in anticipation.
> That seems worth investigating, thank you. I appreciate how you're
> evolving postfix to address this (and the improvements to handle content
> filtering pre-queue, we will be moving to that once amavisd-new is more
> mature with regards to that).
>>> Also, would postscreen_cache_map work with a mysql backend?
>> postscreen needs very low latency (I put in explicit tests for
>> this). Also, postscreen requires read, write, iterate support
>> which is implemented only for file-based databases.
>> If table access requires 10ms, then postscreen can handle only 100
>> connection requests per second. You would be better off not using
>> postscreen and instead turning up the number of smtpd processes.
> That makes sense. I was just looking for a way to provide some "shared
> knowledge" among the servers in the cluster.
Run a cron job that checks for changes in the RDBMS and then rebuilds
the postscreen_cache_map "files" if needed.
-- > > Thanks, > Andy > > --- > Andy Dills > Xecunet, Inc. > www.xecu.net > 301-682-9972 > ---