* 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).