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
