Backend specific spam filtering

Backend specific spam filtering

[Piers Cawley]

So, I've just switched over to useing spam.el + bogofilter from
spamassassin. I've fed bogofilter a largish corpus and things appear
to be working well. However, spam.el runs bogofilter on all my groups
and I only want to use it on my nnml groups. Is this possible as it
stands (I can't seem to find the functionality in spam.el itself...)

-- 
Piers

   "It is a truth universally acknowledged that a language in
    possession of a rich syntax must be in need of a rewrite."
         -- Jane Austen?

Re: Backend specific spam filtering

[Ted Zlatanov]

On Tue, 19 Nov 2002, pdcawley-ding@bofh.org.uk wrote:
> So, I've just switched over to useing spam.el + bogofilter from
> spamassassin. I've fed bogofilter a largish corpus and things appear
> to be working well. However, spam.el runs bogofilter on all my
> groups and I only want to use it on my nnml groups. Is this possible
> as it stands (I can't seem to find the functionality in spam.el
> itself...)

Not currently, but I can add that in.  It shouldn't be
bogofilter-specific though, we want spam-summary-prepare-exit to be
conditional.  Does anyone want finer-grained spam processing?   It's
sort of a moot point right now with only one method (bogofilter)
invoked by spam-summary-prepare-exit, but as more methods are added
they may need to be applied to specific groups only.

Should I do the usual Gnus approach of both a regex variable
(gnus-groups-spam-processed) and a group/topic parameter
(spam-process)?  Do those variable names sound good?

Ted

Re: Backend specific spam filtering

[Kai Großjohann]

Ted Zlatanov <tzz@lifelogs.com> writes:

> Should I do the usual Gnus approach of both a regex variable
> (gnus-groups-spam-processed) and a group/topic parameter
> (spam-process)?  Do those variable names sound good?

Maybe regexes aren't necessary anymore now that we have the variable
gnus-parameters.  What do people think?

kai
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: Backend specific spam filtering

[Ted Zlatanov]

On Thu, 21 Nov 2002, kai.grossjohann@uni-duisburg.de wrote:
> Maybe regexes aren't necessary anymore now that we have the variable
> gnus-parameters.  What do people think?

I'm all for using gnus-parameters.  Can anyone suggest additions or
improvements to the list below, especially variable names?  All the
parameters would be t or nil, except for to-group-processed-spam and
group-is-spam.

(note that ham == non-spam in spam.el lingo)

- group-is-spam: whether this group holds only spam (parallels
  spam-junk-mailgroups, all unread messages get marked as spam on
  summary entry, nil by default, can be t for a spam group or 'none
  for an explicit ham group)

Setting group-is-spam to 'none is useful for whitelist and BBDB
seeding, see below.  We thus explicitly say that the group contains
only ham.

Entering a group with group-is-spam set to t automatically gives all
unread messages the spam mark.

- to-group-processed-spam: whether spam articles from this group
  should be moved to another group, marked as read, after being
  processed (this would be a string value, nil, or 'expire to expire
  processed articles, nil by default)

- spam-process-with-ifile: whether ifile should be used to process
  spam articles on summary exit (nil by default)

- spam-process-with-bofogilter: whether bogofilter should be used to
  process spam articles on summary exit (t by default, but note that
  spam-process is nil by default, so this wouldn't be activated)

- spam-process-to-blacklist: whether the blacklist should be filled
  with spam message senders on summary exit, instead of when the
  message is marked as spam (nil by default)

- spam-process-ham-to-whitelist: whether the whitelist should be filled with ham message senders on
  summary exit if this is a ham group with group-is-spam set to 'none
  (nil by default)

- spam-process-ham-to-BBDB: whether the BBDB should be filled with ham
  message senders on summary exit if this is a ham group with
  group-is-spam set to 'none (nil by default)

- spam-process: whether spam will be processed at summary exit (nil by
  default)

Maybe I should give a little pseudo-algorithm :)  See below.

Ted

---------------------------------------------------------------------

At summary entry:

if (group-is-spam is t)
  set the spam mark on all unread articles
endif

At summary exit:

if (spam-process is t)
  if (group-is-spam is t or nil)
    check and do spam-process-with-ifile on spam-marked articles
    check and do spam-process-with-bogofilter on spam-marked articles
    check and do spam-process-to-blacklist on spam-marked articles
  elsif (group-is-spam is 'none)
    check and do spam-process-ham-to-whitelist on unread articles
    check and do spam-process-ham-to-BBDB on unread articles
  endif
endif

if (to-group-processed-spam is a string)
  set article mark to read on spam-marked articles
  move spam-marked articles to to-group-processed-spam
elsif (to-group-processed-spam is 'expire)
  set article mark to expired on spam-marked articles  
endif