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