289625Re: Initial 220 greeting timeout
- Nov 23, 2012On 11/22/2012 12:39 PM, Alex wrote:
> Hi,Again, the IP in question will never be listed in the PBL. SBL maybe,
>>> 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,
PBL no. Might be time to brush up on Spamhaus various lists and their
>>> They were later all tagged as spam, but it would definitely be nice toFail2ban doesn't stop spam. It merely shifts the burden of rejection
>>> 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.
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
> Just to confirm mySomeone else will need to answer this.
> 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?And decreased the load on your content filters as well, I presume, and
>> 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.
likely decreased or eliminated your 220 delay issue.
> I've also added the reject_rhsbl_reverse_client and other rhsblYou're using SA which makes all of these same DNSBL lookups. So you're
> 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.
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 falseRHSBL restrictions trigger on domains, not IPs. Domains that end up on
> positive IPs in multiple places for now too.
domain based block lists or URI block lists rarely, if ever, send legit
> When I was working on this in 2010 (how the hell did you rememberIt's obviously always best to stay close to current.
> 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 =I always put my least expensive restrictions first and most expensive
>> 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.
> 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?
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
> I think I like postscreen better than the rhsbl statements because ofFuzzy dice hang'n on your mirror don't make the car go faster. If you
> the additional features of postscreen.
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
>> I just noticed you don't require HELO. So you need this as well:I'm not sure if the latest SMTP RFC requires HELO/EHLO or not.
>> 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
> Okay, awesome, I've added that. I didn't even think it was possible to
> send mail without that.
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 greatPrices should be a little lower by then as well, at least for the SSDs.
> 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.
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
> Thanks again,Always glad to help.
- << Previous post in topic Next post in topic >>