On Fri, 2011-08-05 at 07:27 -0500, Robert Bonomi wrote:
You apparently don't have a clear understanding of how procmail
works. :)
OK - Ill admit that! :-)
"Re-order", and simplify the logic as:
IF (clamd error)
{
mark up headers to show clamd error
}
ELSE
{
mark up headers
IF (malware detected)
deliver message to MALWARE folder
}
## reach here if clamd failed *or* it worked _and_ there was no malware
OK that makes sense. I did try that earlier in my experiments, but
couldn't get it to work. I'll try again.
In this recipe (in production) there will be only one case where the
mail is actually delivered.
I don't know how to exit a procmail recipe and allow it to return to the
calling recipe. I have seen the SWITCHRC command - but I don't think
that is what I want here.
You apparently don't have a clear understanding of how procmail works. :)
Procmail has two basic kinds of recipes -- what it calls 'delivering',
and 'non delivering' ones. A 'delivering' recipe is a "terminal'
function -- _all_ processing *ends* after a delivering recipe is executed.
Recipes are executed in the order encountered, subject to 'and'/'else'
flags that make execution conditional on the _last_ prior recipe executed.
These conditional flags are *NOT* 'block structured' --- there is -no-
'return to calling recipe', and 'and'/'else' flags after a '{' '}' block
depend on the last recipe tested _inside_ the '{' '}' block, *if* that
block recipe evaludated 'true'.
Actually I do understand that ;-) but I was probably unclear in my
terminology. I try to keep my procmail processing modular. I have a
series of "rc" files which are called by INCLUDERC commands from
within /etc/procmailrc. I tend to call things "recipes" when what I mean
is "that rc file". The thing we have been talking about here will
eventually become "clamd.rc" and when I say "return to the calling
recipe" what I mean is "resume processing where you left off in
the /etc/procmailrc process - unless delivered somewhere by this
one...".
Apologies for my poor communication.
'switchrc' simply -- and _irrevocably_ -- switches to a different file for
all subsequent recipe input. If you do a switch _inside_ a '{' '}' block,
you have to have the extra 'closing' '}' in the file you switch to, or you'll
get parse errors. DAMHIKT
I really knew that SWITCHRC is not appropriate here.
'includerc' lets you logically switch to a new file, *and*return* to the
original if you 'fall off the end' of the 'included' file. Howevr, if
you execute a 'delivering' recipe in an included file, then that ends
_all_ processing.
Understood - see my comment above.
If/when you need to differentiate between a 'failure' (i.e. 'no match') of
an 'outer' recipe, vs a failure of an 'inner' recipe, you may have to set
(and test) explict 'state variables', or repeat a (possibly inverted) test.
This is the bit that does my head in... I will keep trying.
Thanks again for your help. Much appreciated.
Mark
signature.asc
Description: This is a digitally signed message part
____________________________________________________________
procmail mailing list Procmail homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)de
http://mailman.rwth-aachen.de/mailman/listinfo/procmail