Re: Paul Graham on fighting SPAM

[Ted Zlatanov <tzz@lifelogs.com>]

On Thu, 22 Aug 2002, alex@emacswiki.org wrote:
> Ted Zlatanov <tzz@lifelogs.com> writes:
> 
>> The functions you have are great, we just need to figure out how to
>> preserve the state of an article marked as spam, for the
>> spam<->not_spam transitions, or to go with the original idea of
>> expiring all spam mail that's been processed already.
> 
> Maybe we could move spam into mail.spam, with expirable.  If the
> user then moves mail from or to mail.spam, this indicates
> transitions and must be handled immediately (instead of waiting for
> summary buffer exit).  What do you think?  Is that possible to do in
> a backend-independent way?

I don't like a special newsgroup for this purpose.  For instance, NNTP
spam couldn't be treated in this way.  There was a past discussion
about when the spam analysis should be done, and the general agreement
was that spam should be blacklisted/submitted to ORDB/analyzed at the
time you exit the summary, not at the time you set the spam-mark on an
article.  The user could manually run the summary-exit-process-spam
(to pick a name) function that would normally be in the summary exit
hook, but the consensus was that the action should be delayed.

Also, splitting mail into a separate group is only one possible way to
treat spam.  The splitting function could just set the spam-mark on an
article that it processes, and let the other split rules handle where
the article should go.  I don't know if that's possible in a split
rule, though.  It may have to be done before splitting, at the time
new articles are obtained from the backend.

>> 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?
> 
> I have no idea.  I would like to contribute it, once it is "done".
> :) That includes the FSF paperwork.  Once I think it is "done", I
> will write to assign@gnu.org.  (Assuming that spam.el is part of
> Gnus which is also part of Emacs.)

It's up to you how you want to contribute your code, as a separate
package or as a part of spam.el.  I have no problem with either
approach.  I think it's better to keep all spam-related code,
including yours, in one place (spam.el) to simplify documentation and
future extensions.  spam.el is part of Gnus (in the lisp subdirectory
in CVS and latest Oort).  So if you feel like looking at the current
spam.el and adding your source to it, I can commit that to CVS with
the proper attribution (or I can do the merge if you wish).  Of
course, feel free to continue a separate package if you prefer that.

Thanks
Ted