From: Adam Shostack <adam@bwh.harvard.edu>
Date: Thu, 15 Sep 94 09:52:25 PDT
To: hayden@krypton.mankato.msus.edu (Robert A. Hayden)
Subject: Re: The Importance of Filtering
In-Reply-To: <Pine.3.89.9409141818.A23336-0100000@krypton.mankato.msus.edu>
Message-ID: <199409151652.MAA10444@arthur.bwh.harvard.edu>
MIME-Version: 1.0
Content-Type: text/plain


You wrote:

| One of the things that might be helpful with regards to filtering would be
| some kind of a user-friendly interface that will allow easy editing and
| manipulation of the elm filter or procmail rules.  (For example, the Tin
| newsreader has a good entry screen for killfiles based on subject or
| author.) In addition, I remember way back when when I was using NN as a
| newsreader, there was a way to set up killfiles with a certain number of
| days before they would timeout and be removed from the killfile. 
| 
| If a program existed that would allow similiar manipulation of mail
| killfiles, that would be great.  (regretably, I am a dreadful programmer
| and really am not sure how to design or write the program). 

	The rep. credit system that I sketched out a few days ago would
alliviate the need to edit your procmail rules by hand for those mail
message you choose to filter.  The way I had pictured setting it up
would have a procmail rule which would query a reputation database
(stored in the users account.)  The query would return a number, which
procmail could then act on.

	No timing features at the user level, but I've considered
putting in a decaying value for credit, to prevent entries from living
forever.  I doubt this would be in early versions.

	Lastly, I'm getting around to sketching out data structures,
the only problem I have to address in theory is how to prevent the
system from becoming a spam factory; deluging people who don't use the
system with piles of messages that they don't want.  Several inelegant
server based solutions appear (they often do), but I'm hoping to
design something more elegant.

Adam