Philip Guenther <guenther(_at_)gac(_dot_)edu> wrote:
dattier(_at_)wwa(_dot_)com (David W. Tamkin) writes:
...
One small comment about the `c' flag on a variable capture recipe. Varia-
ble capture recipes perforce work with a copy of the message, so the `c'
flag isn't needed. In more recent versions of procmail (I don't know ex-
actly when it changed), if you also have a logfile defined and
LOGABSTRACT=all in effect, a `c' on a variable capture recipe will get a
logabstract of the action; in older versions, back to the introduction of
variable capture recipes, it will generate a warning message that the ex-
traneous `c' flag was ignored.
it appears that there's an actual bug in procmail regarding this. You
are totally correct that the 'c' flag is not needed for variable
capture recipes, and that with LOGABSTRACT=all, a variable capture (or
filter recipe) with the 'c' flag will get it's own log entry. However
it appears that procmail fails to set LASTFOLDER when doing variable
capture or filtering, and thus the abstract that is logged will be
Indeed. LOGABSTRACT=all was never intended to be used on anything
other than "delivering" recipes (as defined in the procmailrc man page).
The fact that adding a "c" flag on those recipes seems to change them
into delivering recipes is actually purely coincidental.
The question now is, should procmail consider the 'c' flag to change those
recipes to be "delivering" (and therefore fix the content of LASTFOLDER)
or should procmail simply ignore the 'c' on those recipes all together
and not log a thing. What is what one would expect, and is it useful?
--
Sincerely,
srb(_at_)cuci(_dot_)nl
Stephen R. van den Berg (AKA BuGless).
This sentance contains threee errors.