> >   your mail, and gives you only the non-spam.  To train it, you'd only need
> >   to send it the false negatives somehow; it can assume that anything is
> >   ham that you don't say is spam within 48 hours.
>
> I have folks who leave their email programs running 24 hours a day,
> constantly polling for mail. If they go away for a long weekend,
> lots of "friday night spam" will become ham on sunday night.
> (Friday night seems to be the most popular time)
So we'll make this a config parameter.
> > - Your idea here.
>
> Ultimately I'd like to see tight integration into the "most popular
> email clients".. As a stop-gap to the auto-ham ..
What's an auto-ham?
> 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.
--Guido van Rossum (home page: http://www.python.org/~guido/)

Guido> Takers?  How is ESR's bogofilter packaged?  SpamAssassin?  The
Guido> Perl Bayes filter advertised on slashdot?
Dunno about the other tools, but SpamAssassin is a breeze to incorporate
into a procmail environment.  Lots of people use it in many other ways.  For
performance reasons, many people run a spamd process and then invoke a small
C program called spamc which shoots the message over to spamd and passes the
result back out.  I think spambayes in incremental mode is probably fast
enough to not require such tricks (though I would consider changing the
pickle to an anydbm file).
Basic procmail usage goes something like this:
:0fw
| spamassassin -P
:0
* ^X-Spam-Status: Yes
$SPAM
Which just says, "Run spamassassin -P reinjecting its output into the
processing stream.  If the resulting mail has a header which begins
"X-Spam-Status: Yes", toss it into the folder indicated by the variable
$SPAM.
SpamAssassin also adds other headers as well, which give you more detail
about how its tests fared.  I'd like to see spambayes operate in at least
this way: do its thing then return a message to stdout with a modified set
of headers which further processing downstream can key on.
Skip