"The table was created many years ago over an extended period of
time,...................::"
so, its outdated?
i think its better to use postscreen and a regular updated file like
DROP from spamhaus.
i refresh this DROP every hour. so maybe wrong listed candidates are
deleted in the refreshed file.
a static file can only clients "you" want to have block.
am i right?
best regrads from cloudy windy cold hanburg(germany)
marko
Am 2013-03-25 20:04, schrieb Stan Hoeppner:
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.
