Re: Plussed addresses & procmailrcs problem
At 23:35 2003-02-07 +1300, Roland Hill did say:
While plussed addresses seem to work "normally", anything from this
list, and Redhat for that matter, go straight past my plussed address
recipe, and need to be picked up by a list specific recipe.
I know it may sound like a stupid question, but did you actually
uns*bscribe and then res*bscribe to this list?
Unless something has changed recently, the procmail list has an annoying
configuration: it allows posts from nonsubscribers (which is why I continue
to filter the procmail list through spam filters before allowing it into my
inbox, whereas many other lists are filtered before spam checks). Thus,
it's possible to post from a plussed address which isn't subscribed to the
list, but receive your post from the list at a non-plussed address which is
Because the test message which I sent to you originally was _BCC'd_ to you,
if you saw plussing in the message headers, it should be indicative that
your mail host actually stores plussed information during processing. The
messages delivered by a mailing list aren't really any different - they're
delivered as BCC'd messages.
Is this due to the about of "re-routing" these messages seem to go
through (you touched on this previously Sean I think)?
Hmm, I don't recall doing so. List messages travel from the senders mail
host to the list mail host, and from there to the subscribers' mailhosts,
whereas a b/cc travels from the senders mail host directly to your mail
host. Nothing unusual about that, nor "different" about the routing in
that this is how it always works - obviously the two routes are different.
Feb 7 22:48:16 rrl03 procmail: Denying special privileges for
'man procmail' search for 'deny'.
Make sure the file isn't group or world writeable (procmail views that as a
valid security problem). If that doesn't resolve it, your MTA probably
isn't invoking procmail with root privledges (whereby procmail can assume
another identity based on the file owner - a function of the rcfile being
in /etc/procmailrcs/), so you should determine who procmail is invoked as
and simply chown the rcfile to that user. No problem, since the rcfile
doesn't _need_ any special privs (it doesn't write to the spools, it
forwards to real local users, which re-invokes the MTA to engage the LDA).
I set the permissions for /etc/procmailrcs/onepop.rc that same as
/usr/bin/procmail, but it didn't fix it.
Uh, I don't think you'd want the +x bit, and the suid root wouldn't be
While you go to sort out what user procmail is being invoked as, you can
create another dir: /etc/genericprocmailrcs/
Move the onepop.rc file there, and change the alias to use that path, then
rebuild the alias hash. The error about changing owner should be
gone. You should still endeavour to figure out what the hell your MTA is
doing, but obviously, it isn't invoking procmail with root privs such that
it can do what it might otherwise be able to. Eventually, this limitation
of your MTA could cause you grief. In the meantime, put a "README" file in
the /etc/procmailrcs/ dir that states that your MTA is acting in this
fashion. That way, if you go to do something in the future which relies
upon this change-to-owner functionality, you'll have a reminder sitting
there. I can tell you (from other experiences) that there's nothing quite
like the feeling of idiocy when you've been hammering away at a problem,
and finally come to realize that you've had that problem before, but didn't
document it at the time.
There's nothing special about the above directory name (nor is it from the
procmail manpages - I made it up just now) - unlike with /etc/procmailrcs/,
procmail won't attempt to change who it is running as to mate with the
owner of that rcfile.
Hmm, who owns /etc/procmailrcs on your system anyway? I suspect you had to
create the dir yourself, and if so, even it might not have the right
perms. I don't put forth the following as the "one true way", but it's
what is on my systems and has run for years:
$ ls -ald /etc/procmailrcs
drwxr-xr-x 4 root root 4096 Feb 4 17:54 /etc/procmailrcs/
(it has a recent datestamp on this system because within that dir, there's
a link to a mailbox for quarantined messages, which receives changed
Sean B. Straw / Professional Software Engineering
Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
Please DO NOT carbon me on list replies. I'll get my copy from the list.
procmail mailing list