Michael Champigny asked,
| I recently saw a recipe to bounce email from a specific user:
|
| :0
| * ^From(_dot_)*johndoe(_at_)somewhere(_dot_)edu
| {
| EXITCODE=69
| HOST=done
| }
|
| Is the value for HOST simply a bogus hostname? What in this
| recipe actually causes the mail to bounce, and why are both
| the HOST and EXITCODE needed? Apparently, changing the exitcode
| to 75 will requeue the mail instead of bouncing it.
The HOST variable in a procmail rcfile is a quirky little beast. If you read
it, it will return the name of the host procmail is running on, but if you
try to assign it a value, it doesn't change: it just reacts.
If you say
HOST=somestringhere
and the first nine characters of somestringhere match the first nine
characters of the correct value of $HOST, nothing will happen; procmail
will continue right past the assignment without changing the value of $HOST.
But if there is a mismatch somewhere in the first nine characters, procmail
will jump out of the current rcfile and start reading recipes from the next
rcfile named on the procmail's command line. If there are no more rcfiles
named on the command line (this is the last one or the only one) or if there
are none at all (and procmail is using $HOME/.procmailrc by default),
procmail will drop the letter into the bit bucket and do a fast exit (it
will still execute the TRAP statement if there is one).
The original idea, I think, was to start procmail up with a bunch of rcfiles
for different behavior based on which machine was running it back in the days
before the INCLUDERC directive, brace nesting, and variable ?? pattern
conditions were added. But it turns out that setting HOST to a known wrong
value when there are no more rcfiles left on the command line is the most
efficient way to lose a letter you don't want filed anywhere, even faster
than saving its head to /dev/null and losing its body.
As to setting EXITCODE, Michael answered his own question.