Hi, >> I'm sure by now it's in the PBL or SBL. > > This is a bad assumption. The PBL lists dynamics/etc, not snowshoe IPs.
Right, that makes sense. A spammer wouldn't have access to a consecutive block of dynamic IPs, like from a cable company or Verizon. It still could mean that it's listed in the PBL by now, though. >> They were later all tagged as spam, but it would definitely be nice to >> be blocking these outright with postscreen. I've now added an iptables >> rule manually, but I wish there was a way to build in some >> intelligence to automate it, such as with fail2ban. > > Unfortunately fail2ban doesn't work for snowshoe. The rate is > intentionally low, which is why snowshoe avoids most trap driven DNSBLs > as well. I have fail2ban working with dnsblog. It may not necessarily work for snowshoe, but it works well for repeated attempts. Just to confirm my understanding, dnsblog does the lookup and logging, then rejects based on the policy, correct? So it wouldn't be necessary filter on postscreen entries because it's the same IP log info as with dnsblog? >> Are you suggesting I increase the weight of the BRBL with postscreen? > > I don't use postscreen. I block outright in SMTPD on any DNSBL hit. > I.e. I don't use weighting. With any of the reputable DNSBLs you should > probably outright block, not score. So set postscreen weighting so any Okay, I've set the postscreen threshold to 1, so any hit is a reject. It's already dramatically increased the number of rejects. I've also added the reject_rhsbl_reverse_client and other rhsbl statements you've recommended. I decided not to bother with warn_if_reject and trust the DNSBLs. I realize it's doing twice as many DNS lookups for now. I'll also have to whitelist any false positive IPs in multiple places for now too. When I was working on this in 2010 (how the hell did you remember that?), my system was so old that it not only didn't support warn_if_reject, it didn't support any of the rhsbl statements in smtpd_recipient_restrictions. It was certainly pre-2.0 release I was using, so I wasn't able to implement any of the suggestions. > smtpd_recipient_restrictions = > ... > reject_rhsbl_reverse_client dbl.spamhaus.org > reject_rhsbl_sender dbl.spamhaus.org > reject_rhsbl_helo dbl.spamhaus.org > ... > > And in fact you asked about DNSBLS in April 2010 > http://comments.gmane.org/gmane.mail.postfix.user/208344 > > and were given all of this information then, by Ralf and myself. You > can also use multi.uribl.com and multi.surbl.org here, requiring a total > of 9 parameter entries. For now I've just added the spamhaus.org entries. I've added them after reject_unknown_recipient_domain and before check_helo_access. Is that correct? How about barracuda? I'm currently using it with postscreen. I think I like postscreen better than the rhsbl statements because of the additional features of postscreen. > I just noticed you don't require HELO. So you need this as well: > > smtpd_helo_required = yes > > And in fact, your current HELO based restrictions are having no effect > if clients don't send HELO/EHLO: > > check_helo_access pcre:/etc/postfix/helo_checks.pcre > reject_invalid_helo_hostname Okay, awesome, I've added that. I didn't even think it was possible to send mail without that. Headed off for some turkey, so for now I'll just say thanks and great advice about the SSD system. I'm definitely interested in building an SSD system, and planned on doing that early next year, once I have the resources from the customer. Thanks again, Alex
