I agree. To catch the fast-flux servers you have to check not only low ttl values but ALSO how frequently the IP addresses assigned to that domain change.
I think everyone is looking for a fast fast-flux fix. I believe, and this is just my opinion, that a dnsbl is the way to go. That way if the people maintaining the dnsbl have their systems constantly checking for the variables that identify a fast-flux domain: 1. Short TTL 2. Numerous A records 3. IP addresses changing frequently the dnsbl will avoid false positives and still provide a high-level of accuracy in identifying the fast-flux domains. I believe that not checking for everyone of these will lead to erroneous domains being blocked. That's just my opinion, I could be wrong. (Dennis Miller) -----Original Message----- From: Bob Proulx [mailto:[EMAIL PROTECTED] Sent: Saturday, August 11, 2007 7:05 PM To: users@spamassassin.apache.org Subject: Re: Detecting short-TTL domains? Kai Schaetzl wrote: > Jo Rhett wrote: > > Yes, but this also means that it takes longer to fix false positive > > problems. How would one clear this out if the original problem was > > fixed and you wanted to receive the mail? > > By using some whitelist for legit low-ttl domains. I think it is a bad idea to use low-TTL values as more than a minor spamsign. There is nothing overtly improper about it and there are often times when a low TTL dns record is just the right thing to do, such as when planning an IP move for a server. That should not cause mail to be tagged as spam in those cases. While it may be that there is some correlation to some spammers using low TTL servers it is also true that good spam filtering has always been about reducing false negatives. A false negative is much worse than a false positive. Using low TTL dns records, a perfectly valid configuration, as a strong spam indication will cause false negatives, which is creates a cascade failure which is much worse than the original problem. Trying to create workarounds such as maintaining whitelists for noted servers is going about this the wrong way. It is perfectly valid to do and so this would legitimately need to list all possible servers. In fact a small time operator who is setting up and planning moves would most likely to be using low TTL values and would be unlikely to be in random whitelists. Bob