procmail
[Top] [All Lists]

Re: old procmail as LDA, new procmail in .forward ?

2001-12-27 19:55:03
Tim Luoma wrote,

| My sysadmin is not planning to change procmail since "the old version
| works fine."

| Can I setup a .forward and have my $HOME/bin/procmail used instead of the
| LDA-defined procmail ?

With most MTAs, yes, a .forward file overrides the LDA definition.  In case
it doesn't, you can trick it easily enough.  Start your .procmailrc this
way:

 PROGRAM=$0

 # If call is from an interactive shell prompt, allow any binary;
 # otherwise, make sure $PROGRAM is your own build:
 :0
 * ! ? test -t 2
 * $ ! PROGRAM ?? $HOME/bin/procmail
 | $HOME/bin/procmail

And if $PROGRAM was already your own build, procmail will move on.

I prefer that to testing the PROCMAIL_VERSION variable because, well, it got
me into trouble once when I compiled a new release whose version number
didn't meet my regexp for acceptable version numbers (being *too* new for
the regexp).  Every incoming message kept reinvoking procmail (each procmail
would exit as it started the next one, so the process table didn't fill up,
but the loops never ended) until a sysadmin phoned me to tell me what my
mail was doing.  I figured out the problem and fixed my .procmailrc, and all
the messages finally got delivered and got out of the process table instead
of going on replacing one procmail with another and never exiting.

If the admins to upgrade procmail and you want to get rid of your own
binary, just make a symlink from /usr/local/bin/procmail (or wherever) to
$HOME/bin/procmail and go on calling it in your .forward as
$HOME/bin/procmail.  (Your MTA may or may not understand $HOME in a
.forward, so your .forward might have to use an absolute path.)



_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail

<Prev in Thread] Current Thread [Next in Thread>