Ed McGuire <emcguire(_at_)i2(_dot_)com> writes:
...
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.
If you're using sendmail V8, then it's the 'w' mailer flag which does
it, though it really causes more than just .forward file processing.
You would probably be better off setting the forward file path to point
to /dev/null.
Not having $HOME brings up other issues: if someone wants to use procmail
to pre-sort mail into folders, can they somehow get access to their
home directory? Perhaps if they could forward the message to the machine
which had their home directory and let it do delivery (but this gets
really complicated really fast!)?
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.
...
Better idea: change the PROCMAILRC definition in config.h to something
like "/var/procmailrcs/$LOGNAME". Don't use /etc/procmailrcs as that
just confuses the situation. /var/procmailrcs should be mode 1777.
Procmail will do the permission checks on the procmailrc automatically
(it does them no matter what).
Hmm, if people can give away files using chown(), then I'm not 100%
sure the above is safe. I know procmail is paranoid in this case
about /etc/procmailrcs/, but after staring at the code I'm not sure
it's paranoid enough about the user's procmailrc. I'll have to ask
Stephen about this.
Regardless of the above, to comment on your suggestion:
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.
procmail -m /etc/procmailrcs/some-file will run as the owner of that
file, *regardless of who invoked it*. Therefore, your first belief is
incorrect. Sorry.
Are you really on a system which let's people give away files with
chown()? From what I've heard, this produces enough security holes in
other random programs that you might as well give up if you don't trust
everyone.
Bigger question: Is our smart host a dumb idea?
It has its strong points and its weak points, as you've found. The
'best' setup that I know of is to have mail delivered on the fileserver
of the recipient, with the each user's mailspool inside their own
account. However, legacy systems make this hard to do (maybe I'll do
it here at Gustavus some summer, when I have nothing else to do.
<guffaw>).
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
Huh? The '|' flag is totally unrelated to $h. It controls recognition
of addresses that are to be delivered via the prog mailer. R-R-T: was
a bad idea and we should all be happy that sendmail V8 dropped support
for it. Use DSNs (Delivery Status Notifications) instead, or consider
implementing Dan Bernstein's Notice-Requested-Upon-Delivery-To: header
(see ftp://ietf.org/internet-drafts/draft-bernstein-nrudt-02.txt for
more information).
Philip Guenther