From razor-users-admin@lists.sourceforge.net Thu Aug 15 10:49:32 2002
Return-Path: <razor-users-admin@example.sourceforge.net>
Delivered-To: yyyy@localhost.netnoteinc.com
Received: from localhost (localhost [127.0.0.1])
by phobos.labs.netnoteinc.com (Postfix) with ESMTP id 4CBE243C4B
for <jm@localhost>; Thu, 15 Aug 2002 05:48:23 -0400 (EDT)
Received: from phobos [127.0.0.1]
by localhost with IMAP (fetchmail-5.9.0)
for jm@localhost (single-drop); Thu, 15 Aug 2002 10:48:23 +0100 (IST)
Received: from usw-sf-list2.sourceforge.net (usw-sf-fw2.sourceforge.net
[216.136.171.252]) by dogma.slashnull.org (8.11.6/8.11.6) with ESMTP id
g7ELPr404460 for <jm-razor@jmason.org>; Wed, 14 Aug 2002 22:25:53 +0100
Received: from usw-sf-list1-b.sourceforge.net ([10.3.1.13]
helo=usw-sf-list1.sourceforge.net) by usw-sf-list2.sourceforge.net with
esmtp (Exim 3.31-VA-mm2 #1 (Debian)) id 17f5Ss-0006FI-00; Wed,
14 Aug 2002 14:14:02 -0700
Received: from h-66-134-120-173.lsanca54.covad.net ([66.134.120.173]
helo=stealthgeeks.net) by usw-sf-list1.sourceforge.net with smtp (Exim
3.31-VA-mm2 #1 (Debian)) id 17f5Rv-0005qy-00 for
<razor-users@lists.sourceforge.net>; Wed, 14 Aug 2002 14:13:03 -0700
Received: (qmail 68094 invoked by uid 1001); 14 Aug 2002 21:12:56 -0000
Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP;
14 Aug 2002 21:12:56 -0000
From: Patrick <patrick@stealthgeeks.net>
To: "Oates, Isaac" <ioates@amazon.com>
Cc: razor-users@example.sourceforge.net
Subject: Re: [Razor-users] many vs one
In-Reply-To: <1C63DA9F9722C2499FA0475B8B8625E32151ED@ex-mail-04.ant.amazon.com>
Message-Id: <20020814135041.B67991-100000@rockstar.stealthgeeks.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: razor-users-admin@example.sourceforge.net
Errors-To: razor-users-admin@example.sourceforge.net
X-Beenthere: razor-users@example.sourceforge.net
X-Mailman-Version: 2.0.9-sf.net
Precedence: bulk
List-Help: <mailto:razor-users-request@example.sourceforge.net?subject=help>
List-Post: <mailto:razor-users@example.sourceforge.net>
List-Subscribe: <https://example.sourceforge.net/lists/listinfo/razor-users>,
<mailto:razor-users-request@lists.sourceforge.net?subject=subscribe>
List-Id: <razor-users.example.sourceforge.net>
List-Unsubscribe: <https://example.sourceforge.net/lists/listinfo/razor-users>,
<mailto:razor-users-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://www.geocrawler.com/redir-sf.php3?list=razor-users>
X-Original-Date: Wed, 14 Aug 2002 14:12:56 -0700 (PDT)
Date: Wed, 14 Aug 2002 14:12:56 -0700 (PDT)
On Wed, 14 Aug 2002, Oates, Isaac wrote:
> I'm new to razor but have studied trust systems before. I've been following
> the threads about TeS and have a few thoughts.
>
> First, a more complex algorithm is not always better. As soon as you start
> accounting for edge cases in what should otherwise be a generalized
> algorithm, general performance begins to degrade exponentially. The
> thing that razor should have going for it is numbers. Say that razor
> has 100,000 people that actively use it (i.e. click the "Spam" button on
> their mail reader from time to time.) If we decide that our objective
> is to screen 99.0% of spam, it means that we can continue to show what
> appears to be a piece of spam to 1,000 people and still meet our
> objective.
>
> Why not just wait for 1,000 people to vote that a piece of mail is indeed
> spam before ever acknowledging that it could potentially be spam? In
> other words, when I razor-report a message, should I be able to tell
> that razor has ever even seen that message?
Because you then have a system that is ineffective to a varying degree. A
simplistic view would be that 999 subscribers received a piece of spam
that could have otherwise been avoided. But the reality is likely that
many, many more individuals would have received the piece of spam when you
factor in report times.
> By having the server pretend to never have seen it, you can avoid
> people who just re-report spam because it was already marked as spam,
> something that is completely useless.
Wrong. razor-check will tell you if a specific piece of mail matches
something already in the database. If you have the system pretend to have
never seen a piece of mail, how do you propose people use the system for
filtering?
> What about revocations? A revocation is after the fact because a
> substantial number of people (1,000, in this example) have already
> decided that they do not want that message. If it is marked as spam by
> all those people, and then people start revoking it, what does that
> mean?
> It means that the revokers have an opinion that probably doesn't mesh
> with the majority;
No, it means that the people doing the revoking have a different opinion
than the 1000 people who have submitted it as spam. Rather the 1000 people
who have reported the message as spam constitute a majority or not is
something that would have to be determined in the context of the
individual message.
> instead of messing with its rating, why not just put
> it on the whitelist? If I want that ZDNet mail, and most people think
> that ZDNet mail is just plain annoying, then why can't I whitelist it,
> instead of "arguing" with everyone about whether or not it's spam?
You always have that ability.
> Correct me if I'm wrong, but it's not as if all mail from ZDNet will be
> banned in the future-just that one piece. So if ZDNet were to change
> its system to make it easier to opt out, or whatever, people would hopefully
> start unsubscribing instead of clicking the "Spam" button.
It's my opinion that it's not my job to unsubscribe to any list that I
haven't subscribed to, nor is it necessarily in my best interest given
that some parties sending unwanted communications may utilize the
unsubscribe request as a method of determining they are mailing a valid
address.
> The inherent problem here, of course, is that someone can pretend to be
> 1,000 people and block anything they choose. But say you still have a
> lightweight trust system built in, where when they "agree" with the
> majority (though they couldn't have known because razor hadn't
> acknowledged anything yet) then your trust rating goes up and vice
> versa.
>
> The key here is that, in order to be reliable, you need the numbers. What
> am I missing here?
See above.
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
Patrick Greenwell
Asking the wrong questions is the leading cause of wrong answers
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
-------------------------------------------------------
This sf.net email is sponsored by: Dice - The leading online job board
for high-tech professionals. Search and apply for tech jobs today!
http://seeker.dice.com/seeker.epl?rel_code=31
_______________________________________________
Razor-users mailing list
Razor-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/razor-users