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
