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

Re: Postscreen DNSBL Sites

Expand Messages
  • Steve Jenkins
    ... If you meant NJABL, they ve been gone longer than TRBL, 2013-03-01 ... First, thanks for the detailed and insightful reply. Exactly the type of feedback I
    Message 1 of 67 , Apr 23, 2013
    • 0 Attachment
      On Tue, Apr 23, 2013 at 11:23 AM, /dev/rob0 <rob0@...> wrote:
      Looks very similar to mine, http://rob0.nodns4.us/postscreen.html

      > postscreen_dnsbl_threshold = 3
      > postscreen_dnsbl_sites =
      >         zen.spamhaus.org*2,
      >         b.barracudacentral.org*2,
      >         dnsbl.mjabl.org,

      What? $ whois mjabl.org
      If you meant NJABL, they've been gone longer than TRBL, 2013-03-01

      First, thanks for the detailed and insightful reply. Exactly the type of feedback I was hoping for.

      And yep - njabl IS what I meant, and I've yanked them. :)
      >         bl.spameatingmonkey.net,
      >         dnsbl.ahbl.org,

      These are highly accurate for me. AHBL doesn't list as much, but I've
      never seen it return anything questionable.

      >         bl.spamcop.net,
      >         swl.spamhaus.org*-4,
      >         list.dnswl.org=127.[0..255].[0..255].0*-2,
      >         list.dnswl.org=127.[0..255].[0..255].1*-4,
      >         list.dnswl.org=127.[0..255].[0..255].[2..255]*-6

      I'm fine with blocking for Zen alone, thus I give it 3. Of course
      it's possible to continue using it as a reject_rbl_client smtpd
      restriction, also. (I do that too. For some recipient domains I
      also reject using BRBL.)

      I also do that. Any thoughts on these settings which I currently use?

      reject_rbl_client b.barracudacentral.org,
       reject_rbl_client zen.spamhaus.org,
       reject_rbl_client bl.spamcop.net,
       reject_rbl_client psbl.surriel.com,
       reject_rhsbl_client dbl.spamhaus.org,
       reject_rhsbl_sender dbl.spamhaus.org,
       reject_rhsbl_helo dbl.spamhaus.org,

      > I'm wondering if others can recommend any other DNSBLs that I
      > should consider, or if anyone has any other feedback on my setup.

      Having watched logs awhile following upgrade to 2.11 snapshots, I
      found that PSBL and Mailspike are doing a good job. SORBS should
      definitely be there as a 1-point list; I've had that a long time,
      finding that SORBS often pushes a 2-point result over the top.

      I'm considering lowering BRBL to one point and taking it out of smtpd
      restrictions. I've had recent problems with a sender from nerim.net
      in France. I don't doubt that the global army of 'cudas has gotten
      spam from there, but a 2-point list needs to be conservative IMO.

      Again, Mailspike is looking good, and I might soon switch to use of
      rep.mailspike.net as a combined black/white list, but that will get
      ugly in the sites list. I wish they had a different set of return
      codes, i.e., a 127.0.x.x for the bad listings and 127.1.x.x for the
      good ones.

      As I recently noted on this list, the whitelist sites are mostly
      unused. There is almost no overlap between the blacklists and
      whitelists. One nerim.net host (of numerous outbounds they use) seems
      to be the only one (it's on BRBL and DNSWL.org as a .0, trust level

      You can double your threshold and scores and add in more one-point
      lists for testing. I didn't do that with my recent additions, but I
      know they have been around long enough to have some credibility. In
      that case I think a 1-point result is safe enough.

      Again, excellent advice and feedback. Thank you - I'm off to test out some of the ones you suggested!

    • 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 12:43 PM
      • 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

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