[Spambayes] full o' spaces
Tim Stone - Four Stones Expressions
tim at fourstonesExpressions.com
Sat Mar 8 19:35:35 EST 2003
3/8/2003 7:23:14 PM, "T. Alexander Popiel" <popiel at wolfskeep.com> wrote:
>In message: <RQ8621Y61JG6ZYX2D0OM54JFHCZT07.3e6a70d0 at myst>
> <tim at fourstonesExpressions.com> writes:
>>3/8/2003 3:18:55 PM, Paul Moore <lists at morpheus.demon.co.uk> wrote:
>>>> Ok, I'm off my soapbox. <smile> This has been a great discussion.
>>>Can I borrow that box for a moment? Thanks... :-)
>>I yield the floor.
>Okay, I'll grab the box for a moment...
>>>If you liken the spambayes
>>>approach to an anti-virus strategy, it suddenly looks much better :-)
>>Hmmm... interesting analog, but it only goes so far. Viruses would be a
>>vastly smaller threat had microsoft engaged in the strategy that I'm arguing
>>for. Trojans, worms, etc... the face of the online world would be
>>considerably different had they invested in building fundamentally secure
>To build a fundamentally secure system, though, we'd be replacing
>SMTP with something that actively prevented impersonation and
>forgery, as well as possibly providing a provable audit trail back
>to original sender, along with their identity. We're not coming
>even close to that... so I think that the anti-virus analogy is
>quite appropriate. We're layering a band-aid on top of a
>fundamentally insecure system, and patching any leaks as we hear
All good, interesting points, but we're not talking about building a secure
system here. We're just thinking about a couple of alternative going forward
strategies for our project. One alternative is to actively try to find ways
that spammers can get through our filter and plug those holes before the
spammers find them. The other is to wait until a significant amount of spam
is pouring through the hole, then plug the hole in a much more testable,
The first has the strength of potentially keeping users happier, but the
weakness of not having a strong corpus of evolved spam to test against, so the
effectiveness of changes to the tokenizer is not necessarily provable.
The second has the strength of provability, and the weakness of our software
potentially appearing to be deficient. This strategy, which we seem to be
converging on <sigh>, bears resemblance (imo) to microsoft's "wait till a
hacker trashes the webserver, figure out how they did it, and post a patch"
c'est moi - TimS
More information about the Spambayes