Did you want this on the list? I'm replying to the list..
On 6 Sep 2002 at 10:43, Guido van Rossum wrote:
> What's an auto-ham?
Automatically marking something as ham after a given timeout.. regardless of how long
that timeout is, someone is going to forget to submit the message back as spam.
How many spams-as-hams can be accepted before the f-n rate gets unacceptable?
> > How about adding an IMAP server with a spam and deleted-ham
> > folder. Most email clients can handle IMAP. Users should be able to
> > quickly move "spam" into the spam folder.
>
> I personally don't think IMAP has a bright future, but for people who
> do use it, that's certainly a good approach.
>
> > Instead of deleting messages (or, by reprogramming the delete
> > function) they can quickly move ham into the ham folder.
>
> Yes.
I view IMAP as a stop-gap measure until tighter integration with various email clients
can be achieved.
I still feel it's better to require classification feedback from the recipient, rather than
make any assumptions after some period of time passes. But this is an end-user issue
and we're still at the algorithm stage.. ;-)
Brad Clements,                bkc@murkworks.com   (315)268-1000
http://www.murkworks.com                          (315)268-9812 Fax
AOL-IM: BKClements

> > What's an auto-ham?
>
> Automatically marking something as ham after a given
> timeout.. regardless of how long that timeout is, someone is going
> to forget to submit the message back as spam.
OK, here's a refinement.  Assuming very little spam comes through, we
only need to pick a small percentage of ham received as new training
ham to match the new training spam.  The program could randomly select
a sufficient number of saved non-spam msgs and ask the user to
validate this selection.  You could do this once a day or week (config
parameter).
> How many spams-as-hams can be accepted before the f-n rate gets
> unacceptable?
Config parameter.
> I view IMAP as a stop-gap measure until tighter integration with
> various email clients can be achieved.
>
> I still feel it's better to require classification feedback from the
> recipient, rather than make any assumptions after some period of
> time passes. But this is an end-user issue and we're still at the
> algorithm stage.. ;-)
I'm trying to think about the end-user issues because I have nothing
to contribute to the algorithm at this point.  For deployment we need
both!
--Guido van Rossum (home page: http://www.python.org/~guido/)