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