On 02/08/03 02:47 PM, Professional Software Engineering sat at the
`puter and typed:
At 16:58 2003-02-08 -0500, Louis LeBlanc wrote:
But I am running procmail with -m.
Goodie. You're invoking it FROM where? Within sendmail running
_as_root_. if procmail isn't being told to run as if it were the
LDA (whether it IS the LDA or not), then it isn't going to assume a
userid, even if that's one of the arguments you throw on the
commandline (see the docs for -m -- all the arguments after the
rcfile are simply expanded to $1, $2... args - no special meaning is
assigned to any of them, even if one of them just happens to be a
userid).
Ok, my sendmail.mc has the following section for the cyrus setup:
define(`CYRUS_MAILER_FLAGS',`SA5@|:/w')
define(`CYRUS_MAILER_PATH',`/usr/local/bin/procmail')
define(`CYRUS_MAILER_USER',`cyrus:mail')
define(`CYRUS_MAILER_ARGS',`procmail -Y -m /etc/procmailrc $u $h')
define(`CYRUS_MAILER_MAX',`eval(5*1024*1024)')
This was given me some time ago when I first went with Cyrus, and I've
been with it ever since. I've never had much luck interpreting the
sendmail configuration stuff, but I am guessing that this is supposed
to explicitly run procmail as cyrus:mail. Except that the procmail
logs are all owned by root:wheel, so that is probably wrong.
CYRUS_MAILER_FLAGS definition I am totally without understanding,
except that it breaks without it. The MAILER_ARGS, are basically how
I want procmail called, and the CYRUS_MAILER_MAX should probably be
the message size limit (5M).
I have been wondering if all this is really necessary, since I really
only call deliver from procmail, and so far as I understand things,
sendmail doesn't ever get hold of the message again. So is anyone out
there simply using a basic procmail (LDA) config and calling deliver
from procmailrc? If so, I imagine it would be a lot easier to get
procmail to do what I want. I am certainly not opposed to trying a
test out with a basic procmail LDA config in sendmail if someone more
mail savvy than I am believes it will work.
And executing the cyrus deliver utility as any old user from the
command line does work, so I think invoking procmail as the receiving
user is just fine.
It is invoked as follows from sendmail.cf: procmail -Y -m
/etc/procmailrc $u $h
Once again, this is an inadequate picture of how you are invoking it
- surely, there is a ruleset encompassing this? Is this from an
Mlocal definition (oh, I really hope not), an Mprocmail definition
(typically totally unnecessary unless you're writing your own
sendmail rulesets, but it is often included by people enabling any
option in their MC file pertaining to procmail), or in the midst of
a sendmail ruleset? Under what conditions would the above actually
be invoked?
I hope the above is clear enough about just how I'm invoking procmail.
Just to be even more clear as to my goal, I am not doing anything
fancy with multiple MDAs, servers here and there etc. I have one
machine running sendmail and Cyrus imap, and I want procmail to be the
go-between, running and calling spamassassin as the _recipients_ uid,
then deliver, to drop the message into the users imap folder of
choice. Also, I am not running a for pay mail service, and my wife or
my mother won't kill me if they lose one or two messages while I run
tests :)
And the /etc/procmailrc file is used.
Well, in this case, obviously - it's the rcfile you're _specifying_.
However, if you specified any other rcfile with the -m param,
/etc/procmailrc WOULD NOT be automatically invoked because that's
how procmail works. See the manpage - this *IS* documented.
I'm starting to understand this. I think.
What I meant about /etc/procmailrc not being invoked is that if you invoked
_some_other_ rcfile (using -m), that since it wasn't being invoked as an
LDA (via mlocal rule, and more specifically, with the -d param which makes
it act like an LDA), procmail wouldn't be running /etc/procmailrc.
So could I do something like this:
define(`CYRUS_MAILER_ARGS',`procmail -Y -m /etc/procmailrcs/$u/procmailrc $u
$h')
and expect to have sendmail invoke procmail with the rc at
/etc/procmailrcs/leblanc/procmailrc for messages sent to me?
(yes, that file is owned by leblanc)
It still stands that the way you're invoking the rcfile, procmail is
running AS _root_ (or whatever user the MTA is running as, but from
your comments, we can safely conclude that is root), and doesn't
have a different uid to switch to (not having been told that with
'-d $u'). If you were using an /etc/procmailrcs/someuserowned.rc,
procmail would be able to assume the id of the owner of that file,
and from there, INCLUDERC the /etc/procmailrc (though that won't be
executed elevated to root, I'm afraid).
That I understand. Of course, I'm not sure how using -d is better
than -m. I'm not entirely sure how it's different. It seems like two
methods of changing the user that procmail runs as. Using -d gives an
explicit user to change to, while -m forces procmail to get it from
the ownership of the rcfile. Of course -m does seem more complex.
Tell me, for users whose email is invoked with procmail as the LDA
(that is, not being invoked manually in a ruleset, or via an alias
running a PROGRAM), do these people have problems? I suspect not.
This is the only real method of delivery, so this is a tough one to
answer.
You're having problems BECAUSE you're invoking procmail as root and
expecting that changing the invocation parameters will actually have
it behaving the same. The params are what define _how_ procmail
acts.
Not _who_ it becomes?
Get a six pack of Jolt(tm) and guzzle it down, wait a few minutes
(presuming that you don't enter a diabetic shock), then re-read my
previous post.
Uh, I gave up coffee about 3 months ago, and cut sugar to almost
nothing before that. This course of action would almost certainly
induce a heart attack or a coma or both :)
I did reread your last post though, and it seems I gave the impression
that I want procmail to run as a specific user. This isn't the case.
I want it to run as whichever user the current message being processed
is intended for. If a message comes in to leblanc, I want procmail to
execute spamassassin as if leblanc had gotten onto the commandline and
called it from his prompt. If the message comes in to kim, I want
spamassassin called as if kim had called it from her command line.
And so on. Is this even possible?
/etc/procmailrc
is a FILE. That SPECIFIC file (path and name) has special meaning
to procmail WHEN RUN AS THE LDA (via mlocal ruleset). See the
manpages.
/etc/procmailrcs/
is a DIRECTORY, which that specific directory path has special
meaning to procmail when invoked with files within that directory -
it will assume the identity of the owner of whatever rcfile is being
run within that directory. Again, see the manpages.
Thus, if you have a sendmail rule or alias, and you want it to run
something AS A SPECIFIC user, you should place the rcfile within
/etc/procmailrcs/ and provide that path to procmail.
I got it now. The file that procmail initially invokes should be in
that directory somewhere. I couldn't find specific references to it,
but I assume having a /etc/procmailrcs/$user/procmailrc setup, with
each $user directory owned by the user, as well as the procmailrc
within, would be suitable?
*THAT* rcfile can contain a line such as:
INCLUDERC=/etc/procmailrc
to invoke the /etc/procmailrc rules. However, I don't _believe_
(not having a need to do this myself) that procmail would for any
reason "re-assume" root perms when running the _included_
/etc/procmailrc file. That'd be a serious security breach anyway,
since running something as an unprivledged user who could change
operational variables THEN include a root'ed rcfile which would
behave differently would pose serious problems.
This I understand too. So why bother invoking /etc/procmailrc, except
to handle the delivery from a single place?
file (like ~/.procmailrc) owned by the user I want it to switch to.
And of course, the sendmail invocation should be more like
procmail -Y -m /usr/local/etc/procmailrcs/procmailrc $u $h
FTR, just in case you missed it, /usr/local/... isn't
/etc/procmailrcs/
Right, I got that now too.
The procmail manpage makes specific reference to excluding parent
references, (/etc/procmailrcs/../../home/schmuck/gotcha.rc for
instance), and by a similar token, I expect that links from other
directory paths probably don't fly, even if the file might
eventually have a link in /etc/procmailrcs/.
As I understood it, links were ok, but better safe . . .
[snip - manpage excerpt]
Procmail will setuid to the intended recipients and
delivers the mail as if it were invoked by the
recipient with no arguments (i.e., if no rcfile is
found, delivery is like ordinary mail).
Re-read that several times please. Out loud, deliberatley
enunciating the words.
Right. This does sound like what I want, so I do need the -d format.
The question is wether this would hose the delivery that actually
happens at the end of the system wide procmailrc (currently
/etc/procmailrc)?
SPECIFICALLY, it'll handle the /etc/procmailrc just as it would if
procmail were invoked as the LDA. If that means you're delivering
via /etc/procmailrc instead of dropping through to the ~/.procmailrc
(please refer to your SUBJECT line), then that's how it'll deliver.
I have been INCLUDERCing ~/.procmailrc from /etc/procmailrc. The
actual deliver call is at the end of /etc/procmailrc. I have no
problem doing it the other way around, or INCLUDERCing /etc/procmailrc
at the end of ~/.procmailrc if it's a better way to do it.
For reference, a typical mlocal invocation of procmail (directly
from sendmail's own procmail_local feature exansion) would be:
procmail -Y -a $h -d $u
I take it $h is the plussed address extension, and $u is the recipient
username. How are these accessed in the procmailrc? The way I am
doing it, it's $u $h, just in case there isn't a plussed extension.
The first lines of /etc/procmailrc:
LOGNAME = $1
FOLDER = $2
and the last:
:0 w
* FOLDER ?? .
| /usr/local/cyrus/bin/deliver -q -m "$FOLDER" -- "$LOGNAME"
# Only if there was no extension do we try this
:0 wE
| /usr/local/cyrus/bin/deliver -q -- "$LOGNAME"
# Whichever one we tried, failed
EXITCODE = $?
HOST
Of course, I run a lot of recipes in between both in /etc/procmailrc
and in ~/.procmailrc, sometimes changing the value of folder, wether
it was passed in or not, but this always works. Except I don't want
it running as root anymore, but the recipient.
That '-d $u' is what makes procmail act like an LDA, and that's
exactly what makes it invoke /etc/procmailrc first (processed as
root), check for a ~/.procmailrc file (processed as $u), and all
that.
Refer to the manpage for the meaning of the switches, and to the
sendmail documentation for the intended contents of the variables.
I have been looking at the procmail manpage. I am slowly starting to
understand more and more of it - thanks in no small part to your help.
As for the sendmail docs, I'm still looking for the variable
descriptions. /usr/share/sendmail/cf/README has always helped in the
past, but it doesn't seem to have this bit of info.
Thank you Sean. I profoundly appreciate your patience with me on
this. I'm going to reread each of your messages (and mine) as well as
the manpages - tomorrow. Then I'll see if I understand it and try
again.
Good night.
Lou
--
Louis LeBlanc leblanc(_at_)keyslapper(_dot_)org
Fully Funded Hobbyist, KeySlapper Extrordinaire :)
http://www.keyslapper.org ԿԬ
One small step for man, one giant stumble for mankind.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail