Re: [Nymserv-devel] Proper behavior of Razor checking

[Michael T. S. <mi...@sh...>]

Erik Arneson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> I'm adding the Razor spam filtering stuff to nymserv right now, and I'm
> wondering what the proper behavior should be?
> 
> I figure we've got a few choices.  The first choice is to let the
> filtered mail just be dropped entirely.  This is neat, but right now
> Razor has some problems with its spam database being spoiled with
> legitimate posts -- most notably recently have been the CERT and Bugtraq
> messages being added to the Razor database.
> 
> Another option might be to forward the message on to the user but
> somehow specify that Razor tagged it as spam.  However, this defeats the
> purpose of getting rid of the spam in the first place, as it's still
> using up remailer resources and causing the user to go through the
> trouble of decrypting the received message after all.
> 
> The option that would be the most difficult to implement would be to
> store messages that were tagged by Razor and then send a summary to the
> user with the "From" and "Subject" lines.  If the user wants the
> message, he'd have to reply with a special confirmation code.  This
> would be the safest, but it suffers from a number of problems, including
> the problem of going through a lot of extra trouble for some potential
> spam.
> 
> If the Nymserv operator is willing to put in some time creating a good
> whitelist for Razor, then maybe the first option would be the best.
> 
> What do you guys think?

Initially, we should look at supporting spamassassin before support 
razor by itself.  Spamassassin has rule sets (and it supports razor), so 
it does a better job of dealing with the false positive problem than 
razor by itself.

Regardless of which one we support first (spamassasin *wink* *wink* 
*nudge* *nudge*) I would say we need to support two options before we 
can offer any:

1. Bit bucket
2. Label the message as possible spam and send it on.  Spamassassin does 
a nice job of marking up the message as to why its spam.  It also allows 
for per user configuration of the rule sets, so an individual user can 
setup their rule sets.  This allows a user to "train" their config to 
their unique situation, add white lists, etc.  And eventually, switch to 
option 1.

For the case of holding the messages and sending a summary, I recommend 
doing that last.  Its an excellent feature, but it seems to me we need 
the first two options before we can have the third.

Anyway, my two cents... in a hurry.  :-)

-- 
Michael T. Shinn	PGPKey: 0x91C0781F       GnuPG Key: BC626A27