Mar Matthias Darin wrote:
>> 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.
A very small minority of them. Hence why I wrote "it's more than likely"
> 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.
I was looking for a percentage or a ratio, total mail throughput,
graphs, comparisons against other filters. Not "5 false positives" which
is a meaningless figure.
>> 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.
I was asking for total resource usage of dynastop+spamassassin vs
spamassassin+fuzzyocr. Not, total cpu usage of spamassassin scanning
lots of messages vs spamassassin scanning less messages.
>> 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?
You forgot to address the question that I marked as the question that
needs to be addressed more than anything.
>> 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 PBL is not a list of dynamic IP addresses.
The PBL is a list of IP space that should not send Spam according to the
people who control that IP space, or according to Spamhaus. It can even
contain static IPS. There are automated methods of getting your IP
removed from that list. They're not comparable.
> The "valuable" part is the ability to examine patterns in identifying the
> dynamic IP address space.
The pattern list looks vaguely interesting. It would be better provided
as an RHSBL though so people just have to add something along the lines
of the following config to Exim rather than installing all this cruft:
"deny dnslists = rhsbl.dynastop.dom/$sender_host_address"
Rather amusingly, using DynaStop requires at least as many DNS lookups
as using a DNSBL would because it forces a reverse DNS lookup, where as
using a DNSBL you do a single A record lookup.
> 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).
Looking at the lists you provide:
BleedingThreats would be more useful as an RHSBL
Bogons would be more useful as a DNSBL
Whitelist would be more useful as a DNSWL
Mike
