Hi All,
While trying to cause mail to be delivered before the end of the
system-wide procmail file (see separate posting), I tried various forms of a
recipe that delivered to procmail, and encountered a number of problems with
this. I wondered if anyone can shed some light on this, and hopefully help
with some way around the current problems, or even suggest better approaches
to the problem.
My recipe looks something like this:
# jump to user processing rules for this mailing list
:0
* ^TO_mailing-list(_at_)some-domain
| procmail <args>
#
Basically, I want to skip the rest of this procmail file, and instead start
processing using a different file (exactly as if procmail had just skipped
the rest of this file, and then started processing the user's
$HOME/.procmailrc file).
I had to try different combinations of procmail arguments before I got any
result at all, and even then the things I had to do to make it work preclude
one of the main reasons for the recipe. Here's what I tried:
1. procmail
(ie, no arguments) This causes (not unexpectedly) a mail loop, since at least
one paragraph in the procmail man page implies that procmail without "-p"
will run (cook?) the system procmail file recipes before the user's .procmail
file.
2. procmail -p
This seemed initially to send the mail into the universal bit-bucket. I
finally found most of the mail in root's mailbox.
3. procmail -m $HOME/.procmailrc
I really didn't want to have to specify the location of the .procmailrc file,
but at least it uses a procmail variable. This also (surprisingly) sent the
mail into a bit-bucket. Turning on logging showed that procmail had
determined that the $HOME/.procmailrc file was suspicious, even though it was
not suspicious when used to filter mail that fell through the system-wide
procmailrc file. I finally made it unsuspicious by changing the owner of the
$HOME/.procmailrc file to root, which sadly also makes it inaccessable to the
user, since .procmailrc files also aren't allowed to be group-writable *sigh*
Once I changed the ownership, mail that made it through the $HOME/.procmailrc
whereupon it was delivered to root's mailbox.
4. procmail -d $LOGNAME -m $HOME/.procmailrc
This also created a mail loop, which I didn't expect. Looking at the log
showed me that the -d argument was swallowing everything after it on the
command line, including "-m" and "$HOME/.procmailrc". Have I misread the man
pages, or is this surprising behaviour?
5. procmail -m $HOME/.procmailrc -d $LOGNAME
This actually behaves exactly as 3. above. The -d option has no apparent
effect. I am presuming that I've misunderstood the purpose or meaning of the
option?
6. procmail -m $HOME/.procmailrc DEFAULT=$DEFAULT
This behaves as 3 and 5 above. It took careful re-reading of the man pages to
see that the rcfile path doesn't bind to the -m argument, and that variable
assignments should (perhaps) be before rcfiles (some paragraphs in the man
pages imply they can be intermixed).
7. procmail -m DEFAULT=$DEFAULT $HOME/.procmailrc
This actually does what I want. Sadly though, because it only works if the
$HOME/.procmailrc file is owned by root, it doesn't allow the user any
control over their own delivery rules.
8. procmail -m DEFAULT=$DEFAULT LOGNAME=$LOGNAME $HOME/.procmailrc
This does ensure that LOGNAME is set to the user's id rather than "root" when
processing $HOME/.procmailrc, but doesn't fix the ownership problem with
.procmailrc.
So my questions are:
Q1. is there a way to make this work without setting the .procmailrc file to
be owned by root?
Q2. Is there a better way to do what I'm trying to do?
Thanks in advance for all suggestions
Cheers!
Nik.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail