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

Re: dictionary-attack

Expand Messages
  • Stan Hoeppner
    ... Precisely. Let me add that ISPs introduce new consumer rDNS strings very infrequently. Thus, the table doesn t change very often, as it already has most
    Message 1 of 48 , Mar 28, 2013
      On 3/28/2013 8:03 AM, /dev/rob0 wrote:

      > "... maintaining it ..." see? I would think that something which is
      > maintained generally isn't outdated. Depends how well the maintainer
      > maintains it, of course.

      Precisely. Let me add that ISPs introduce new consumer rDNS strings
      very infrequently. Thus, the table doesn't change very often, as it
      already has most dynamic/generic patterns used by ISPs for consumer
      endpoints. When I come across a new rDNS string, or one is reported by
      a user, I add a regex to match it. In the past twelve months I'd guess
      I've added maybe a half dozen patterns at most.

      > Not entirely. Think of Stan's PCRE list as a compact, local version
      > of Spamhaus PBL. It lists patterns which have been identified in
      > reverse DNS names for dynamic hosts, which should not be sending
      > mail.

      Dynamic, but also generics that may/not be dynamic. It also has
      patterns matching generic static rDNS, which return a PREPEND action
      instead of a reject. This can be used for scoring in a policy daemon or
      content filter. This table serves the same purpose as the PBL, but
      using a different method: rDNS instead of IP address.

      > If you are checking PBL, or more likely, Zen (which includes PBL),
      > you're not likely to benefit much from Stan's PCRE list, except for
      > those networks which slipped through the PBL cracks.

      There are quite a few PBL doesn't list, or at least this used to be the
      case. Also, as we've discussed, a query to this table takes <100 ┬Ás. A
      DNS query to Zen takes from 10-100ms, assuming you're not a data feed
      customer serving the zones locally. So fqrdns has a big latency
      advantage, and it can dramatically decrease DNS packet traffic.

      Worth noting here is that fqrdns and things like it decrease the burden
      on the world's dnsbl servers. While this doesn't benefit MTA operators,
      it benefits dnsbl operators. Bandwidth costs money.

      > But there too,
      > you can also use it as a HELO check after postscreen (things that
      > make you go "hmmm": postscreen is actually a prescreen!)
      ...
      > If postscreen DNSBLs are your only protection, what happens if your
      > DNS breaks? Spam flood! Here too, Stan's PCRE list can help, again,
      > at least as a HELO check (client name checks won't fire if DNS is
      > gone.)

      And many people use the table for HELO checks as well for this very
      reason. Spambots quite often do a PTR lookup on the local IP and use
      the rDNS name in the HELO string.

      > Consider the "onion" approach, multiple layers of protection. When I
      > went to postscreen I left all my old spam restrictions alone. On rare
      > occasions I have seen where they are used.

      Layered, exactly. And the cost of leaving them enabled is miniscule.

      > All that said, I personally have not used Stan's PCRE list, but I've

      So much for that layered defense Rob. ;)

      > seen it discussed here and elsewhere for a lot of years. I guess that
      > means I'm outdated also. ;)

      It lost much of its appeal when Wietse introduced Postscreen due to the
      overlap of coverage. It does have three advantages over Postscreen.

      1. Ease of implementation. One line added to main.cf. You don't have
      to touch master.cf, configure dnsbl sites, nor turn any other knobs.
      It's great for low volume MXen. Postscreen was designed to keep
      spambots from tying up smtpds. If you're smtpds aren't being tied up
      then fqrdns is an easier option.

      2. Usable with any Postfix version--Postscreen requires 2.8+

      3. It will reject a connection from consumer land even if the sending
      client is a valid MTA, not a bot. Postscreen lets these through unless
      the IP is listed in a postscreen dnsbl. Recall that the first convicted
      US spammer, Jeremy Jaynes, had 6 aDSL lines to his house and was using
      real MTAs to send his spam.

      --
      Stan
    • Benny Pedersen
      ... add permit_sasl_authenticated before fqrdns.pcre testing -- senders that put my email into body content will deliver it to my own trashcan, so if you like
      Message 48 of 48 , Apr 7, 2013
        On 2013-03-27 23:11, Matthew Hall wrote:

        > I ran into a bit of an issue trying out fqrdns.pcre as recommended
        > here in this thread. The header in the file recommended adding it
        > into
        > smtpd_client_restrictions. However if I place it there, I end up
        > rejecting mail even from SASL authenticated client devices, if they
        > also match a rule in fqrdns.pcre.

        add permit_sasl_authenticated before fqrdns.pcre testing

        --
        senders that put my email into body content will deliver it to my own
        trashcan, so if you like to get reply, dont do it
      Your message has been successfully submitted and would be delivered to recipients shortly.