Gnus development mailing list
 help / color / mirror / Atom feed
* planned spam.el features
@ 2003-01-24 19:22 Ted Zlatanov
  2003-01-24 20:01 ` Kai Großjohann
  2003-01-25 20:54 ` Stephen Zander
  0 siblings, 2 replies; 7+ messages in thread
From: Ted Zlatanov @ 2003-01-24 19:22 UTC (permalink / raw)


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



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: planned spam.el features
  2003-01-24 19:22 planned spam.el features Ted Zlatanov
@ 2003-01-24 20:01 ` Kai Großjohann
  2003-01-24 20:25   ` Ted Zlatanov
  2003-01-25 20:54 ` Stephen Zander
  1 sibling, 1 reply; 7+ messages in thread
From: Kai Großjohann @ 2003-01-24 20:01 UTC (permalink / raw)


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!



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: planned spam.el features
  2003-01-24 20:01 ` Kai Großjohann
@ 2003-01-24 20:25   ` Ted Zlatanov
  0 siblings, 0 replies; 7+ messages in thread
From: Ted Zlatanov @ 2003-01-24 20:25 UTC (permalink / raw)
  Cc: ding

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



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: planned spam.el features
  2003-01-24 19:22 planned spam.el features Ted Zlatanov
  2003-01-24 20:01 ` Kai Großjohann
@ 2003-01-25 20:54 ` Stephen Zander
  2003-01-27 18:20   ` Ted Zlatanov
  1 sibling, 1 reply; 7+ messages in thread
From: Stephen Zander @ 2003-01-25 20:54 UTC (permalink / raw)


>>>>> "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



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: planned spam.el features
  2003-01-25 20:54 ` Stephen Zander
@ 2003-01-27 18:20   ` Ted Zlatanov
  2003-02-22  7:00     ` Stephen Zander
  0 siblings, 1 reply; 7+ messages in thread
From: Ted Zlatanov @ 2003-01-27 18:20 UTC (permalink / raw)
  Cc: Ding Mailing List

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



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: planned spam.el features
  2003-01-27 18:20   ` Ted Zlatanov
@ 2003-02-22  7:00     ` Stephen Zander
  2003-02-24 15:42       ` Ted Zlatanov
  0 siblings, 1 reply; 7+ messages in thread
From: Stephen Zander @ 2003-02-22  7:00 UTC (permalink / raw)
  Cc: Ding Mailing List

>>>>> "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



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: planned spam.el features
  2003-02-22  7:00     ` Stephen Zander
@ 2003-02-24 15:42       ` Ted Zlatanov
  0 siblings, 0 replies; 7+ messages in thread
From: Ted Zlatanov @ 2003-02-24 15:42 UTC (permalink / raw)


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



^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2003-02-24 15:42 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-01-24 19:22 planned spam.el features Ted Zlatanov
2003-01-24 20:01 ` Kai Großjohann
2003-01-24 20:25   ` Ted Zlatanov
2003-01-25 20:54 ` Stephen Zander
2003-01-27 18:20   ` Ted Zlatanov
2003-02-22  7:00     ` Stephen Zander
2003-02-24 15:42       ` Ted Zlatanov

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).