Some months ago I posted a sample recipe set to call and deal
with the results of ClamScan. Frankly, I didn't pay all that
much attention to the code: it was just some model stuff for
people to make use of if they wished. I myself don't run
ClamScan or clamav, etc., from my .procmailrc, and the code
never got rigorous testing from me before now.[1]
Meanwhile, a number of people seem to have adopted that code
or recipes that are based on it. One such person on my
$HOME shell provider, Glenn Spell, tried to use that code
I'd posted here and found some problems. Let's just say
it works some of the time, but not all of the time. In
a local newsgroup on panix we hashed out what was wrong.
I have a fixed version, and I will publish it here in order
to forestall people's continued use of the old suggestion
that, as it turns out, just doesn't work all that well.
Here are the problems we found: (1) In looking for a line
with "FOUND" in the output from ClamScan, my code presumed
it would be on the first line. There can be and are
infected multipart messages whose ClamScan results return
multiline output where the "FOUND" (virus or worm) line
is not the first line of the output.
(2) It also turns out (I had known this at some point earlier
and forgotten it) that checking for the exit code in procmail
under recipe syntax needs the w or W flag. So
:0
VAR=| some_piped_command
MYXIT = $?
does not work. We would need
:0 W
VAR=| some_piped_command
MYEXIT = $?
Except that STILL doesn't work, because now the exit code is
successfully saved, but the $VAR is not!!!
The only way I've succeeded, in my subsequent testing, in getting
*both* $VAR and a saved exit code (with only one call to the piped
action) out of procmail is to do it this way:
VAR = `some_piped_command`
MYEXIT = $?
*That* does work. (Moreover, it avoids a known bug in many
procmail builds where memory addresses can get corrupted using
the "VAR=|pipe" syntax.)
Okay, so here is some revised model code for piping messages to
ClamScan from procmail. Note that $NL is assumed to have been
defined elsewhere (earlier) as a literal newline.
-----------------------------------
:0 # look for possible viral transporters before calling clamscan
* 9876543210^0 ^Content-Type:.*(attachment|multipart)
* 9876543210^0 ^FROM_MAILER
{
CS_OUT=`clamscan --mbox --no-summary --stdout -`
CS_EXIT = $?
:0: # look for any clamscan problems ( exit code > 1 )
* -1^0
* $ $CS_EXIT^0
clamscan_problem
:0 D # capture right side of var; isolate virus name
* CS_OUT ?? : \/.* FOUND$
* MATCH ?? ^^\/.* ()
* MATCH ?? ^^\/.*[^ ]
{
LOG = "$NL Clamscan identified $MATCH $NL"
:0 fw h # attach an X-header telling us what matched
| formail -I "X-Clamscan: $MATCH"
:0:
CLAMSCAN_POZZIES
}
}
-----------------------------------
[1] Regulars here know the reason I don't use ClamScan:
<http://vsnag.spamless.us> is what I prefer instead.
Personal bias acknowledged, of course. I have nothing
at all against ClamScan![2]
[2] That said, I did just notice yesterday and today that
ClamScan -- at least as it has been built on panix -- has
let slip two Bagle-infected messages (both of which were
caught by vsnag). The above-mentioned Glenn Spell has
tentatively concluded that LibClamAV's decoding of base
64 is partially broken. I don't have enough personal
interest to research it further myself, but would be happy
to send the two messages that got through panix's ClamScan
to someone who wants to look further.
Dallman
____________________________________________________________
procmail mailing list Procmail homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail