Jon Lewis <jlewis(_at_)inorganic5(_dot_)chem(_dot_)ufl(_dot_)edu> wrote:
I find out that whenever I am testing a new recipe and procmail runs into
a loop it will then start sending me mail messages on the average of
about 5 per second. I then have to quickly run over to my .procmailrc and
start disabling my individual "control" recipe files (I have everything
compartmentalized to allow me to turn off any single recipe file or whole
auto system).
How about mv .procmailrc .procmailrc.hmm? With command completion in the
shell, you should be albe to bang that out pretty quick.
Or similarly, if you're testing recipes, it would probably be better to
have sendmail re-queue the messages than having them delivered to your
spool mailbox. How does:
INCLUDERC=.procmail.emergency
at the top of .procmailrc look. With .procmail.emergency being a file you
can mv(1) into place, when testing goes haywire, that contains:
# Emergency situation, sendmail will receive a return value of 75 which
# tells it the delivery was "Deferred", will re-queue, and try again later
EXITCODE=75
:0h
/dev/null
1: Is feeding the header to /dev/null the easiest way to force a final
recipe? I thought I remembered a variable that could be set to stop
processing (or at least to pretend delivery and process no more of
the .procmailrc), but I couldn't find anything in the man pages.
2: My testing showed procmail will skip bogus INCLUDERC lines if the
included file does not exist (So you don't have to copy /dev/null
into ...emerg... for a working setup). Is this guaranteed behavior?
-philip
____________________________________________________________ Philip Kizer ___
Texas A&M CIS Operating Systems Group, Unix ( 409.862.4120 )
pckizer(_at_)tamu(_dot_)edu
"Relying on the government to protect your privacy is like asking a peeping
tom to install your window blinds." -John Perry Barlow, EFF co-founder