[Spambayes] full o' spaces

[Tim Stone - Four Stones Expressions]

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 
>>systems...
>
>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
>about them.

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, 
provable manner.

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" 
strategy.  


c'est moi - TimS
http://www.fourstonesExpressions.com
http://wecanstopspam.org