> From: Bob George [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, February 11, 2004 4:43 PM
>
>
> Gary Funck <[EMAIL PROTECTED]> 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"
>
