procmail
[Top] [All Lists]

Re: Virus scanning and defense-in-depth

2004-03-01 10:01:05
On Sun, 29 Feb 2004, Bob George wrote:

After my recent run-in with calling clamav from procmail, I've decided
to write some shell wrapper scripts for various AV programs (clam,
f-prot, bitdefender) to call from my procmailrc. The scripts are
working, but not-quite ready for prime-time yet (tweaking
error-checking). However, I'd like to get some feedback on my general
approach.

My first remark would be to ask: Why are they shell wrapper scripts?

If they're meant only for use in procmail, write procmail recipes that can 
be loaded with INCLUDERC.  If they're meant for general use and procmail 
is just a happy coincidence, write shell wrappers.  For example:

The intent is to have these set up for calling from procmail in a 
uniform, consistent way

INCLUDERC and recipe-file naming conventions could fill that bill.  

and return uniform, consistent results regardless of the underpinnings
of the AV checker itself. [...] I want to hide these differences in the
script, and simply return:

0 = OK, no virus.
1 = Infected.
2 = Error.

This is quite reasonable.

I also want to call each with two command-line parameters:

-q = quiet (output nothing)
-v = verbose (output full X-Virus-(Scanner)-Status: 
{Clean|Infected|Error} header)

This sounds fine, too.  I have some perl mail-scanning scripts that do
almost exactly this.

For the procmail recipe solution, the command-line parameters are replaced
by assigning to a control variable before INCLUDERC.

The scripts themselves unpack the mime message into a temp directory, 
call the AV scanner to check the contents of the directory, and save the 
output to a report file (not used yet.)

This can all be done with a :0c: delivering recipe, assignment of a 
command in backticks to a variable, and LOGFILE and LOG assignments.

I'm thinking this approach will simplify doing AV while keeping procmail 
complexity to a minimum, and aid maintenance. The return codes and/or 
Status messages allow a variety of handling from procmail (and other uses.)

I'd agree.  If you have other uses in mind, then by all means stick with
shell scripts.


_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail