On 11/22/2012 12:39 PM, Alex wrote: > 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.
Again, the IP in question will never be listed in the PBL. SBL maybe, PBL no. Might be time to brush up on Spamhaus various lists and their criteria. >>> 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. Fail2ban doesn't stop spam. It merely shifts the burden of rejection from Postfix to the IP stack. And it won't work for snowshoe because you're never going to detect snowshoe with Postscreen, or any Postfix controls. > 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? Someone else will need to answer this. >>> 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. And decreased the load on your content filters as well, I presume, and likely decreased or eliminated your 220 delay issue. > 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. You're using SA which makes all of these same DNSBL lookups. So you're not doing any extra lookups, just doing them sooner in the cycle. If mail reaches SA its lookups are now local to your resolver, which speeds up SA as it doesn't have to wait for remote DNS server responses. > I'll also have to whitelist any false > positive IPs in multiple places for now too. RHSBL restrictions trigger on domains, not IPs. Domains that end up on domain based block lists or URI block lists rarely, if ever, send legit mail. > 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. It's obviously always best to stay close to current. >> 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? I always put my least expensive restrictions first and most expensive last. So inbuilt Postfix checks go first, then local table checks, then DNSBL lookups, then content filters. > How about barracuda? I'm currently using it with postscreen. Set it to reject outright (which I believe you already have) and you're done. > I think I like postscreen better than the rhsbl statements because of > the additional features of postscreen. Fuzzy dice hang'n on your mirror don't make the car go faster. If you find that you *need* weighting of RHS domain rejection decisions due to high FPs (which I doubt), then you can use postfwd or policyd for weighting. Keep in mind policy servers are much slower than Postfix smtpd restrictions, but faster than content filters. Thus it's always best to reject with inbuilt Postfix restrictions if you can, on a busy server. >> 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. I'm not sure if the latest SMTP RFC requires HELO/EHLO or not. Regardless, you should enforce it or your HELO checks may be worthless. > Headed off for some turkey, Hope you didn't gain 10 pounds like many of us. :) > 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. Prices should be a little lower by then as well, at least for the SSDs. The RAID card prices may not move much. SSD simply makes soo much sense for a mail gateway. You never have to worry about a queue IO bottleneck again. > Thanks again, Always glad to help. -- Stan
