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. Thanks, Andy --- Andy Dills Xecunet, Inc. www.xecu.net 301-682-9972 ---
