I need your help again. My recipe, which forwards a copy of "important"
mail to me at work, does not need always expand my dollar variables,
(i.e., $FORMAIL, $SENDMAIL and $WORK_ADDRESS, etc.)
Beware: just because the variable aren't expanded in the log doesn't
mean they aren't being expanded when the action is being executed.
I looked at the log (below) and found a 'UX:sh (/bin/sh): ERROR:
/usr/lib/formail: Not found' message. I checked my recipe (also
included below) but can't find what I did wrong.
That log entry actually proves that the $FORMAIL variable is being
expanded when that particular action is being executed. It tells you
exactly what is going wrong in that particular case: formail isn't
installed in /usr/lib on machine. I would actually be surprised to find
formail in the /usr/lib directory: it's a user level program and is
therefore generally installed in a bin directory like /usr/local/bin or
My first suggestion is therefore to stop using full paths when running
programs. You don't normally type "/usr/bin/ls" when you want a listing
of your current directory, do you? No! You type "ls" and let the shell
find the program for you. Instead of saying $FORMAIL, just say
"formail" and let procmail or the shell find it.
My second suggestion is to not set the SENDMAIL variable: procmail does
this for you and is more likely to be correct if the rcfile is ever
moved to another machine.
I am using procmail procmail v3.11pre7 1997/04/28.
My third suggestion is to upgrade to version 3.15. I don't think that's
the cause of any problems I see in the log, but it's a good idea
dummy = "The SENDMAIL variable is: $= $SENDMAIL"
dummy = "The WORK_ADDRESS variable is: $= $WORK_ADDRESS"
dummy = "End of the maillists.rc"
Did you really intend to the $= variable in that? It seems unlikely
since there's no scoring involved and the $= variable is the current
score (see the procmailsc(5) manpage for an explanation of scoring).
procmail mailing list