W. Wesley Groleau had written,
| > | The recipe is
| > |
| > | :0
| > | * condition(s) withheld in case the bomber reads this list :-)
| > | EXITCODE=67
|
| And Dave explained I should do
No, it wasn't Dave. It was I who suggested this:
| > :0
| > * conditions
| > { EXITCODE=67 }
| James [McGill] went a little further:
|
| > :0
| > * conditions
| > {
| > EXITCODE=67
| > :0
| > /dev/null
| > }
James assumed that Wesley wanted to drop the message into the bit bucket
after assigning EXITCODE. That wasn't in Wesley's original post, so I made
no assumptions about what other plans he had for it. Perhaps he wanted to
save the message somewhere for perusal to make sure that all these events
occurred for a message that deserved them.
| It appears James is right--unless you want to fiddle with the message even
| though you said it bounced.
If the question is how to set EXITCODE and then toss away the message, then
James is right, and I agree with him (well, I might add an `h' flag to the
drop recipe). If the question is how to set EXITCODE and do nothing else at
the time, I'm right, and surely James agrees with me.
| Once you set EXITCODE, is it impossible for a subsequent recipe to change
| it?
Not at all. You can reset or unset a variable (except for HOST) as many
times as you like until procmail makes final delivery. Moreover, with
EXITCODE you get even one more chance: if it is set but null when procmail
completes delivery, procmail will use the exit code of the TRAP statement as
its own exit code.