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

289681Re: Initial 220 greeting timeout

Expand Messages
  • Alex
    Nov 27, 2012

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

      Yes, I didn't fully understand that dynamics aren't listed in the PBL.

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

      I thought the IP layer would be more efficient than filtering it at
      the postfix application layer, and also would then not have to
      specifically worry about whether it was part of a snowshoe botnet or a
      single hacked IP.

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

      Yes, I haven't seen any further indication of 220 delay issues. I also
      still have a few too many header checks that I'll be purging.

      >> 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 meant that if I kept postscreen running, I would have the lookups there too.

      >> 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 meant that postscreen has extra functionality such as the protocol
      tests before and after the 220 greeting.

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

      I've actually given more thought to doing this sooner on the secondary
      box. However, I can't find any 3.5" SSD SATA disks that will fit in my
      existing 1U SATA chassis. Any ideas? Here's the newegg link you sent:


      I thought I could use the existing SATA controller on board with the
      Linux md RAID5.

    • Show all 15 messages in this topic