Loading ...
Sorry, an error occurred while loading the content.

289588Re: Initial 220 greeting timeout

Expand Messages
  • Stan Hoeppner
    Nov 22, 2012
    • 0 Attachment
      On 11/21/2012 7:01 PM, Alex wrote:

      > I pulled the IPs out of the logs for these 'lost connection' errors
      > 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.

      This is a bad assumption. The PBL lists dynamics/etc, not snowshoe IPs.
      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:
      >
      > Nov 21 19:39:14 mail01 postfix/postscreen[9111]: PASS OLD [198.41.120.10]: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.

      Unfortunately fail2ban doesn't work for snowshoe. The rate is
      intentionally low, which is why snowshoe avoids most trap driven DNSBLs
      as well.

      > 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*2
      > 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.

      Since Nov 18 I've blocked every connection from this /24 with a
      combination of BRBL and DBL. The first attempt here from 198.41.120.10
      (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

      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.

      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

      > 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 to
      > throttle the number of connections from a single IP.

      Your kernel is shutting down the SYN flood, which is what that kernel
      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 a
      > bottleneck. If I had to do it over I would use RAID10.

      For gateway/AS appliance queue duty with no local mailboxes you should
      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:

      http://www.newegg.com/Product/Product.aspx?Item=N82E16816103229
      http://www.newegg.com/Product/Product.aspx?Item=N82E16820167120

      > There is some amount of CPU iowait, but the majority of the time the
      > processors are more idle than fully utilized.

      They always will be mostly idle. You have 8 cores and 8GB RAM for an
      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". ;)

      --
      Stan
    • Show all 15 messages in this topic