Bill Landry wrote: > This issue has been unresolved for way too long. All of this, in my > mind, this makes the plugin orphaned and unusable if not patched with > Mark's patch.
No matter how hard you try to improve botnet: (A) botnet is still dependent on third party dns servers, many of which are poorly configured, overburdened, squeezed of bandwidth, etc. (B) Even if that were not true, botnet:STILL won't ever "scale" that particularly well (C) By design, botnet is always going to be "asleep at the wheel" with regards to correcting its own mistakes. What i mean by this is that... consider a DNSBL which misfires on certain IPs on rare occasions due to part poor rDNS configurations of the senders... so that the sender is at least partly to blame.... BUT... where it is determined that listing the IP would block little-to-zero spam, and would generate many FPs. With a well-run DNSBL, there is a feedback mechanism to the DNSBL operator--often the sender can get alerted to their problem--and the sender has a means to figure out the source of their problems more easily--and once that feedback (from senders or recipients) gets back to the DNSBL operator, an exception can then be made for such IPs so that they can then stay off the dnsbl. Botnet doesn't have these types of checks-and-balances or feedback mechanisms which lead to critical and justifiable adjustments for some of those exceptional cases. Not that botnet isn't useful... and I think the concept is wonderful and the author should be praised... but anyone trying to use the botnet plugin as the "end all" replacement for DNSBLs, or the "bridge all gaps" from their existing DNSBLs' shortcomings... should be aware of these limitations I mentioned. -- Rob McEwen http://dnsbl.invaluement.com/ r...@invaluement.com +1 (478) 475-9032
