289618Re: Initial 220 greeting timeout
- Nov 22, 2012Hi,
>> I'm sure by now it's in the PBL or SBL.Right, that makes sense. A spammer wouldn't have access to a
> This is a bad assumption. The PBL lists dynamics/etc, not snowshoe IPs.
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,
>> They were later all tagged as spam, but it would definitely be nice toI have fail2ban working with dnsblog. It may not necessarily work for
>> 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.
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?Okay, I've set the postscreen threshold to 1, so any hit is a reject.
> 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
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 =For now I've just added the spamhaus.org entries. I've added them
> 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
> 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.
after reject_unknown_recipient_domain and before check_helo_access. Is
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:Okay, awesome, I've added that. I didn't even think it was possible to
> 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
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.
- << Previous post in topic Next post in topic >>