postfix+clamscan is eating my mail
When I went to check my mail this morning, there was a lot less than I thought there should be. That is, there was no new email, not even spam. This never happens, because I get so much spam and list mail that there's always something there.
I did some investigation and found that postfix was running everything through clamav as configured, but clamav was rejecting everything as having a virus. Even text messages with no attachment!
When I integrated clamscan into postfix, I used a postfix after-queue content filter script. That example shows filter processing as:
filter <in.$$
That redirects the temporary file in.$$ to the filter's stdin for processing. So my script reads:
/usr/local/bin/clamscan -d /var/lib/clamav <in.$$
Looks ok, right? Well, clamscan doesn't support redirecting content into its stdin. Instead, when run without arguments it ignores stdin and processes everything in the current directory. Since the current directory is the temporary filter queue directory, no problem. (Well almost; there is also a race condition if two scans are running simultaneously and one is a virus - the other will be thought to be a virus too.)
Upon further investigation, I found that sometime last evening clamscan had crashed and left a clamscan.core file in the filter working directory. The problem here is that the clamscan core file is itself identified as a virus! While clamscan is running, it contains virus signatures in memory which are then written to disk if it dumps core.
I fixed this problem by changing my clamscan line to:
/usr/local/bin/clamscan -d /var/lib/clamav in.$$
A subtle change but it makes all the difference.
(I don't know why clamscan dumped core. At least if it happens again, it won't cause me to lose 11 hours of email.)
I did some investigation and found that postfix was running everything through clamav as configured, but clamav was rejecting everything as having a virus. Even text messages with no attachment!
When I integrated clamscan into postfix, I used a postfix after-queue content filter script. That example shows filter processing as:
filter <in.$$
That redirects the temporary file in.$$ to the filter's stdin for processing. So my script reads:
/usr/local/bin/clamscan -d /var/lib/clamav <in.$$
Looks ok, right? Well, clamscan doesn't support redirecting content into its stdin. Instead, when run without arguments it ignores stdin and processes everything in the current directory. Since the current directory is the temporary filter queue directory, no problem. (Well almost; there is also a race condition if two scans are running simultaneously and one is a virus - the other will be thought to be a virus too.)
Upon further investigation, I found that sometime last evening clamscan had crashed and left a clamscan.core file in the filter working directory. The problem here is that the clamscan core file is itself identified as a virus! While clamscan is running, it contains virus signatures in memory which are then written to disk if it dumps core.
I fixed this problem by changing my clamscan line to:
/usr/local/bin/clamscan -d /var/lib/clamav in.$$
A subtle change but it makes all the difference.
(I don't know why clamscan dumped core. At least if it happens again, it won't cause me to lose 11 hours of email.)
If you specify "-" as an argument, it'll accept stdin. For example, I use this in my ~/.procmailrc
:0HB
* Content-type.*multi
* ? ( clamdscan --quiet - ; test "$?" -eq 1 )
"viruses/"
![[info]](http://stat.livejournal.com/img/userinfo.gif){kind=small}
ghewgill
2005-12-10T01:05:43Z
Ah, that would have worked too. Good to know!
chrisj04
2005-12-10T04:17:24Z
rather than piping it through clamscan, why not use something like amavisd-[new|lite]?
ghewgill
2005-12-11T00:54:20Z
I could, but that would be yet another piece of software to install and maintain. Right now I've got postfix and clamscan operating effectively together. Perhaps if I need to install another before-smtp filter I'll look at installing amavisd*.
2005-12-09T18:34:44Z