procmail
[Top] [All Lists]

Re: Procmail handling of spawn_process exit code

2000-02-28 13:54:35
Federico Tesei <tesei(_at_)tecsiel(_dot_)it> writes:
I'm working with a sendmail-8.8.7 on an Linux box RH 5.2.
using procmail v3.10 as LDA. 

Version 3.10 is over 5 years old and has some annoying bugs in it.  You
should strongly consider ungrading.  I _know_ there's an RPM out for
version 3.13.1 and I'm fairly certain there's one for version 3.14.


Each incoming message is 
- delivered in the standard user maibox mailbox
- handled by a 'filter' 
via .procmailrc specified in the user home directory.

I would like the filter program exit  code to be passed back to
sendmail, so if for instance the filter return temporary failure
(EX_TEMPFAIL) sendmail can queue for later processing

My tests with the the following  recipes 

:0 c
* ^From.*
{
       :0 wr
       | $TEST
}

shows that procmail check the exit code as you see on the log 
attachment but it seem not to pass back to sendmail as no message 
is queued by sendmail.
...

You need to set procmail's exitcode by setting the EXITCODE variable in
the rcfile.  Setting it in the child doesn't help as the child's
environment is separate from the parent's.  Since the last child
process's exit code is in $?, you can just put the assignment

        EXITCODE = $?

after the action in the above.

However, that won't do what you want: the 'c' flag on a nested block
recipe turns it into a 'clone' block where procmail forks and the child
process starts inside the block, but can continue past it.  As a
result, if the filter fails, you'll have *two* procmail processes
reading the rcfile past the nested block (one with EXITCODE set if you
made the addition suggested above).  Since EXITCODE was set in the
child procmail process, the parent will still exit with success.  Also,
If a later recipe matches you'll get a duplicate message.

In general, you don't want to put the 'c' flag on a nested block
without putting a sure-to-deliver recipe at the end of the nested block
to kill off the child.  However, even then there's usually a better way
to do it.  Putting the 'c' flag on the nested recipe will often do it.

In this case, it's not clear why you put the 'c' flag on the recipe to
begin with.  I suspect you didn't really need it, but without a
description of what you want the *end results* to be (not *how*, but
rather *what*) it's hard to say.

On the other hand...

The condition on nesting recipe is 'odd': The trailing ".*" does
nothing to the regexp because you're not capturing the matched text.
As a result, that recipe will _always_ match, because _every_ message
has a "From " header when procmail is invoked with the -d flag (as it
is being done as sendmail's local mailer).

So, what were you trying to do there?


Philip Guenther

<Prev in Thread] Current Thread [Next in Thread>