era eriksson wrote:
Dirk Laurie <dirk(_at_)calvyn(_dot_)puk(_dot_)ac(_dot_)za> wrote:
> SENDMAIL = /usr/sbin/sendmail
(Are you sure you need to reset Procmail's compiled-in notion of where
Sendmail resides? What if your ISP moves Sendmail without telling you?)
I thought I needed to do this because my Sendmail is not where the
Procmail man page says, but you're right, removing this line does
not ruin the recipe.
> :0
> * !^FROM_DAEMON
> * !^X-Loop: $USER(_at_)$HOST
You need a $ option on recipes when you want $VAR references to be
interpolated. Also note that $\VAR is useful here for quoting
characters that are special to Procmail.
The condition does seem to do what I want -- I tested it by sending
mail from its own userid. Isn't the $ option only needed when the $VAR
appears inside double-quotes?
:0
* ! ^FROM_DAEMON
* $ ! ^X-Loop: $\USER(_at_)$\HOST
{ # ...
> { # shell script `pipe` sends stdout if exit code 0, else stderr
(Not sure what this means. The exit code of what? Do you mean the idea
is to throw away the body under some circumstances?)
Sorry, it's a bit cryptic -- `pipe` calls the program which really does
the work. Normally that program produces a stdout of genuine output,
a stderr with warning and error messages, and the exit code
of that program is 0 if no errors occur.
> :0 fbw :
> | pipe
<...>
> I'm not too sure it works if mails come thick and fast: `pipe` uses
> temporary file names that are not unique, and I'm hoping that the second
> colon on its recipe stops a new mail from executing the recipe until the
> first one is finished.
It will not; in fact, you will get an error message in the log stating
that Procmail can't figure out what to lock. Use a named lock file
each time you use the pipe script -- the same lock file each time,
otherwise different invocations of pipe will clobber each others' temp
files. Better yet, rewrite pipe so it uses unique temp file names, or
no temp files at all. Hint: $$ contains the PID of the current process.
Thanks, I'll try that. BTW, I'm not getting any procmail-log on this ID,
even though it has processed and replied to quite a number of mails.
> :0 fhw # reverse mailheader and extract name
> | formail -rA "X-Loop: $USER(_at_)$HOST"
> :0 a
> | $SENDMAIL -oi -t
> }
> :0
> /dev/null
You mean all mail that didn't go into the braces should go to
/dev/null? I wouldn't do that, at least not until I'm +very+ sure the
script is properly debugged. Even then, it would seem useful to get a
warning that there is a mail loop, or that some bozo is mailing to the
wrong address.
Note also that if formail fails for some reason, mail will get sent to
/dev/null. (And possibly you should be using formail -rt instead of
just -r.)
Well, this ID is set up ONLY to process inputs to the program in question,
and the braces condition is not very restrictive. But I take your point,
maybe I should forward it to postmaster if there is a loop?
Dirk