procmail
[Top] [All Lists]

Re: ERROR: rescue of unfiltered data succeeded

2002-01-19 09:12:49
Stig asked,

| I don't quite understand that, why? As I understood it, Adhamh wanted
| the message to be processed by the next recipe as well, and I thought
| that without a `f' in the recipe `head', the recipe would be considered
| a delivering recipe, thus processing for that mail would terminate
| (unless a `c' was used to keep processing on a copy that is).

An `f' flag is for filtering: yes, a filtering recipe is non-delivering, but
also it changes the content of the message.  Adhamn didn't want that to do
that.  He wanted the output of the command to be assigned to the variable,
not to replace the message.

| Is it because of the `NEWTO=' part in the beginning of the line?

It's because of the `NEWTO=|' part at the beginning.  Variable capture
recipes are also non-delivering.

Martin has posted two relevant passages from the procmailrc(5) man page, and
there is also this, which comes immediately after his first excerpt:

       Non-delivering recipes are: those that cause the output of
       a program or filter to be captured  back  by  procmail  or
       those that start a nesting block.

[The man page then goes on to say that in addition the `c' flag will make
procmail deliver a copy and treat the original as still undelivered.]

The point of a filtering recipe is to do something with the filtered text;
the point of a variable capture recipe is to use that variable somehow.
Neither delivers, so it's implicit that procmail continue reading recipes to
complete delivery.  But also, `f' and var=| are incompatible with one
another, so procmail has to have a rule about which to do when the code says
both, and the winner is var=|.



_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail

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