On 08/02/01 02:57 AM, Sudish Joseph sat at the `puter and typed:
> 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
>
I can't really argue with anything Sudish states here, but here is how
I am getting procmail to deliver to cyrus - successfully, without
much trouble at all.
When sendmail invokes procmail, it does so as follows:
`procmail -Y -m /etc/procmailrc $u $h'
Now, $u is user and $h is the folder extension (as in
[EMAIL PROTECTED] will deliver to my cyrus folder).
If $h is null, it just goes to the inbox.
My /etc/procmailrc looks like this:
############################################################
LOGNAME = $1
FOLDER = $2
PATH=$1/bin:/usr/bin:/bin:/usr/local/bin:.
SHELL=/bin/sh
MAILDIR=/home/mail
LOGFILE=$HOME/.procmail.log
DEFAULT=$HOME/
VERBOSE=yes
# Place any antispam or other universal filters here. Don't
# write to files or pipe to programs unless you are ABSOLUTELY
# SURE you know what you are doing!
# this enables automated procmail recipe creation for users;
# roll your own tool to allow creation of procmail recipes on a
# per-user basis and place them there, but you may not want to let
# users edit their own recipes
INCLUDERC=/home/$LOGNAME/.procmailrc
# A little recipe to ensure that all incoming mail has a Lines header.
:0 Bfhw
* H ?? !^Lines:
* 1^1 ^.*$
* -1^0 ($)($)^^
| /usr/local/bin/formail -Y -f -A "Lines: $="
:0 w
* FOLDER ?? .
| /usr/local/cyrus/bin/deliver -q -m "$FOLDER" -- "$LOGNAME"
# Only if there was no extension do we try this
:0 wE
| /usr/local/cyrus/bin/deliver -q -- "$LOGNAME"
# Whichever one we tried, failed
EXITCODE = $?
HOST
############################################################
The only difference in my own is that I use deliver -e because I am
still using 1.6.24 - got sick of the crashes and couldn't figure them
out.
If you don't care about the Lines header, just remove the recipe. It
has no bearing on wether mail is delivered or not.
> (In general, it's always a good idea to use "w" when delivering through
> a pipe with procmail.)
Not entirely sure why, but yeah.
> 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.
Hmm. I have seen a failure (67), on deliver, but only rarely - like 3
in the last couple weeks out of a couple hundred mails a day. Anyone
know what it is?
--
Louis LeBlanc [EMAIL PROTECTED]
Fully Funded Hobbyist, KeySlapper Extrordinaire :)
http://acadia.ne.mediaone.net ԿԬ
Corry's Law:
Paper is always strongest at the perforations.
