Chris,
I used to be the manager of the system support in the College of Engineering,
at the University of California, Santa Barbara.
We supported about 1500 users from two HP 9000 G30's, using one of them
as the centralized mailer. Mail was available via NFS exported /usr/spool/mail
to over 200 workstations, of all kinds: SGI, HP, Sun, etc.
We replaced /bin/mail with procmail as the local mailer (Mlocal) because
procmail correctly avoided NFS-locking problems, and it supported
user-configurable mail filtering, without compromising system security.
In over two years subsequent to the change, we had no loss of mail due
to procmail being used as the local mailer. If you wish further comment
from the current system managers, send email to
"postmaster(_at_)eci(_dot_)ucsb(_dot_)edu".
To answer your specific questions:
* you can configure the permissions directly, by changing one of the
following defines in config.h:
#define UPDATE_MASK S_IXOTH /* bit set on mailboxes when mail
arrived */
#define OVERRIDE_MASK (S_IXUSR|S_ISUID|S_ISGID|S_ISVTX) /* if found
set */
/* the permissions on the mailbox will be left
untouched */
#define INIT_UMASK (S_IRWXG|S_IRWXO) /* ==
077 */
#define GROUPW_UMASK (INIT_UMASK&~S_IRWXG) /* ==
007 */
We did not find it necessary, however.
* We did disable all locking except dot-locking, since the kernel locks
were the source of the NFS-locking problems. There have continued to
be occasional locking problems, but these are "victim"-induced
problems caused by using non-supported and discouraged mailers, such
as "mailtool" from older Suns. These locking problems have nothing
to do with mail delivery, but from the mail client using
kernel-advisory locks, and then orphaning them or, leaving them
locked all day long.
* An alternative to having users use .forward files, is to create a file
of users who would leik to use procmail as their local delivery agent, and
use this file to initialize a class variable.
Write a special rule in sendmail.cf which delivers mail using Mprocmail
instead of Mlocal when the destination user is in the special procmail
user class.
This allows users who want procmail-direct delivery in spite of
management worrying.
I set this up to test procmail delivery on our system before changing
Mlocal to use procmail. We placed some "volunteer" users in the procmail
class file, and they never had any problems (I was one of them).
Hope this helps.
___________________________________________________________
Alan Stebbens <aks(_at_)sgi(_dot_)com> http://reality.sgi.com/aks
Here at Indiana University we have a collection of 5 HP K series being
used as mail client only servers for between 10,000 and 15,000 users
per box.
User demand has declared that procmail should be installed on these
machines. Management fear and desire to not mess with the status
quo has declared that procmail will not be installed the local mailer.
Therefore we will have users that are calling procmail from their
.forward files.
In this situation it appears that mail that procmail delivers back
into the spool it is writing out with owner.group user.mail and
rights 600. To me this is reasonable.
These K boxes are running sendmail 8.7.1 owner root, group mail,
setuid, setgid and sticky. /bin/mail is owner root, group mail, setuid
and setgid. /var/mail is 1777
Mail delivered to the spool by /bin/mail is written out owner user,
group mail 660.
When procmail delivers mail 600 later attempts at delivery with
procmail removed from the .forward file fail: /bin/mail doesn't have
permissions (or refuses to uses its permissions).
Since we have fickly and unruly users who will be moving their
.forwards in and out of place this is a problem.
Is the correct solution to force procmail to write 660? If so, how is
this done? I assume in the section of config.h just below the warning
about only messing with a section if you think you know what you are
doing. I don't like feel like I know well enough what I'm doing to
walk into that territory without some guidance.
Or, is the correct solution to change something about the setup I
described above?
Thanks for any help, direction, pointers etc.
--
Chris Dent <cdent(_at_)indiana(_dot_)edu>
http://detritus.ucs.indiana.edu/~cdent/