Martin Mokrejs <mmokrejs(_at_)natur(_dot_)cuni(_dot_)cz> writes:
for some reason I tried to handle some error messages. For testing
purposes I'm forwarding to myself just one of them. My intention is to
extract the e-mail address contained in Subject: line, i.e.
silhand(_at_)feld(_dot_)cvut(_dot_)cz . The message contains in header:
...
I tried several recipes and I "discovered" that procmail is really lost
if I try to assign variable with:
VAR=$MATCH
It needs
VAR = $MATCH
Sorry, even worse, it needs:
VAR = "$MATCH"
otherwise it complained in log like:
procmail: Skipped ""David Silhan" <silhand(_at_)feld(_dot_)cvut(_dot_)cz>]
(fwd)"
I think it's because of those spaces.
Let's say this is the proper recipe I wanted, although I have not yet
what I wanted.
:0cH
* ^Subject:[ ]*BOUNCE.*Non-member.*submission.*from.*\[\/.*
ODESILATEL = "$MATCH"
LOG = "Odesilatel1 je $MATCH
"
Here's your problem: the action of a recipe must be one of the following
a) a mailbox delivery, with optional secondary folders allowed in some
cases; or
b) a pipe action; or
c) a forwarding ('!' action); or
d) a variable-capture version of either (b) or (c), ala
VAR=| command-here
or
e) a nested block ('{')
Variable assignments do not fit any of those. However, you can use a
nested block that only contains variable assignments to do the same
thing. So your receipe above should be writted:
:0 H
* ^Subject:[ ]*BOUNCE.*Non-member.*submission.*from.*\[\/.*
{
ODESILATEL = "$MATCH"
LOG = "Odesilatel1 je $MATCH
"
}
Note that you *don't* want the 'c' flag then, as nested blocks are, by
themselves, never considered to be delivering recipes.
Philip Guenther