On 7/13/07, Denny White <[EMAIL PROTECTED]> wrote:
...
PATH=$HOME/bin:$HOME:/usr/bin:/usr/sbin:/bin:/sbin:/usr/local/bin:/usr/local/sbin:.

That line is probably unnecessary.  Unless you can point to a specific
program that your .procmailrc uses that is not in the default PATH set
by procmail, why change it?


FORMAIL=/usr/local/bin/formail

Why do people think that hardcoding the paths to normal programs is a
good thing?  Why not just say "formail" and let the shell do the work?


SENDMAIL=/usr/sbin/sendmail

Remove that line: procmail sets that for you.  ($SENDMAIL is a
historical wart that exists only because sendmail was originally
installed into a directory (/usr/lib) that wasn't in anyone's path.)


LOCKFILE=$HOME/.lockmail

Ugh.  Do you know what that LOCKFILE assignment does?  Unless you have
a specific need for it (and I don't see anything in your .procmailrc
that does), you should remove it.  If you don't know what it does,
then go read the procmailrc(5) manpage and then remove that line.



# Anything that has not been delivered by now will go to $DEFAULT
# using LOCKFILE=$DEFAULT$LOCKEXT

That comment is not correct for at least two reasons:
1) the locking of $DEFAULT$LOCKEXT is only done if $DEFAULT names
   an actual file and not a directory, and
2) it doesn't (re)use LOCKFILE: you can hold both global lock and a local lock


When I take procmail out of .getmailrc & just download everything
to my inbox, there's no problem. The problem starts every time I
try to use procmail. Below is typical output of a getmail session:

2007-07-13 14:23:31 Delivery error (command procmail 17884 error
(0, procmail: [17884] Fri Jul 13 14:23:31 2007
procmail: Assigning "MAILDIR=/home/dennyboy/Mail"
procmail: Assigning "DEFAULT=/home/dennyboy/Mail/inbox"
procmail: Assigning "PMDIR=/home/dennyboy/.procmail"
procmail: Assigning "LOGFILE=/home/dennyboy/.procmail/.procmail-log"
procmail: Opening "/home/dennyboy/.procmail/.procmail-log"))
2007-07-13 14:23:31 msg 13/13 (2274 bytes) msgid UID54784-1149445332 from <[EMAIL 
PROTECTED]>
...

It looks like the complaint from getmail is that procmail is writing
stuff to its stderr.  That's occurring because you set VERBOSE to on
before you set LOGFILE.  Either remove the assignment to VERBOSE or
move it to after the LOGFILE assignment (or move the LOGFILE
assignment to before the VERBOSE assignement, of course).


Philip Guenther

Reply via email to