Tony Earnshaw wrote:
Tom Allison wrote:
[...]
What about the tokens and the signature from the first instance?
What are the chances that I could do this without doing data integrity
damage or suffering other inconsistencies in performance?
If it had been such a good idea, don't you reckon that Jonathan (who
after all wrote dspam in the first place) would have "stumbled" on it
long ago?
--Tonni
If that was the case then why would I consider the wheel since someone might
have stumbled on that one too...
I was working on a few assumptions:
a token is a representation of essentially a regex match in either case, CRM114
or Bayes. Any overlap is purely coincidental.
How you manipulate the tokens, based on history, is dependent upon the method of
calculation, markov/chi-square/naive, but they are dependent on the same base
history of good/bad messages and good/bad tokens.
So a signature can consist of both naive derived tokens and SPBH derived tokens.
Any learning or correction of that token will be to apply a correction to the
historical count (+1/-1) in either case. So the data and it's history remains
consistent.
The more variations you can deploy in checking for spam the better the chances
that something will get trapped.
The biggest advantage that dspam can provide is a lighter weight naive or
chi-square determination, removing some of the more obvious spam via quarantine,
followed by the slower CRM114 methodology to further determine what's left over
from the bayes determination.
It probably won't work because there just isn't enough data captured about the
tokens. But if it was truely a bad idea then why do so many people use multiple
filters to capture spam?
