At 09:24 2005-08-07 -0600, Lloyd Standish wrote:
Now, my procmail script only runs as user "mydomain," the domain owner.
It receives only mail sent to user mydomain(_at_)mydomain(_dot_)com(_dot_)
Mail sent
directly to joe(_at_)mydomain(_dot_)com bypasses my procmail script and is sent
directly to the "joe" spool. In order to process mail by procmail for the
"joe" and "sally" pop accounts, I have to redirect it to
mydomain(_at_)mydomain(_dot_)com(_dot_)
I've got to wonder: can't the ISP operator set up the aliases for these
other addresses to invoke procmail? Using sendmail, with which I am
familiar, one might have a virtusertable entry like so:
joe(_at_)mydomain(_dot_)tld joe.mydomain.tld
(where joe.mydomain.tld might be the local username)
and in the aliases file:
joe.mydomain.tld: /var/spool/mail/joe.mydomain.tld
(that might be sort of how things are _now_) Change the alias to something
more like:
joe.mydomain.tld: "|/usr/local/bin/procmail -m
/etc/procmailrcs/mydomain.tld/deliver.rc joe"
The /etc/procmailrc/mydomain.tld/ dir would be owned by user mydomain, as
would the files within it. deliver.rc would be your script, and you could
manipulate it to do what you want. joe would be the first argument passed
to the script, which it could use to determine the final delivery point for
the message.
A retentive admin might wrap this all up in a script to change the
effective uid of the process, or explicitly invoke DROPPRIVS, though the
files under /etc/procmailrcs/ are already invoked using the UID of the
owner, and as a regular user, you can't create files owned by other users,
so I don't see that as being absolutely necessary.
THE PROBLEM (finally) is that once user joe's mail is filtered by user
mydomain's procmail script (my one and only procmail script), I cannot get
procmail to write to joe's mail spool. There is an ownership/privileges
problem. The procmail script runs as user mydomain, and does not have
permission to write to joe's mail spool.
Correct.
My idea is to make user mydomain and user joe belong to a group,
Well, arguably, your ISP could put you in a "mydomain" group (like a
group-as-user setup, which some distributions use by default, but obviously
your ISP isn't already doing this, and they don't need to do it for
everyone). They will need to set that up though - you can't set this up,
and as a user, you can't arbitrarily join a group.
You may encounter issues with the various mail-related daemons though:
delivery to the mailbox, POP and IMAP. The latter two should be running
with your uid when you log in to them, but initial delivery is a different
matter (yea, I get it that you'll be running procmail to deliver). If the
mailbox is deleted (say by a POP or IMAP session which completely empties
the file for some reason), when it gets automatically recreated, in all
likelyhood, it won't have the same group association, which can then lead
to troubles.
You'll need to review how your ISP deals with creating new POP accounts as
well.
and give
read-write privileges for these spool files to members of the group.
Should this work? Somebody at my web server said that the spool file
permissions HAVE to be 600.
For security reasons in a default setup, yea, they're supposed to be, and
depending upon what mail agents are in use, something might enforce that
(not entirely unlike procmail rejecting a ~/.procmailrc with poor
permission settings).
Another approach might be to use FETCHMAIL to invoke procmail on the
contents of certain mailboxes and then ultimatley forward them to DIFFERENT
mailboxes (presuming you have a number available to do this with). This
however is a post-processing operation - the mail would arrive in the
mailbox first, and then (say, invoked by cron), fetchmail would retrieve
the messages, pipe them to procmail, with a username specified as an
argument, and that procmailrc would filter the messages and forward to the
"secondary" (filtered) mailbox which you'd actually have a mail client set
up to retrieve email from. Ugly and kludgy-like, but if you have the
additional boxes available to do it with, it might be more straightforward
and should definatley be doable, without requiring the ISP to change things
for your account.
Finally, you could just get some rack space and run your own server to
process your mail as you see fit. <g>
---
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 homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail