procmail
[Top] [All Lists]

Re: Plussed addresses & procmailrcs problem

2003-02-07 09:13:08
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 subscribed.

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[3941]: Denying special privileges for
"/etc/procmailrcs/onepop.rc"

'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 appropriate either.

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 content periodically.)

---
 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
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail