Re: spam assassin filtering

Re: spam assassin filtering

[Jay Belanger]

Alain Picard <apicard+die-spammer-die@optushome.com.au> writes:

> Hello all,
>
> Does anyone have a working setup of GNUS/spam assassin working?
> The setup described in the manual (Oort v.7) doesn't seem to
> work for me.

The method in the cvs manual is to use fancy splitting with

(setq nnmail-split-fancy '(| (: kevin-spamassassin)
                             ...))
(defun kevin-spamassassin ()
  (save-excursion
    (let ((buf (or (get-buffer " *nnmail incoming*")
                   (get-buffer " *nnml move*"))))
      (if (not buf)
          (progn (message "Oops, cannot find message buffer") nil)
        (set-buffer buf)
        (if (eq 1 (call-process-region (point-min) (point-max)
                                       "spamc" nil nil nil "-c"))
            "spam")))))

This didn't work for me either.  The output of spamc with the -c
switch is 1 if the article is spam, but the function above seems to
assume that the value of 'call-process-region' is the same as the
output of spamc. I don't think that's the case, particularly here.
If I'm right, this should probably be changed in the manual.

> Any example of a configuration known to work in real life
> would be helpful.

There are a couple of ways of doing it in the lisp files on
http://my.gnus.org/Lisp
I have it set up the following way (with help from the above function,
and the functions on my.gnus.org); it works for me.

==== from my .gnus =======
(setq nnmail-split-methods 'nnmail-split-fancy)

(defun jpb-spamassassin ()
  (with-temp-buffer
    (if (get-buffer " *nnmail incoming*")
        (insert-buffer " *nnmail incoming*")
      (insert-buffer gnus-original-article-buffer))
    (call-process-region (point-min) (point-max)
                         "spamc" t t nil "-f")
    (goto-char (point-min))
    (when (re-search-forward "^X-Spam-Status: Yes" nil t)
      "Spam")))

(setq nnmail-split-fancy
  '(|
     <... a bunch of splits ...>
     (: jpb-spamassassin)
     "Misc"))
==========================

Jay

Re: spam assassin filtering

[Tim Haynes]

deskpot@despammed.com (Vasily Korytov) writes:

>  JK> process per message plus some MTA processes. This is verly likely to
>  JK> eat up all of your RAM and end in an disaster, i.e. you will loose
>  JK> your mail. (This happend to me while downloading ~100 messages.)
>
> Use spamd/spamc pair. Anyway, my old modem takes care of not losing my
> mail in such situations. =))

Fetchmail will not flush a message off the upstream server if it gets a
failure code from the local delivery agent. 

spamc/d do make it considerably quicker processing a mail, as the perl
interpreter is only invoked the once.

You can add locking to procmail rules (the fine manpage mentions appending
a `:' to the end of the intro line to a recipe triple).

Me, I have my colo-swerver handle the initial incoming mails, bogofilter
being invoked for anything questionable; the mails that pass are copied on
to the ISP at home and pulled down with fetchmail and re-bogofiltered as
well. Seems to work :)

~Tim
-- 
But mountains are holy places,              |piglet@stirfried.vegetable.org.uk
And beauty is free / We can still walk      |http://spodzone.org.uk/
Through the garden                          |
Our earth was once green                    |

Re: spam assassin filtering

[Vasily Korytov]

>>>>> "JK" == Jan Korger writes:

 JK> BUT if you use an MTA, i.e. deliever from fetchmail to port 25 or call
 JK> sendmail or similar, you will end up if 1 procmail + 1 spamassassin(perl)
 JK> process per message plus some MTA processes. This is verly likely to
 JK> eat up all of your RAM and end in an disaster, i.e. you will loose your
 JK> mail. (This happend to me while downloading ~100 messages.)

Use spamd/spamc pair. Anyway, my old modem takes care of not losing my
mail in such situations. =))

---Vas

Re: spam assassin filtering

[Michael Below]

Alain Picard <apicard+die-spammer-die@optushome.com.au> writes:

> deskpot@despammed.com (Vasily Korytov) writes:
>
>> Yep, it works here. It's very simple here: I have procmail as MDA
>> and I call spamc (spamd is run at startup) from my
>> ~/.procmailrc. Then I have ("junk.spam" "^X-Spam-Status: Yes")
>> entry in my nnmail-split-methods.
>
> I was hoping for a procmail-free solution, as this is on a laptop
> system, and I prefer to get the mail "on demand", rather than from a
> procmail daemon.

I didn't even know that procmail can be used as a daemon. Just start
fetchmail on each IP-up, and make fetchmail hand the mail over to
procmail (using procmail as a MDA). Then procmail pipes the mail
through spamassassin (you don't have to use spamd/spamc) and does some
sorting. No need for daemons.

Michael
-- 
_Agricultural activity_ is the management by an enterprise of the
biological transformation of biological assets for sale, into
agricultural produce, or into additional biological assets.  IAS 41,5

Re: spam assassin filtering

[Alain Picard]

deskpot@despammed.com (Vasily Korytov) writes:

> Yep, it works here. It's very simple here: I have procmail as MDA and I
> call spamc (spamd is run at startup) from my ~/.procmailrc. Then I have
> ("junk.spam" "^X-Spam-Status: Yes") entry in my nnmail-split-methods.

I was hoping for a procmail-free solution, as this is on a laptop
system, and I prefer to get the mail "on demand", rather than
from a procmail daemon.

But thanks for the tip, I may have to use it nonetheless.