procmail
[Top] [All Lists]

problems piping to procmail

2002-08-21 05:10:56
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

<Prev in Thread] Current Thread [Next in Thread>