On Monday, August 30, 2004, 5:57:53 AM, Rob McEwen wrote:
The quicker TTLs is helping with the savy spammers. Also, I recall something about a newer version of SURBL which will use some kind of tracking to trace new domains back to older ones in order to attributing new spam to known and confirmed spammers so that they would stay "attached" to their previous bad records in order to blacklist them faster. What ever became of this? (Did I explain this correctly?)
Yes, it's on my list of things to do. I will get to it eventually and the new system could be a basis for generalized spam domain feed handling. Where there is a real time feed of spam domains, as from SpamCop or perhaps good spamtraps, the reports can like be a voting system where more reports means more likely spam.
Basing this on human reports, as from SpamCop, is probably best since automation usually leads to too many FPs.
The idea is to take the top N percentile (probably 85th percentile) of reports, thus hopefully leaving behind the FPs in the low-level "noisy" bottom 15th percentile.
In addition the IP address of the domain will be resolved and "remembered". Future domains that resolve to the same IPs will probably inherit the report counts of the whole IP range or some fraction thereof. That will catch spammers whose web sites are on the same IPs or range of IPs.
By the way we have lowered the TTLs on the lists to 1 hour, then 25 minutes, now 20 minutes. We may try 15 minutes also. We will pick the TTL that minimizes both DNS traffic and TTL. (At some TTL point the DNS traffic will ramp up significantly; from which we will back off one time period. We already know it's quite a bit higher at 10 minutes, but not much higher at 20 minutes, so that point is somewhere in between.) We are using real world testing to find the optimum TTL for our type of data and application.
Jeff C.