Mike Cardwell writes:
>> 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?
This is from Tom when he evaluated it. I would recomend contacting him for
details on his specific configuration.
DynaStop is now very stable.
> 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.
See the thread in the Exim archives with Marc Perkel and many others
discussing the fact that spam zombies are using retry methods to bypass
greylisting.
False positives are subjected to each system and its specific configuration.
I have personally encountered 5 false positives. Tom has a whitelist that
he has graciously contributed with a list of false positives he has
encountered. I get updates from DNSWL everyday to minimize the false
positive rate. These updates go online as well. Here is the updatelist for
today:
* The BleedingThreats List can be downloaded by clicking here. Last updated
on Monday, August 06, 2007 at 04:38:25 AM.
* The DNS WhiteList can be downloaded by clicking here. Last updated on
Monday, August 06, 2007 at 04:38:26 AM.
* The CompleteWhois Bogons List can be downloaded by clicking here. Last
updated on Sunday, August 05, 2007 at 04:37:28 AM.
> 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.
If DynaStop is used to deny messages (after proper testing), then the
resources are much less on spamassassin as there will be less messages for
it to scan.
> 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
SBL/XBL is comparable to DynaStop's NoMail verb (BleedingThreats/Bogons)
extries.
PBl is directly in line with DynaStop's dynamic IP address identifications.
from
http://www.spamhaus.org/pbl/index.lasso
"The Spamhaus PBL is a DNSBL database of end-user IP address ranges which
should not be delivering unauthenticated SMTP email to any Internet mail
server except those provided for specifically by an ISP for that customer's
use. The PBL helps networks enforce their Acceptable Use Policy for dynamic
and non-MTA customer IP ranges."
The comparitives are accurately compared to the functions of zen.
The "valuable" part is the ability to examine patterns in identifying the
dynamic IP address space.
In terms of updates and corrrections, thay take effect immediately after the
DynaStop server receives a HUP signal. Cached items are re-evaluated based
upon the changes and appropriate actions taken. Changes in RBLs can take as
much as 48 hours to propagate (based upon the basic funnctions of a DNS).
---
DynaStop: Stopping spam one dynamic IP address at a time.
http://tanaya.net/DynaStop/
