Re: spam.el and Procmail splitting strategy?

[Jody Klymak <jklymak@coas.oregonstate.edu>]

Hi Ted,

Just realized that I never got back to you...

Ted Zlatanov <tzz@lifelogs.com> writes:

> Well, I was thinking of a 'respool spam/ham process destination, as
> suggested before, which would resubmit the spam/ham mail to the spool
> process from any mailbox.  Would that work for you?

Not sure if that would work.  Does imap support re-spooling?  

I am pretty happy taking bbdb out of my .procmail and splitting it in
gnus instead.  It does, however, seem that this will end up being a
generic problem if other mail groups get infected.  Doing all my
splitting in gnus may be a good option - it just means that I
need to have a gnus running at all times on my main machine.  

It seems that it should be possible to spam-split new messages in any
group upon entry.  I guess it just doesn't fit with the existing
splitting mechanism.  Perhaps the splitting mechanism not be extended
so that the last argument in nnimap-split-fancy is something like
"current-split-inbox" instead of a single mail box?  Then I could do
something like:

(setq
  nnimap-split-rule 'nnimap-split-fancy
  nnimap-split-inbox ("INBOX" "mail/ZIn.bbdb")
  nnimap-split-fancy '(|
		       (: spam-split)
		      ;; default mailbox
		      'current-split-mailbox)
)

instead of: 
(setq
  nnimap-split-rule 'nnimap-split-fancy
  nnimap-split-inbox "INBOX"
  nnimap-split-fancy '(|
		       (: spam-split)
		       (any ".*bbdb.*" "mail/ZIn.bbdb")
		      ;; default mailbox
		      "mail/Inbox.spam")
)

Of course, I have no idea how the splitting code is written so that
may not be easy.   

> I think it would be easier in the end to keep splitting on the client
> side with spam.el.

I agree - being able to continuously train bogofilter from within gnus
is very convenient.

Thanks,   Jody

-- 
Jody Klymak                           104 Ocean Admin Bldg., OSU
mailto:jklymak@coas.oregonstate.edu   Corvallis OR, 97330