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

292187Re: dictionary-attack

Expand Messages
  • Stan Hoeppner
    Mar 25, 2013
    • 0 Attachment
      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
    • Show all 48 messages in this topic