procmail
[Top] [All Lists]

Re: on thin ice: using $COMSAT to decide how procmail was invoked

2003-03-09 04:22:46
"David W. Tamkin" <dattier(_at_)panix(_dot_)com> writes:

Jeff Orrok followed up,

| I guess I'm lucky.  This system has no /etc/procmailrc.

Usually a non-privileged user can evade an ill-written /etc/procmailrc, such
as specifying an rcfile on a command line in .forward:

 "|/usr/local/bin/procmail $HOME/.procmailrc"

for example.

Hmm, but the man page says "Procmail should be invoked automatically over the
.forward file mechanism" -- I figured that meant that it was going to bypass
it.


Dallman Ross <dman(_at_)nomotek(_dot_)com> writes:

Better?  I think it's a fine way.  I've been doing it for almost a year,
under a heavily tested production environment, and it works fine.  Not
with COMSTAT, and I actually am not sure from the face of it what you
mean by that part; but with live delivery or not depending on whether
TEST is set.
[...]
Later, I deliver in various places based on a SWITCHRC that bails if
we're in test mode.  I have had no unwished-for deliveries of live
mail when I'm in test mode, which I am very often.

The situation I was trying to avoid was forgetting to be in test mode when I
should have been -- something that could happen in the wee hours of the
morning.

Checking COMSAT would work unless there were no rcfile on the command line.

Checking STDERR with test would work unless LOGFILE had been set.

So, I've settled on checking what ps says the parent's tty is.  If it's got a
number in it, then I figure a human is running it, and I force TEST to on
unless it was explicitly set to off in the command line.  If there's such a
thing as a tty without a number, then I guess I should compare it to "^\?$",
which is what the output from ps is when a tty is not involved.

Jeff

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