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

Re: dictionary-attack

Expand Messages
  • Stan Hoeppner
    On 3/25/2013 8:52 AM, Noel Jones wrote: ... The table was created many years ago over an extended period of time, by staff at a US ISP, composed of fully
    Message 1 of 48 , Mar 25, 2013
      On 3/25/2013 8:52 AM, Noel Jones wrote:
      ...
      >>> are you missing http://www.hardwarefreak.com/fqrdns.pcre ? :)
      >>
      >> very interesting link, as I understand my postfix is not prepared for
      >> pcre thus I won't be able to use it, right?
      ...
      > You can use this file as a regexp: type.
      >
      > pcre is recommended as it's a little faster than the built-in regexp
      > library on most systems.

      The table was created many years ago over an extended period of time, by
      staff at a US ISP, composed of fully qualified POSIX regular
      expressions, some 1400 or so, and used with the Postfix REGEXP facility.
      When I began maintaining it and offering it publicly some years ago I
      cleaned up a few errors so it would execute via Postfix PCRE, which is
      faster as Noel mentions. This is why I publish the file with a .pcre
      extension and recommend it be used this way.

      The few hundred expressions I've added should also be POSIX regex
      compliant. Thus it should still execute just fine via the Postfix
      REGEXP facility, albeit slightly slower. How much slower? On modern
      hardware the table easily fits in L2/L3 cache. With only ~1700
      expressions, about half of these being skipped on each pass due to
      conditional tests, the difference between PCRE and REGEXP processing
      time will be something like up to a few 10s of microseconds.

      Thus one may ask, "Why does it really matter then?" On a low volume
      server it makes no difference. However, on a high volume server the
      execution time of all combined restrictions adds up quickly, and if the
      server is doing content analysis (SpamAssassin) that burns a ton of CPU.
      Thus it's best to keep individual table execution time to a minimum.
      This is also why the table uses mostly fully qualified expressions.
      Each requires far fewer CPU instructions than wildcard matching.

      --
      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 12:40 AM
        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.