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

289618Re: Initial 220 greeting timeout

Expand Messages
  • Alex
    Nov 22, 2012
    • 0 Attachment

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

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

      I have fail2ban working with dnsblog. It may not necessarily work for
      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?
      > 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.

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

      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?

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

      Okay, awesome, I've added that. I didn't even think it was possible to
      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.

      Thanks again,
    • Show all 15 messages in this topic