On Friday, September 10, 2004, 1:13:38 PM, Jeff wrote:
JC> Thanks for your comments. By "recursive domain additions" to you JC> mean to initiate a proactive search of domains within a given JC> network? What I'm proposing is not to actively try to search, JC> but simply to bias the inclusion of domains that are *actually JC> reported to us as being in spams*.
What I mean by "recursive domain additions" (an internal name I use for this process) is something like this:
1. Spamtrap sources the addition of a domain (URI) to the blacklist.
2. A subset of domains in the blacklist are resolved to IPs and those IPs are added to an internal reference list.
3. Subsquent clean spamtrap sources are scanned for domain URI that resolve to IPs on the reference list and if found these new domains are added to the blacklist (or at least recommended as candidates).
So, this is not a proactive search really - rather the capture of one domain predisposes the candidate generator to capture additional domains that resolve to the same IP(s).
(Candidate generator = AI monitoring spamtrap data to extract URI and recommend them as candidates for the black list).
--- Sorry for the complexity here, I'm used to thinking in terms of our system and it is sometimes difficult to describe the concepts outside of that context.
JC> Hopefully my description of the difference makes some sense JC> and it can be seen why the potential for false inclusions JC> might be lower when the space is *actual spam reports*, and JC> not the space of all domains hosted in nearby networks.
Clearly. *actual spam reports* is analogous to clean spamtrap data - though I presume it may also include some non-spamtrap data submitted by users. You are definitely on the right track - that is, I think we're on the same page generally.
The caution is - even with very strong spamtraps there are errors in this process often enough to require some extra research before gating the new "candidates" into the blacklist, IME.
_M