Re: ifile-gnus.el version 0.3.5 (spam-filtering / general email classification)

[Ted Zlatanov <tzz@lifelogs.com>]

On 13 Oct 2002, jhbrown@ai.mit.edu wrote:
> Ted Zlatanov <tzz@lifelogs.com> writes:
>> Some ideas: it would be nice if ifile-gnus.el could support nnimap,
> 
> Yeah, I know.  I don't use nnimap myself (yet), so it hasn't been
> high priority.  I need to sit down and grok how messages are managed
> under nnimap --- I'll have to make ifile-gnus pull down at least the
> ascii and html parts for filtering.  People may not like the
> performance impact, at least when they're reading mail via imap over
> slow links.

I don't think the performance impact will be huge, especially
considering the benefits of ifile.  I think spam.el already pulls down
the article for bogofilter processing, for instance.

> Ah, this is where I'm bitten by working with stable gnus -- I
> haven't played with spam marks at all.  I'll look into doing this
> too, but it's lower priority than nnimap for the moment.  I'll look
> at how spam.el handles it.

Sure.  Basically there's the explicit spam-mark, and there's a list of
marks considered spam marks (usually just the spam-mark).  Conversely,
there's a list of "ham" marks (François Pinard came up with the term)
which are explicitly considered not to be spam.

> I think it probably makes more sense in the long run to have
> ifile-gnus do its own hooking, but since I'm not likely to get there
> real soon, feel free to add it to spam.el for now.

Well, if it's just a function that looks at spam articles, like
spam-bogofilter-register-routine, we can pretty much copy the code
from that function and the corresponding spam-bogofilter-articles that
processes each article with bogofilter, but use "ifile -i spam" on
each spam article.  Does that sound OK?  Would you rather have the
register and processing functions in ifile-gnus.el and have me
autoload them, since you'll need them eventually anyhow if you want to
do your own hooking?

Thanks
Ted