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

Re: Postscreen DNSBL Sites

Expand Messages
  • David Benfell
    ... Hash: SHA1 ... First, thanks for introducing me to postscreen. Since I moved my domains to a dedicated server in Germany, I ve been getting hammered with
    Message 1 of 67 , Apr 23, 2013
    • 0 Attachment
      -----BEGIN PGP SIGNED MESSAGE-----
      Hash: SHA1

      On 04/23/2013 10:42 AM, Steve Jenkins wrote:
      >
      > This setup has been working pretty well for me, and reduces false
      > positives by not allowing any single DNSBL to block an incoming
      > connection without concurrence from at least one other DNSBL.
      >
      First, thanks for introducing me to postscreen. Since I moved my
      domains to a dedicated server in Germany, I've been getting hammered
      with spam, so second, I've been testing this out, minus the mjabl
      entry, and it seems to have stopped the spammers in their tracks. I'm
      not going to claim it's optimum, because I don't know, but it works
      *very* well.

      -----BEGIN PGP SIGNATURE-----
      Version: GnuPG v2.0.19 (GNU/Linux)
      Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

      iQIcBAEBAgAGBQJRd1itAAoJELJhbl/uPb4SYOQQAJIF7mYgy0ipZC0SekcsrjKM
      QOp9IHDGAuKnvN4U5uPhyJc7M17JGOijf4SUc8PX148EsIL85ytKlr1xMyxuvNlX
      RLoetJGXmditRYfH2pRjHibMs5RuZN+k5auDyG9OEXZebo+YC3KwdRJiAy5pKi+V
      H+EFtD5QGQ1EKslQNFYdm1Yp5JDs2qOiWKe9/imBPw3KxN86wJwMP2MnLG5cEg+s
      W9dDQsOBccJU25W3XZO362lBP5MMRlBDwMWx2ijW2dDGaJBuQu2ZtDbUa/apY0r9
      nl74QUUZdU741YHk6l31wF8Hj3tsJKLYrEOBm1A+VoUbj1kWWugMUEoH1hT14U5V
      L8SjT7IPOhy310pMLoThZWb+mS7VBBb3C82m6TJjqd93ekx2dsl9uH6TzTwcIlPS
      aVPZ0bpUJzzZSIXhaPTbFCx+3Na7oMQOCWUT5Esrqpgs9LgHxF7NrmkvVbUDOtbT
      o4siP6TGTB39egv1DCDSIC/hiolCkXidY54eHMi2fgDfvH3f8AsHudGyaXGa71YF
      DZPauec43avRp6rN2uedg+aiRg4eSTT6vMRvvI1dp0nU22ugZRwEkXWcWodmppR3
      /vv0I0os+G5G689IvbuXb9kEerNXTU8RBonFyZehaG55EkoRDP1cfBgj0lKPL5Sj
      vtPVE/fSDqggYOm0Qi7d
      =wFOx
      -----END PGP SIGNATURE-----
    • Stan Hoeppner
      ... permits always come before rejects . Thus whitelist type entries should always be at the top of the restrictions list. As you are using
      Message 67 of 67 , May 14, 2013
      • 0 Attachment
        On 5/14/2013 11:45 AM, Steve Jenkins wrote:
        > On Tue, May 14, 2013 at 8:33 AM, /dev/rob0 <rob0@...> wrote:
        >
        >> On Tue, May 14, 2013 at 07:49:50AM -0700, Steve Jenkins wrote:
        >>> smtpd_recipient_restrictions =
        >>> reject_invalid_helo_hostname,
        >>> warn_if_reject reject_non_fqdn_helo_hostname,
        >>> reject_unknown_reverse_client_hostname,
        >>> warn_if_reject reject_unknown_helo_hostname,
        >>> check_reverse_client_hostname_access
        >> pcre:/etc/postfix/fqrdns.pcre,
        >>> check_helo_access hash:/etc/postfix/helo_access,
        >>> check_sender_access hash:/etc/postfix/sender_access,
        >>> reject_rbl_client zen.spamhaus.org,
        >>> reject_rhsbl_client dbl.spamhaus.org,
        >>> reject_rhsbl_sender dbl.spamhaus.org,
        >>> reject_rhsbl_helo dbl.spamhaus.org,
        >>> permit_dnswl_client list.dnswl.org=127.0.[0..255].[1..3],
        >>> permit
        >>
        >> The last two lines are no-op. If you have anything you want to be
        >> subjected to the list.dnswl.org whitelist, put it after the
        >> permit_dnswl_client. If not, there is no point in querying it.
        >
        >
        > Excellent point. If the next step is going to "permit" anyway, then no use
        > in the extra query. I've moved the dnswl.org line up so that it's just
        > above the three "local" check_* lines.

        "permits" always come before "rejects". Thus whitelist type entries
        should always be at the top of the restrictions list. As you are using
        (client|helo|sender|recipient) sections any whitelisting in
        smtpd_recipient_restrictions should typically be at the very top.

        permit_dnswl_client list.dnswl.org=127.0.[0..255].[1..3]
        ^^^^^^ ^^^^

        This shows you are explicitly permitting anything/everything listed in
        the dnswl. Are you sure that is what you want? I use...

        permit_dnswl_client list.dnswl.org=127.0.[2..14].[2..3]

        which does not explicitly permit email marketing providers nor any IP
        with trustworthiness score of 1. A score of 1 is equivalent to a
        SpamAssassin score of -1, which does not merit a direct shot to the
        queue. That would typically require an SA score of -5. I want these
        clients to go through all of my other restrictions before allowing their
        payload into my queue.

        Also worth noting, there are currently only 14 categories (3rd octet of
        a reply), so specifying 255 is not necessary, and possibly problematic.
        Hypothetically, if dnswl decided one day to create categories 16,
        political campaigns, and 17, religious newsletters, you are currently
        setup to automatically permit such clients.

        Remember, the sole purpose of whitelisting is to bypass all of your
        other spam checks and get the mail into your queue unmolested. IMO, not
        every IP listed by dnswl is deserving of this honor, not even close to
        all of them.

        See section "Return codes" at: http://www.dnswl.org/tech

        --
        Stan
      Your message has been successfully submitted and would be delivered to recipients shortly.