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.
> 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.
Wietse
