(last cross-post unless some major issue arises.
Note: it seems that adding the 'w' on the first pipe
into VIRUS was required, and the recipe now works.
Also, the 'E' glitch speculation below was apparently
due to the reader's interpretation of Section 5.13
in http://pm-doc.sourceforge.net/pm-tips-body.html)
From: "Gary Funck" <gary(_at_)intrepid(_dot_)com>
Date: Wed, 11 Feb 2004 17:51:52 -0800
From: Bob George [mailto:mailings02(_at_)ttlexceeded(_dot_)com]
Sent: Wednesday, February 11, 2004 4:43 PM
Gary Funck <gary(_at_)intrepid(_dot_)com> wrote:
(I posted David's suggestion to the procmail list, because the
topic of invoking a virus scanner from procmail had come up
over there recently as well. Here is some early feedback. I
see a an additional opportunity to streamline the script My
suggestion is prefixed with GF)
I appreciate the assistance!
:0 HB
VIRUS=|/usr/bin/clamscan --mbox --disable-summary --stdout -
The HB flags apply to conditions, of which you have none. By
default procmail pipes both h and b, so you can remove 'HB':
I threw that in during an early attempt to get it all working.
Without it, it
does work fine.
:0
VIRUS=|/usr/bin/clamscan --mbox --disable-summary --stdout -
Above, I'd add a 'w' (wait for result) to be on the safe side;
:0 w
VIRUS=|/usr/bin/clamscan --mbox --disable-summary --stdout -
otherwise, there may be a race condition with the tests that
follow. This might've been a cause of your 'E' rule not working.
GF: Since there are no conditions/tests in that rule, this is
simpler:
VIRUS=`/usr/bin/clamscan --mbox --disable-summary --stdout -`
This I does not seem to work for me (procmail v3.22), whereas the
pipe version
does. I think the message isn't getting fed in via stdin without
the pipe, so I
wind up with just the clamdscan result on an empty file (stream: OK).
I'm guessing that clamscan returned a non-zero exit code, and in the
backtick context it discards the output, but in the pipe methoed it ignores
the exit code. you might be able to confirm this by placing these lines at
the top of your test recipe,
LOGFILE=`rm -f test.log && echo test.log`
VERBOSE=yes
and then look in test.log (under your $MAILDIR)
for the execution trace of the recipe.
:0 Dfw
* VIRUS ?? ^.*: \/.* FOUND
| formail -A "X-Virus-Status: yes, $MATCH"
This could be made more efficient with an 'h', and 'D' is
probably unnecessary:
I haven't done timing tests, but yes it does work well without.
Does D incur a
measurable penalty?
D should be slightly more efficient (it disables the default
'ignore case'). The big savings will come from filtering only
the header.
I anchored the result to the end of the line,
just to play
safe.
:0 hfw
* VIRUS ?? ^.*: \/.* FOUND$
| formail -A "X-Virus-Status: Yes, $MATCH"
:0 Efw
| formail -A "X-Virus-Status: no"
NOTE: This (my recipe) did NOT work after all. I have bad luck
with E. A quick
google leads me to think that E is quirky.
Really? How so? And how was the recipe breaking when 'E' was
in there? I think VERBOSE=yes and looking at the log would add
some insight.
Perhaps only works if previous
recipe is a delivering one? Instead, I just plunked in:
Nope. If it delivered (and didn't also do a 'c' carbon copy, the script
would end, like executing a return in the middle of a subroutine. But in
fact, you are not delivering in the first rule, you are 'f' filtering.
:0 hfw
* VIRUS ?? ^.*OK$
| formail -A "X-Virus-Status: No"
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail