> postscreen is one layer in a multi-layer defense. It does not have > to stop all unwanted email. That is what the other layers are for.
Certainly. That does not warrant blindly stacking layers upon one another simply because one can. There are certainly layers that postscreen clearly renders marginal (DNSBL checks in SA postqueue). Others like fail2ban, I'm simply not sure as yet. > the things fail2ban has been really useful > for are blocking AUTH dictionary attacks Good point. Simply haven't suffered much of that at all, but understand the value if it's a concern. > blocking clients that consistently fail a full-scan filter such as > SpamAssassin. Again, clear in principle -- and not something my stats had shown as a problem. So, to both -- likely worth the additional bit of effort at prophylaxis. > more about cleaning up your log than protecting postfix. I'd rather know than not know. I'm happy enough with grep, here. > as long as you're not approaching DoS levels of rejects it doesn't matter too much. I'm not. For now. > postscreen doesn't change the argument very much. I've been weighing postscreen's load vs the 'rest of postfix'. If postscreen can handle it early, I'm fine with the countless rejects. Pre-postscreen, the 'rest of postfix' took the full hit, and fail2ban helped there. I've no quantitative measure of the relative loads for reject, but understand that postscreen is earlier and more efficient. Given the validity of the points above, I'll likely keep fail2ban in place, but tune it 'down' to more clearly act on those things that are not already well remediated by postscreen. Appreciate the comments.
