Discussion:
[Spamprobe-users] SpamProbe + ClamAV
Nikolaus Hiebaum
2007-01-28 09:33:34 UTC
Permalink
Hello,

A while ago, I asked a question here regarding an obscure ClamAV error that
happens in combination with SpamProbe. Well, nobody replied; hence, I'll tr=
y
again ...

I am running SpamProbe 1.4d and ClamAV 0.88.7 on my system (a shared
FreeBSD server). Both SpamProbe and ClamAV are invoked through a .procmailr=
c
rule. In general, my .procmailrc-setup looks like this:

1) Run everything through ClamAV (via Clamassassin)
2) Check if mails are for mailing lists and shuffle them in the respective
folder
3) Run SpamProbe
4) Do more mail shuffling

Every now and then it happens that e-mails get "destroyed" and there is an
obscure error in the mail header: Clamscan error 137.

Googling didn't reveal anything and there was no info from the ClamAV maili=
ng
list. I observed that the mailing list mails never suffer this fate; it can
only happen to mails that ran through SpamProbe (so mails of step 4).

So, my question is if anyone of you has an idea what could be the cause of =
the
problem. Also, what would you suggest in terms of order and processing
efficiency of ClamAV & SpamProbe.

--=20
Beste Gr=FC=DFe / Best regards ,
Nikolaus Hiebaum
Brian Burton
2007-01-28 14:56:54 UTC
Permalink
Post by Nikolaus Hiebaum
A while ago, I asked a question here regarding an obscure ClamAV error that
happens in combination with SpamProbe. Well, nobody replied; hence, I'll try
again ...
Probably because people didn't consider it to be a SpamProbe question.
Post by Nikolaus Hiebaum
I am running SpamProbe 1.4d and ClamAV 0.88.7 on my system (a shared
FreeBSD server). Both SpamProbe and ClamAV are invoked through a .procmailrc
1) Run everything through ClamAV (via Clamassassin)
2) Check if mails are for mailing lists and shuffle them in the respective
folder
3) Run SpamProbe
4) Do more mail shuffling
Every now and then it happens that e-mails get "destroyed" and there is an
obscure error in the mail header: Clamscan error 137.
I have been running clamscan followed by SpamProbe for years now and have
never encountered this issue. I have not used clamassassin so I have no
idea what that really does, I simply run clamscan directly to set a header
and reroute virus mails then run spamprobe on anything not identified as a
virus.

If you are seeing emails destroyed then you should use a rule in your
procmailrc to save a backup of every email for a while then when one gets
destroyed look for the original in your backup folder. That way you might
be able to see something interesting about that email and test that email
directly by running clamscan (or whatever) on it by hand.
Post by Nikolaus Hiebaum
So, my question is if anyone of you has an idea what could be the cause of the
problem. Also, what would you suggest in terms of order and processing
efficiency of ClamAV & SpamProbe.
No ideas. As I said above I have always run clamscan first and then
spamprobe. I do train on the virus mails by having cron run a spamprobe
train-spam of the virus folder.

All the best,
++Brian
Nikolaus Hiebaum
2007-01-28 18:54:41 UTC
Permalink
Post by Brian Burton
A while ago, I asked a question here regarding an obscure ClamAV error =
that
Post by Brian Burton
happens in combination with SpamProbe. Well, nobody replied; hence, I'l=
l try
Post by Brian Burton
again ...
Probably because people didn't consider it to be a SpamProbe question.
I really found that connection between SpamProbe and the destroyed e-mails =
just
recently when I realized that the e-mails not running through SpamProbe are=
not
affected.
Post by Brian Burton
I have been running clamscan followed by SpamProbe for years now and have
never encountered this issue. I have not used clamassassin so I have no
idea what that really does, I simply run clamscan directly to set a heade=
r
Post by Brian Burton
and reroute virus mails then run spamprobe on anything not identified as =
a
Post by Brian Burton
virus.
Could you e-mail me the .procmailrc-rule you use for clamscan and rerouting=
the
mails? Thanks

--=20
Beste Gr=FC=DFe / Best regards ,
Nikolaus Hiebaum

Loading...