All the recipes I've seen have a line such as
# Mail loops are evil
* !^X-Loop: your(_at_)own(_dot_)mail(_dot_)address
(from the procmailex man page)
which includes the owner's email address. This is a general problem, I think,
requires manipulation of the users' individual ~/.promailrc files, and it is
bad idea for any administrator to trust their users to do anything correctly.
Which is why
I'd like to have a global way of implementing a safeguard against loops, for
/etc/procmailrc. The other option would be to disallow recipes that send mail
or to do it for each user who really wants it (only allow root to edit ~/.pro
which is not really a satisfying solution from a maintenance point of view.
It It shouldn't be hard to test for a loop in the global procmailrc, and it's
something you as the administrator can do.
You do need to read the documentation carefully to see if there are any side
effects you dislike.
You can use pattern-matching to strip out addressing information (note that
TO: and CC: headers are not obligatory) and determine what the loop-detector
then test to ensure it's not there (you need to decide what to do if you DO
detect a loop - sending it to the user may not be prudent) & having
established it's not, then inject your header.
Does not have to be X-loop (and maybe shouldn't be as your users may look for
it) - perhaps X-loop-detection: will suffice.
At this point you're ready to pass the message on to your user's .procmailrc.
There are alternatives here:
1) Include the user's .procmailrc
2) Invoke procmail recursively
3) Forward the mail to another host for delivery.
the last means that your fiddling is entirely invisible to the user, with (I
think) no side effects. It does require that all incoming mail go through the
first host which then fiddles around and then sends the mail on to where it is
Note: your second host can almost certainly be an appropriately-configured
second MTA on the same host, and you could actually forward tyhe mail by
piping it though a little perl (or some such) that talks smtp to the second
http://www2.ami.com.au/ for OS/2 & linux information.
Configuration, networking, combined IBM ftpsites index.
Note: mail delivered to me is deemed to be intended for me, for my disposition.
procmail mailing list