289588Re: Initial 220 greeting timeout
- Nov 22, 2012On 11/21/2012 7:01 PM, Alex wrote:
> I pulled the IPs out of the logs for these 'lost connection' errorsThis is a bad assumption. The PBL lists dynamics/etc, not snowshoe IPs.
> over the last 24hrs, and it does appear that there are multiple IPs in
> the same network losing the connection. This also doesn't really prove
> much, but there are cases where there are dozens of consecutive 'lost
> connection' errors for a single IP.
> I'm sure by now it's in the PBL or SBL.
The SBL lists some snowshoe IPs, but you likely won't see a lot of
overlap with other IP based DNSBLs. Snowshoe is notorious for avoiding
traps that feed IP based DNSBLs.
> I searched for 198.41.120 and found hundreds of entries such as these:Unfortunately fail2ban doesn't work for snowshoe. The rate is
> Nov 21 19:39:14 mail01 postfix/postscreen: PASS OLD [220.127.116.11]:47864
> 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.
intentionally low, which is why snowshoe avoids most trap driven DNSBLs
> 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
hit causes a rejection. If you are FP averse, simply duplicate your
postscreen DNSBL config in SMTPD with 'WARN_IF_REJECT' and do a log
comparison to see what additional clients would be rejected. If you're
not seeing warnings on ham, go live.
> postscreen_dnsbl_sites = myhost.zen.dq.spamhaus.net*2Since Nov 18 I've blocked every connection from this /24 with a
> bl.spamcop.net*1 b.barracudacentral.org*1 psbl.surriel.com*1
> This IP is now listed in barracuda, but wasn't when it was received.
> It only hit the URIBL list.
combination of BRBL and DBL. The first attempt here from 18.104.22.168
(which you reference above) at Nov 21 17:38:30 was blocked by DBL. The
first attempt from this /24 was nailed by BRBL at Nov 18 16:57:41.
postscreen doesn't handle domains, only IPs. Your main.cf parameters
show you're not rejecting snowshoe domains via RHSBLs. You should be
using something like this
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.
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:
> Yes, I wish I had the resources for this.Check out: http://dnsbl.invaluement.com/ivmsip/
> It sounds like I should at least be doing some QoS work with tc toYour kernel is shutting down the SYN flood, which is what that kernel
> throttle the number of connections from a single IP.
message tells you, so Postfix isn't being affected, and it's probably
not doing any harm to your system, performance or otherwise. I simply
feel it would be better to shut this down at an upstream firewall.
> Yes, I definitely know that the disks in my configuration are aFor gateway/AS appliance queue duty with no local mailboxes you should
> bottleneck. If I had to do it over I would use RAID10.
seriously look at using two smallish good quality (Intel) SSDs mirrored
(with a hot spare) with a low end hardware RAID controller (allows boot,
/, and queue on the mirror device). It's cheaper and 100s of times
faster than rust in RAID10, and you simply never have to worry about an
IO bottleneck. Something like:
> There is some amount of CPU iowait, but the majority of the time theThey always will be mostly idle. You have 8 cores and 8GB RAM for an
> processors are more idle than fully utilized.
SMTP/filter workload. Such a system with a few SSDs or a very large
spindle count rusty RAID and a GbE connection could handle many hundreds
of msgs/sec, if configured properly. The performance key to the SMTP
workload has always been, and always will be, random IO throughput
to/from the queue directory and/or mailboxes.
> Thanks so much for your help. Really appreciate it.Always glad to help "Alex". ;)
- << Previous post in topic Next post in topic >>