procmail
[Top] [All Lists]

creating a .procmailrc "farm"

1997-09-07 19:31:29
I would like help with a tough procmail-sendmail problem.

We have a single mail spool, NFS exported to many systems.  Users can
thus process their mail from any UNIX system.  The server having the
mail spool is a "smart host," supporting mailing list expansion, local
mail delivery, and all gateways to other mail systems.  Every other
UNIX system forwards all mail to the smart host.

We have long since stopped mounting user home directories on the smart
host because the search for $HOME/.forward blocks mail delivery
indefinitely when they are unavailable for whatever reason, and because
it's hard to keep up with all those mounts except with the automounter
-- which sometimes goes into a high priority loop upon encountering an
unavailable server.  (If there were no problem with the mounts, I would
have just stopped using the local mailer, as that's the key which
causes sendmail to look for the $HOME/.forward.) So as a consequence
$HOME doesn't exist for most users.

Assuming that this setup was the reasonable thing to do, my challenge,
then, is to configure procmail to run /etc/procmailrc with super-user
credentials and then run a substitute rcfile with the recipient's
credentials.  I want the users to be able to create and maintain their
own substitute rcfiles.  So here is what I am thinking of.

Create /etc/procmailrcs/, owned by uid 0, world write, sticky bit set.
NFS export it.

Create /etc/procmailrc, with the following recipe at the end which
expects a substitute rcfile called /etc/procmailrcs/$LOGNAME.  Pass it
the "meta-information" argument if present.

  DROPPRIVS=yes         # be the recipient
  :0
  | procmail -Y -m /etc/procmailrcs/$LOGNAME "$1"

My belief is that the substitute rcfile will only be invoked if owned
by the recipient.  However, I believe this fails to prevent an
unscrupulous person from creating a trojan rcfile under someone's name
and then chowning it to the person.

Is there a simple solution other than write-protecting /etc/procmailrcs
and creating empty rcfiles there for all users?

Bigger question:  Is our smart host a dumb idea?

Another issue.  I have integrated procmail with sendmail.  Sendmail no
longer honors return-receipt-to, because that is dependent upon the "l"
flag being present and that flag must be absent for the "meta-
information" argument to be passed via $h.  That means /etc/procmailrc
must honor return-receipt-to.  The proposed solution is the following
recipe.

  :0 c
  {
    :0 h
    * ^return-receipt-to:[        ]*\/.*
    | (echo 'Precedence: junk'; echo 'Subject: mail received'; echo; cat) | 
$SENDMAIL "$MATCH"
  }

Anybody care to tear this to shreds?

Regards, Ed

-- 
To prove the viability and simplicity of the NC, Mr. Ellison assembled a
complete network during the broadcast. He instructed the audience that if they
had any problems installing NCs they should "Send me an e-mail at
Larry(_dot_)Ellison(_at_)Oracle(_dot_)Com and I'll come to your house and hook 
it up."

<Prev in Thread] Current Thread [Next in Thread>