Re: Paul Graham on fighting SPAM

[Ted Zlatanov <tzz@lifelogs.com>]

On Thu, 22 Aug 2002, alex@emacswiki.org wrote:
> When the user leaves the summary buffer, there are five
> possibilities:
> 
> 1. The message was new and the user thinks it is non-spam.  Call
>    spam-stat-buffer-is-non-spam.  

Those articles do not have the spam-mark.  We should make it optional
for users to process all non-spam articles this way (since some
backends may be too slow).  Also, we need a way to mark that articles
have been run through the process already - I can't think of such a
way.

> 2. The message was new and the user thinks it is spam.  Call
> spam-stat-buffer-is-spam.  

Those articles have the spam-mark.  I think
gnus-spam-stat-process-buffer looks like the right function to call on
articles marked as spam; is there a corresponding function (or reuse
of this one) to process articles that are *not* spam?  How do you want
to handle the file setting for the word table - should it be a string
passed to a setup function on your side, or should we keep it in your
code and tell users to customize it?

Will your stats code be a part of Gnus?  Would you like to merge it
with spam.el, so all the spam code is in one place?

> 3. The message was old and marked as spam but the user no longer
> thinks it is spam.  Call spam-stat-buffer-change-to-non-spam.

> 4. The message was old and marked as non-spam but the user now
> thinks it is spam.  Call spam-stat-buffer-change-to-spam.  

> 5. The message is old and its spam-status unchanged, or unread.
> Nothing happens.

Messages should be marked as spam only once, and I think they should
be marked as expired once they are processed as spam at the summary
exit hook.  Are you suggesting that we leave the spam-mark on?  It's a
primary mark, so it can't coexist with the read or unread or expired
marks.  So I don't think there's a way currently to have a message be
both old and marked as spam.

We could make the spam mark a secondary mark, but the original idea
was to have spam marked once, processed, and expired.  I'd like to
know if anyone thinks the spam messages should be kept around in a way
that expiration (deletion or to a folder) can't handle.

> Note that I posted a new version to g.e.sources, which requires less
> effort to build, can be updated on the fly, and has a tiny testing
> infrastructure, plus test data by myself with a tiny set of mails.

I saw that, it looks great.  I'd love to hook or include it into
spam.el.

-- 
Teodor Zlatanov <tzz@iglou.com>
"Brevis oratio penetrat colos, longa potatio evacuat ciphos." -Rabelais