Re: RBL Usage questions

From: Stan Hoeppner (no email)
Date: Sun Apr 11 2010 - 00:16:51 EDT

  • Next message: Ralf Hildebrandt: "Re: RBL Usage questions"

    Alex put forth on 4/10/2010 7:28 PM:

    >> smtpd_recipient_restrictions =
    >> ...
    >> reject_rbl_client
    >> reject_rhsbl_client
    >> reject_rhsbl_sender
    >> reject_rhsbl_helo
    > I'm familiar with zen, but I believe the dbl is relatively new,
    > correct? What other URI BL lists do people use?

    The dbl is somewhat unique in that it's not just a uri domain list. It also
    contains domain names that directly send spam. This is how I use the dbl.
    It stops a few spam, and every little bit counts.

    > Can these postfix restrictions be used with older versions of postfix?
    > I have a few systems with older versions and can't upgrade right now.

    I'm not sure about all of them. Check yourself here:

    >> I reject most spam via other methods, mostly pcre/regex and cidr tables. My
    > Can you tell me more about rejecting using cidr tables? Do you mean
    > the bogon list or ASN numbers? I seem to remember a downloadable list
    > of the top 10 ASNs that could be used to add weight to an SA score.

    I've built a cidr table over the last couple of years of mostly showshoe
    networks that have spammed me. I also use cidr ranges to block
    all smtp connections from certain countries. The combined list is
    approximately 12,000 cidr entries from /12s to /24s. In my case these are
    implemented as:

    smtpd_recipient_restrictions =
            check_client_access proxy:${cidr}/spammer

    >> dnsbl queries reject less than 1% of my spam load. Plug the following
    >> dynamic/generic rdns regex table into your Postfix configuration and see if
    > But isn't it really a subset of just downloading a current zen zone
    > and querying against that?

    I don't have data feed access to zen, so it would be impossible for me to
    answer that question. Considering what the regex looks for, the only likely
    overlap would be with the pbl. I've never tested the overlap. Even if the
    overlap was 100%, local determination is a better solution for a number of
    reasons, including response time and dnsbl query load. In my opinion, it's
    better to make an accept/reject determination locally and only query a dnsbl
    when a local determination can't be made. dnsbl lookups are the 2nd to the
    last test in my config, greylisting being last. My MX MTA makes very few
    dnsbl queries.

    > How do you update it? Manually? That doesn't sound feasible for a
    > larger network or without having some type of procedure for keeping it
    > updated surrounding it. What type of network do you have it running
    > on?

    Most networks don't change their reverse naming conventions once they've
    established them. Once the pattern is identified, it doesn't really need
    maintenance. If an organization does add or change rdns patterns, the only
    downside is you won't catch those, but you still get no FPs.

    >> it catches some spam for you. It does a good job here. Given its size I'd
    >> recommend running it (and all your map files) via proxymap. Ask here if
    > Can you include information on proxymap and postfix for me to read?

    I'll be nice since this bit me on the first attempt, instead of allowing you
    to make the same mistake. When you modify this list by declaring it in, you have to include the entire default list, and then add the
    additional tables you want to have read via proxymap. Hence this reference
    in the documentation: "proxy_read_maps (default: see "postconf -d" output)"
     The postconf -d output gives you the default proxymap list. Note that the
    ones I added begin with "proxy:". The $(cidr) is merely a reference to a
    variable I declared to shorten long lines.


    proxy_read_maps = $local_recipient_maps $mydestination $virtual_alias_maps
    $virtual_alias_domains $virtual_mailbox_maps $virtual_mailbox_domains
    $relay_recipient_maps $relay_domains $canonical_maps $sender_canonical_maps
    $recipient_canonical_maps $relocated_maps $transport_maps $mynetworks
    $sender_bcc_maps $recipient_bcc_maps $smtp_generic_maps $lmtp_generic_maps
    proxy:${cidr}/countries proxy:${cidr}/spammer proxy:${cidr}/misc-spam-srcs

    smtpd_recipient_restrictions =
            check_client_access proxy:regexp:/etc/postfix/fqrdns.regexp
            check_client_access proxy:${cidr}/countries
            check_client_access proxy:${cidr}/spammer
            check_client_access proxy:${cidr}/misc-spam-srcs

    >> This regex file is free for anyone to use if you wish to. The FP rate
    >> should be zero since it matches only dynamic/generic rdns names.
    > I guess that depends on what you consider a FP, right? IOW, I'm not
    > currently outright rejecting mail from unknown hosts, and it's very

    Is it possible to get an FP from a consumer broadband rdns? Very unlikely.
     Depends on your particular MX and those people sending you email. Do you
    accept email directly from vanity servers on dynamic IP dsl or cable
    connections? If not then your FP rate with this regex is zero.

    > likely that some road-warriors could be sending from their desktops,
    > and that would impact them here, right?

    No, not at all. Your users should already be submitting their email for
    delivery via TCP 587, commonly known as the "submission port", NOT to your
    MX on TCP 25. Typically one should never implement anti-spam measures such
    as those described above on the submission port. User submission requires a
    valid username and password, unlike standard SMTP mail, so you don't need
    hefty A/S countermeasures on the submission port. MX mail and user
    submission mail should always be separated by at least the service port, if
    not by physical machine. Implement the hefty A/S on MX TCP 25, not on
    submission TCP 587.

    If you're doing both types of mail on TCP 25 on your MX, then you need to
    change that to the proper configuration ASAP separating user submission to
    another port or machine. If this requires your users changing their MUA
    configuration, then so be it. It's something that really needs to be done.
     You should be beginning to understand at minimum one of the reasons why.
    There are many others.

    > Lots of questions, so I sure appreciate your help.

    Hope I was able help. If anything isn't clear, ask and myself or others
    should be able to get you on the right path.


  • Next message: Ralf Hildebrandt: "Re: RBL Usage questions"

    Hosted Email Solutions

    Invaluement Anti-Spam DNSBLs

    Powered By FreeBSD   Powered By FreeBSD