Adding a spam processor

Adding a spam processor

[Piers Cawley]

So, I started work on a Spamassassin spam processor now that
Spamassassin has its own rather lovely Bayesian system.

What I'd hoped to do was to have a spam-spamassassin.el which would
have all the spamassassin related code, without having to alter any of
the main gnus distribution files (mostly because I want to be able to
distribute the resulting code without having to fart about signing
papers). 

But, of course, I can't. 

In an ideal world, I want to be able to do

(spam-add-post-processor "spamassassin")

and have that magically insert the appropriate entries into the
spam-process gnus-group parameter definition, tweak
spam-summary-prepare-exit, etc. 

But on looking at the code, everything appears to be hardwired. So
would there be an interest in adding things like:

(gnus-group-param-add-choices (PARAM &rest CHOICES))

and modifying spam-summary-prepare-exit to be rather more dynamic? 

Also, on a Spamassassin specific note, Spamassassin currently does a
quite dramatic modification of messages that it thinks are spam,
hiding the original message away in a MIME part. This can be stripped
away with 'spamassassin -d'. It occurs to me that this could be dealt
with rather neatly by adding a 'filter' parameter to
gnus-summary-move-article (or adding a new function), which would
filter the message through an arbitrary command before inserting it in
the destination mailbox.

-- 
Piers

Re: Adding a spam processor

[Ted Zlatanov]

On Wed, 14 May 2003, pdcawley-ding@bofh.org.uk wrote:
> So, I started work on a Spamassassin spam processor now that
> Spamassassin has its own rather lovely Bayesian system.
> 
> What I'd hoped to do was to have a spam-spamassassin.el which would
> have all the spamassassin related code, without having to alter any
> of the main gnus distribution files (mostly because I want to be
> able to distribute the resulting code without having to fart about
> signing papers).
> 
> But, of course, I can't. 

If you have suggestions for integrating with spam.el, similar or
better than the way that spam-stat.el is integrated, let me know.  You
can definitely keep your code separate and licensed differently - I
will provide a placeholder in spam.el, that's all.

> In an ideal world, I want to be able to do
> 
> (spam-add-post-processor "spamassassin")
> 
> and have that magically insert the appropriate entries into the
> spam-process gnus-group parameter definition, tweak
> spam-summary-prepare-exit, etc. 

That sounds like an excellent idea.  But which groups do you want to
process?  Probably there should be a second parameter, defaulting to
nil (all mail groups), with a regular expression or list thereof
allowed in the parameter.

> But on looking at the code, everything appears to be hardwired. So
> would there be an interest in adding things like:
> 
> (gnus-group-param-add-choices (PARAM &rest CHOICES))
> 
> and modifying spam-summary-prepare-exit to be rather more dynamic? 

Yes, I've been meaning to do that (a lot of spam.el was written when I
knew very little Lisp).  Feel free to implement it or suggest how I
should do it.

> Also, on a Spamassassin specific note, Spamassassin currently does a
> quite dramatic modification of messages that it thinks are spam,
> hiding the original message away in a MIME part. This can be
> stripped away with 'spamassassin -d'. It occurs to me that this
> could be dealt with rather neatly by adding a 'filter' parameter to
> gnus-summary-move-article (or adding a new function), which would
> filter the message through an arbitrary command before inserting it
> in the destination mailbox.

Maybe a mail-sources option?

Thanks
Ted