Bart Schaefer <schaefer(_at_)zanshin(_dot_)com> wrote:
[...]
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.
A good question, and one I wrestled with. The short answer is that clamav
appeared to work when called directly from procmailrc, but yielded inconsistent
results. On this and the spamassassin list, I went through several iterations
of trying to "tweak" the recipes, only to find that the results varied
depending on platform and phase of the moon. Given the importance of AV
scanning, a wrapper script semmed the safest answer, and turned out to be
required by bitdefender anyhow (no --mbox or stdin options).
INCLUDERC and recipe-file naming conventions could fill that
bill.
I thought about that, but the entire recipe now consists of:
VHEADER=`/usr/local/bin/vscan-clamav`
:0 fw
| formail -A "$VHEADER"
so I don't know if an INCLUDERC gains much for calling one. 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. A
few comments (documentation!) fixes that though.
[...]
For the procmail recipe solution, the command-line parameters
are replaced by assigning to a control variable before INCLUDERC.
Ah, OK. I had contemplated setting them in an /etc/.rc file and sourcing that
from the shell scripts. So in procmailrc, I could put:
VERBOSE="yes" (etc.)
at the top with other settings, then use $VERBOSE later. That's nice and clean.
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 thought about that, but I need the shell script anyhow, due to the
limitations of the scanners themselves, as described above. But then again,
extacting ONCE rather than in each of the AV scripts makes good sense.
Here's what's in the scripts:
REPORT=`mktemp -p /tmp -t vscan-${SHORTNAME}-report-XXXXXX` || exit 2
SCANDIR=`mktemp -d -p /tmp -t vscan-${SHORTNAME}-XXXXXX` || exit 2
I want the indicate an error if the temp directories extraction and report
directory/file can't be created.
mktemp returns an error exit code on failure, and prints the temp
file/directory name to STDOUT otherwise. Can I grab STDOUT AND test the exit
code in procmail directly?
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. Would that work as
expected? mktemp does add another external dependency, which isn't ideal. I'm
also using munpack for mime-decoding, which isn't universal either.
Doing this all as a one-time setup in procmail does make sense, as reports
would be "all or nothing" for each pass, so I'd want any called scanner to
append to that file. Hmm... OK, I'm sold on the setup (creation of temp
directory for extraction, and report file) in procmailrc.
[...]
I'd agree. If you have other uses in mind, then by all means
stick with shell scripts.
After piddling with several spam scanners, and the differing details of how
they're called, and what they return, I'm contemplating similar scripts for
those as well to provide a consistent header format. I'd like to wind up with a
header added like: X-Spam-<scanner>-Status: {Yes|No} [optional info] that could
be easily tested and logged within procmail. I realize on a one-time setup,
these scripts might not help much. But then, if I'm setting up something for
OTHER users to plug into their procmailrc, it's easier to troubleshoot if
there's ONE WAY to call external scanners.
Again, I'm running several AV and spam scanners for cross training and checking
of bayes. This probably isn't "normal" nor "recommended", but it has yielded
some interesting results. I next want to plug in some of the "filtering"
approaches described on this list and compare hit rates. Your recommended
INCLUDERC approach to test, then handle disposition locally helps a lot for
this kind of scenario.
Thanks for the feedback.
- Bob
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail