mdam writes:
> What is the function of "-e" as option?
> I use cyrus (and deliver) version 2.0.12 and the option is not mentioned
> anywhere.
In 2.0.15, -e does nothing -- the option is ignored in deliver.c. The
comments imply that it had something to do with duplicate delivery in
the past.
> What Version of procmail do you use?
> I have the funny problem, procmail interprets such a line as above
> sometime with commas, where the blanks are,
If you're seeing this in procmail's log when you turn on VERBOSE in
your .procmailrc, then the commas can safely be ignored. That's just
procmail's way of making its actions really explicit. I.e., something
like this indicates that the command was executed correctly:
procmail: Executing "/usr/local/bin/deliver,-a,sudish,-m,cyrus,sudish"
If your "| deliver" rule isn't working, try adding the "w" flag to the
first line in the rule. That'll make procmail wait around for deliver
to exit and the exit code will be logged on failure (turn on VERBOSE).
I.e., your rule should look something like this:
:0w
| /usr/local/bin/deliver -a sudish -m dubious sudish
(In general, it's always a good idea to use "w" when delivering through
a pipe with procmail.)
Now, when deliver fails, procmail will log the failure along with the
exit code. Here's an example from when I forgot to strip the leading
"From " from the piped-in message:
procmail: Executing "/usr/local/bin/deliver,-a,sudish,-m,foo,sudish"
procmail: Program failure (65) of "/usr/local/bin/deliver"
Once you have the error code, 65 in this case, you can look at
lib/sysexits.h and src/deliver.c to figure out why deliver is
reporting failure. It helped me recover from my silly oversight (65
is EV_DATAERR, which helped light the bulb over my head in this
case). Or, you could post the error code here and someone might be
able to help you figure it out.
--
Sudish Joseph
