planned spam.el features

planned spam.el features

[Ted Zlatanov]

OK, now that spam.el is somewhat stable, I'm going to start working on
the next bunch of features:

- unified spam score command (`S t' should produce the most sensible
  score: whichever of [ifile|bogofilter|spam-stat] is set as a spam
  exit processor on the current group, or whichever the user
  specifies).  This will not unify the spam scores themselves, only
  the command used to display them.

- global message registry to record what messages were processed as
  spam or ham.  This is so a message registered by accident as spam
  can later be reclassified as ham.

- capturing messages when they are accepted, moved, or replaced.  This
  is what I saw in the ifile-gnus.el code - is it sufficient to trap
  those three article events to track an article as it moves around?
  What functions should I advise?  Examples would be greatly
  appreciated; the ifile-gnus.el example is only applicable to nnml
  unfortunately.

- optimized training on large numbers of messages, when the spam/ham
  processor allows it.

- better documentation, especially concerning interaction with
  spam-stat.el

- Hashcash support for verifying cookies?  Is anyone using this or at
  least interested?

- universal spam/ham scores?  -100 to -1 is spam, 0 to 100 is ham.
  All the backends would be required to produce a unified score.  Does
  anyone think this would be useful?

Ted

Re: planned spam.el features

[Kai Großjohann]

Ted Zlatanov <tzz@lifelogs.com> writes:

> - capturing messages when they are accepted, moved, or replaced.  This
>   is what I saw in the ifile-gnus.el code - is it sufficient to trap
>   those three article events to track an article as it moves around?
>   What functions should I advise?  Examples would be greatly
>   appreciated; the ifile-gnus.el example is only applicable to nnml
>   unfortunately.

I think a more recent version of ifile-gnus supports more backends.
But I haven't looked at the code.

Maybe it would be a good idea to put some hooks into Gnus.
-- 
Ambibibentists unite!

Re: planned spam.el features

[Ted Zlatanov]

On Fri, 24 Jan 2003, kai.grossjohann@uni-duisburg.de wrote:
> Ted Zlatanov <tzz@lifelogs.com> writes:
> 
>> - capturing messages when they are accepted, moved, or replaced.
>>   This is what I saw in the ifile-gnus.el code - is it sufficient
>>   to trap those three article events to track an article as it
>>   moves around?  What functions should I advise?  Examples would be
>>   greatly appreciated; the ifile-gnus.el example is only applicable
>>   to nnml unfortunately.
> 
> I think a more recent version of ifile-gnus supports more backends.
> But I haven't looked at the code.

Latest (0.3.5) ifile-gnus.el release notes say: "currently works with
most (all?) of the nnmail backends.  It does not currently work with
nnimap."

> Maybe it would be a good idea to put some hooks into Gnus.

Yes!

Ted

Re: planned spam.el features

[Stephen Zander]

>>>>> "Ted" == Ted Zlatanov <tzz@lifelogs.com> writes:
    Ted> OK, now that spam.el is somewhat stable, I'm going to start
    Ted> working on the next bunch of features:

A simple request (unless it's already in the latest version).  I use
fetchmail & mailagent to retrieve & split mail from various lists into
seperate files before reading it with Gnus.  I now also run bogofilter
against all email prior to handing it to mailagent for splitting.
While I have spam-use-bogofilter set to t, this means that bogofilter
gets invoked with the wrong command line switches, '-n' & '-s' instead
of '-S' and '-N', because bogofilter has already added the message to
its database.

If I write a small patch to allow for this alternative, would you be
willing to add it?  Also, does anyone have a prefered name for the
variable that enables such switching?

-- 
Stephen

You will be a large breasted porno star in your next life
    - Chinese Fortune Cookie

Re: planned spam.el features

[Ted Zlatanov]

On Sat, 25 Jan 2003, gibreel@pobox.com wrote:
>>>>>> "Ted" == Ted Zlatanov <tzz@lifelogs.com> writes:
>     Ted> OK, now that spam.el is somewhat stable, I'm going to start
>     Ted> working on the next bunch of features:
> 
> A simple request (unless it's already in the latest version).  I use
> fetchmail & mailagent to retrieve & split mail from various lists
> into seperate files before reading it with Gnus.  I now also run
> bogofilter against all email prior to handing it to mailagent for
> splitting.  While I have spam-use-bogofilter set to t, this means
> that bogofilter gets invoked with the wrong command line switches,
> '-n' & '-s' instead of '-S' and '-N', because bogofilter has already
> added the message to its database.
> 
> If I write a small patch to allow for this alternative, would you be
> willing to add it?  Also, does anyone have a prefered name for the
> variable that enables such switching?

Sure, I'll take a look.  Maybe spam-bogofilter-force-reclassify?

The upcoming spam.el changes will track messages as they are processed
as ham or spam.  You will be able to force spam.el to recognize that a
message has already been processed as spam/ham by a certain backend
spam/ham processor, so force-reclassify will not be needed.  These
changes won't happen soon, though, so your patch would be literally a
patch in the meanwhile :)

Ted

Re: planned spam.el features

[Stephen Zander]

>>>>> "Ted" == Ted Zlatanov <tzz@lifelogs.com> writes:
    Ted> Sure, I'll take a look.  Maybe
    Ted> spam-bogofilter-force-reclassify?

Since writing my original mail, I've upgraded to Oort 0.15, and I have
to say that spam.el officially rocks!!!

The only thing I need now is the ability to use '-S' & '-N' instead of
'-s' & '-n' so that any spam/ham messages are reclassified rather than
added to the pool.  Any likelihood of you adding that, rather than
my doing so?

-- 
Stephen

I love catnip mice
It's why I chew their heads off.
They're good for breakfast.
  -- cat haiku

Re: planned spam.el features

[Ted Zlatanov]

On Fri, 21 Feb 2003, gibreel@pobox.com wrote:
> Since writing my original mail, I've upgraded to Oort 0.15, and I
> have to say that spam.el officially rocks!!!

That's good, I hope you keep enjoying it.  I would welcome any
suggestions for improvements of the documentation or functionality.

> The only thing I need now is the ability to use '-S' & '-N' instead
> of '-s' & '-n' so that any spam/ham messages are reclassified rather
> than added to the pool.  Any likelihood of you adding that, rather
> than my doing so?

Well, I can make it a customizable option, but with the next major
iteration of spam.el there will be real reclassification.  What this
means is, after a message has been processed with a spam processor,
you could "undo" that processing through reclassification.

Is there a way to specify "-s if message is not registered, -S
otherwise"?  Or are the -S and -N flags OK always?  I'm worried that
-S on an unregistered message might cause a skew in the statistics,
and I don't know if bogofilter allows for that.  If that can't be
done, I'll make the -s/-n flags customizable until the
reclassification abilities are in place.

Ted