The high trust score for a period of time won't do much in regards to those corp entities that have purchased their own Razor server and thus have their own database and configuration. Also Pyzor and DCC both come with the opensource server code so you can run your own database as well.
-----Original Message----- From: John J. Stimson-III [mailto:[EMAIL PROTECTED] Sent: Monday, February 24, 2003 11:58 AM To: [EMAIL PROTECTED] Subject: Re: [Razor-users] Turning Razor into a censorship tool > Date: Mon, 24 Feb 2003 09:02:25 -0500 > From: Shawn McMahon <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: Re: [Razor-users] Turning Razor into a censorship tool > > Razor does not list it as spam. You have a problem understanding what > Razor is. Razor lists the OPINION of a Razor member with a high trust > level, that's all. Other Razor members then choose what to do with that > opinion. This seems to be a common response. I think that you are missing the fact that Razor is not just a neutral piece of software doing it's assigned task. Razor was designed as a SYSTEM of determining spam-or-not based on the assumption of a large user base some of whom unintentionally or maliciously provide corrupt input. You can't just say "GIGO" when the stated intent of your system is to tolerate GI. I do agree with you on the last point; the true responsibility for losing the EFF mailings lies with the system administrators who are using a beta-level anti-spam system in a production environment. But that does not mean that it's inappropriate to say "hey, Razor got a false positive; how can we reduce the frequency of such events?" Here are some ideas I've thought of while following this incident: Require a user to build and maintain a high trust score for some period of time before their input is used to determine spam-or-not or affect others' trust scores. Come up with a procmail or other method wherein razor is reapplied to mailboxes periodically to either recover freshly-revoked false positives or weed out newly-reported spam, and include that in the docs as a suggested implementation instead of or in addition to the current check-on-receipt method. -- [EMAIL PROTECTED] John Stimson http://www.idsfa.net/~john/ HMC Physics '94 ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Razor-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/razor-users ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Razor-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/razor-users
