procmail
[Top] [All Lists]

Re: qmail-local supplies some environmental vbles

2001-10-19 10:11:59
Greg Matheson <lang(_at_)ms(_dot_)chinmin(_dot_)edu(_dot_)tw> writes:
In
http://www.xray.mpe.mpg.de/mailing-lists/procmail/2001-10/msg00175.html
DAvid Tamkin said:

[A] shell forked by qmail to run a command in a .qmail file
wouldn't know the recipient's login environment (shells forked
by other MTAs to run a command in a .forward file don't
either).  That's one of the reasons that procmail takes
variable assignments on its command line.

But according to the qmail documentation on qmail-command,

qmail-local supplies several useful environment variables to
command.  WARNING: These environment variables are not quoted.
...
your home directory, homedir.  HOST is the domain part of the
recipient address.  LOCAL is the local part.  EXT is the address
extension, ext.

Yes, but a) that's not your login environment as defined in your
.profile or .cshrc, and b) with the exception of the TZ variable,
procmail by default ignores the environment that it is started with.
If you want your rcfile to see a variable assignment you need to put it
on procmail's command line:

% FOO=bar
% export FOO
% procmail LOG='$FOO' DEFAULT=/dev/null /dev/null </dev/null; echo ''

% procmail FOO=bar LOG='$FOO' DEFAULT=/dev/null /dev/null </dev/null; echo '' 
bar
%   

If you look carefully you'll notice that procmail is performing variable
and command expansion on the value passed in, so it doesn't work if the
value you want to pass contains any of
        ' " $ `
For example:

% FOO='$SHELL'                                                                 
% echo $FOO                                                                    
$SHELL
% procmail FOO="$FOO" LOG='$FOO' DEFAULT=/dev/null /dev/null </dev/null; echo >
/bin/ksh
% FOO='`id`'
% echo $FOO
`id`
% procmail FOO="$FOO" LOG='$FOO' DEFAULT=/dev/null /dev/null </dev/null; echo >
uid=1000(guenther) gid=1000(guenther) groups=1000(guenther), 0(wheel), 
5(operator), 9(wsrc), 117(dialer)
%  

...so don't use variables assignments on the command line to pass
'uncontrolled' information into procmail.


You can also use the -p option to procmail to preserve (almost all)
the environment.  Certains variables will always be overridden,
including LOGNAME, HOME, etc.  Combining -p with -m will keep procmail
from setting some internal variables in ways that can lead to confusing
errors (for example, SHELLMETAS, SENDMAIL, and SENDMAILFLAGS won't set),
so I strongly recommend you avoid combining the -p and -m options.

Does that all make sense?


My question is a Smartlist one. I want every email that comes to
the many student lists I have to be logged in one central log
file. I have in .qmail-[listname], 

| preline $HOME/bin/procmail -m .procmaillogrc

and in .procmaillogrc, after the usual logging lines, I have

:0
* ^TOpenpals-\/[^(_at_)]*
| flist $MATCH

but I wonder whether it is better to just use the .procmaillogrc
for logging and to pass the email directly to flist with a second
line in the dot-qmail files like this:

| preline $HOME/.bin/flist [listname]

Well, since your current setup won't work very well if a message is
sent to two penpals lists---both of the .procmaillogrc invocations will
extract the same listname from the header---so using a second line in
the appropriate dot-qmail file is better than what you're doing now.

You can fix that extraction problem by passing the EXT variable as an
argument to the rcfile.  Change the preline entry to:

        | preline $HOME/bin/procmail -m .procmaillogrc $EXT

The rcfile will then see it as $1.  That only works with procmail
versions 3.11pre4 and later, but anything before than is in desperate
need of upgrading.


Philip Guenther
_______________________________________________
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>