Mar Matthias Darin wrote:
>> Doesn't using DynaStop involve calling an external executable using
>> ${run} which reads several flat files and uses up IPC shared memory in
>> order to obtain relatively stale results?
>>
>> In what regard does DynaStop provide any advantage over using a plain
>> dnsbl? The guy is trying to reduce the time exim processes run, not
>> increase them...
>
> DynaStop does use shared memory for the cache that expires after 24 hours or
> the oldest entry remove in the case of it being full. The "flat files" are
> heavily maintained (some updated daily) The results are hardly stale as any
> "new" IP addresses are looked up in realtime. New being defined as not in
> its cache.
>
> The advantages are thus:
>
> DynaStop is light and faster then spamassassin,
Presumably because it does an entirely different job, which is nowhere
near as complex and has an entirely different purpose?
> see http://tom.knaupp.com/?p=9
This confuses me: "Although the software is still in beta status, I use
it in my company to kick out the rest of unwanted connections that are
not recognized by RBLs (i.e. zen.spamhaus.org) or those that “survive”
greylisting."
The way you order your tests suggest that you consider dynastop to be
more expensive than using an external dnsbl, and also greylisting?
Also. The whole reason you might block dynamic IP space is because you
want to reject spam zombie software running on peoples home machines
right? If it's already passed greylisting, then it's more than likely
not zombie software... I'd be interested to see the false positive rates
there at the moment as I doubt they're that great.
> Reduced load to spamassassin means the availability of tools like fuzzyocr
> can be deployed. DynaStop can also be used to aid in the training and
> accuracy of spamassassin (or dspam).
I'd be interested to see how the following two compare:
1.) Run Dynastop executable on every message, followed by running
SpamAssassin
2.) Run SpamAssassin including the Fuzzyocr plugin. Fuzzyocr only runs
on spam messages with images attached, when the other rules haven't
already pushed it over the min score required.
I'd guess that #2 takes less resources.
> DynaStop catches more IP addresses then the RBLs. See the following:
>
> http://tanaya.net/DynaStop/IPComparitive.html
>
> http://www.exim-users.org/forums/showthread.php?t=54012
>
> Of the 373,302,000 IP addresses tested (Aug 1/07) 85% (317,306,720) where
> evaluated to be dynamic. The estimated 10% ligitimate mail servers that use
> dynamic IP addresses (based upon user feedback) can easily be excluded
> leaving 279,976,512 IP addresses (potential spam zombies) that will be
> blocked/tagged by DynaStop.
If it were purely down to numbers of IP addresses listed, everyone would
be using Apews. Fortunately, most e-mail admins aren't that mad.
Ok. Here's the question that needs to be addressed much more than
anything I've said above. For arguments sake, we'll say the data
provided with DynaStop is more useful than any of the other dnsbl's out
there. Please explain why it uses such a convulated, inefficient,
"non-standard" system to perform lookups on the data, rather than using
a dnsbl? The valuable part of the system is the list of IPs right?
Also, please don't compare DynaStop against zen.spamhaus.org
DynaStop lists dynamic IP space
Zen.spamhaus.org includes 3 separate lists including:
1.) pbl - Lists of IPs that shouldn't be sources of email
2.) xbl - Lists of IPs that have hosts which have been exploited to send
spam
3.) sbl - Lists of IPs that have been seen to send spam
They have entirely different purposes.
Mike (Unconvinced)
