[Spambayes] full o' spaces
Tim Stone - Four Stones Expressions
tim at fourstonesExpressions.com
Fri Mar 7 13:49:13 EST 2003
This is a great discussion. We really should hash this out to everyone's
3/7/2003 1:42:34 PM, Neil Schemenauer <nas at python.ca> wrote:
>Tim Stone - Four Stones Expressions wrote:
>> The fallacy here is that you're assuming that spammers will simply give up.
>> They won't. And a set of eyeballs looking at a mail, even if they stop
>> reading after the first line, is better than no eyeballs.
>I have to respectfully disagree. Spammers _need_ people to respond to
>their spam. If a filter avoidance trick kills the response rate they
>will stop using it. There is no point in bloating spambayes with every
>failed trick they try.
This really wasn't what I was suggesting. Rather, when we find a significant
hole through which effective spam can squirt, we should plug it, rather than
wait to see if any spammers find that same hole.
> That's why I suggested testing with a real
>corpus. If a trick is common enough that detecting it signficantly
>affects the error rate then fine, add code for it. Otherwise, forget
>about and keep spambayes lean and mean.
>> So they'll keep trying things to defeat the algorithms, especially if
>> their response rates are dropping.
>Sure. However, they will only continue using a trick if it defeats
>filters _and_ gets an acceptable response rate.
If it defeats the filters then the response rate, however dismal, will be
better than for spam that doesn't defeat the filters.
>> This strategy, which has been employed by the spambayes team up to this
>> is very useful for research, but is quite reactive. We're exiting the
>> research phase of this project, and entering a product phase. Reactive
>> strategy is not appropriate for products (e.g. Microsoft security).
>I disagree. We should not abandon the rigorous, testing based strategy
>that got SB to its current state.
Absolutely. Rigorous testing is not the issue at all, in my mind.
> Adding more code every time a spammer
>comes up with a new trick is completely reactionary and will eventually
>destroy the code base. I'm mystified as to how you can call such an
Again, I was suggesting that we find the holes before they do. I think that
we should begin to think like spammers, not like people trying to defeat
spammers. If we were on the other side, what would we do? Gosh, I can think
of things, simple things. And if I can find something that actually crashes
the tokenizer, all the better. I'll look at the code, more closely than most
on this team ever will. I'll find the holes, and blast away. My goal? Not
to get spam into mailboxes, but to destroy the anti-spam community. Make
people give up hope that this problem really is/can be solved. That's the way
to make you and me go away. Simply make it so people don't believe in us.
>> We must be proactive, and kill ideas before they become widespread in
>> the spammer community.
>We don't need to worry about spammers' ideas that will be killed by
>other forces. Perhaps it comes down to a question of objectives. If
>your objective is to keep spam out of your mailbox then trying to detect
>all spam, effective or not, makes sense. My objective is to destroy the
The two objectives are identical.
> One way to do that is to have a widely deployable filter
>that blocks spam that would make spammers money. Honestly, for me to
>hit delete for a few spam messages in my inbox is not a big deal. It is
>the fact that these people are wasting millions of people's time.
c'est moi - TimS
More information about the Spambayes