Bart Schaefer <schaefer(_at_)zanshin(_dot_)com> wrote:
On Mon, 1 Mar 2004, Bob George wrote:
The short answer is that clamav appeared to work when called
directly from procmailrc, but yielded inconsistent results.
But that was when piping to it, rather than invoking it on a
tempfile copy of the message, right?
Yes, that's (apparently) true. But there are caveats about using --mbox in the
current clamav docs. And since bitdefender insists on files-on-disk anyhow...
I'm leaning towards the "consistent" approach, as that's KNOWN to work with
just about any scanner. Again, if I were ony using clam, this wouldn't be as
big a deal.
It might avoid forking an extra shell to run the script. That
may not be important.
That was the holy grail that led me astray with clamav originally. Mind you,
I'm intentionally leaning towards "mildly paranoid" with anti-virus. In a
high-volume production environment, I can see where this might not be
advisable.
However, if several are called -- normally for testing -- it
makes good sense. The only problem is it might not be clear
WHERE headers are being added that are tested later.
You can still follow the model of only setting variables in the
INCLUDERC'd file, and doing the header insertion in the main
procmailrc.
You've made some good points, and I'm re-thinking the approach. It makes sense
for procmail to prep everything, then call the scanner wrapper script to do
exactly ONE thing -- scan for viruses, and return status.
Having procmail do the setup of temp files/directories also give me a way to
use a persistent report file for each session... something I've been tinkering
with.
So: "procmail processes mail, virus scanners scan for viruses."
[...]
VERBOSE="yes" (etc.)
Except that VERBOSE already has special meaning to procmail:
yes, exactly.
Doh! Heh, thanks.
REPORT=`mktemp -p /tmp -t vscan-${SHORTNAME}-report-XXXXXX`
STATUS=$?
:0
* ! STATUS ?? ^^0^^
{
STATUS=2
SWITCHRC
}
OK, keeps the flow in one place. I like it.
However, you might just want to let procmail create the
filenames rather than resort to mktemp.
I may have missed a capability. I'd ideally like each message ("session") to
get a guaranteed-unique directory to work in, so multiple instances could run
concurrently. Something clever with Msgid?
(Do some of the
scanners really require an entire private *directory* in which
to work, rather than just a unique file to work on?)
At least one does (bitdefender), at least from what I can determine. Again,
it's a safe if slightly-paranoid approach.
I want different SCANDIRS to be used for each instance so
they several
can run simultaneously (scans can take a few seconds). I
recall that I
can set EXITSTATUS in procmail with a value, then HOST so
procmail will indicate a delivery failure, and that the
message should be requeued.
It's EXITCODE, but yes. Replace STATUS and SWITCHRC above
with EXITCODE and HOST if that's what you want.
I'm still trying to decide if I want to re-queue the message, or simply put any
affected messages in a safe, holding location for review.
Thanks for the tips!
- Bob
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail