On Wed, 4 Dec 1996, Greg A. Woods wrote:

> If the local delivery and mail-pickup processes are setgid to the unique
> member-less group which owns and has write permission on /var/mail, and

FWIW, I think it is a _bad_ idea to require this.  It immediately raises two
problems in the porting of mail packages to NetBSD:

    1.) Users cannot port mail agents without the help of the admin
        staff.  I think this is an unnecessary restriction...  In the
        past, I have often had reason to, for example, install a mail
        reader, or, say, procmail on a machine I had only a user account
	on.

    2.) The admin staff must do a lot more work to provide a new mail
	program.  Many mail programs were not designed to be run sgid/suid
	and would not adapt well to this (would need shell escapes
	removed or wrapped up, for example).  Even those that were would
	need a good going-over before I would suid them on any sytem
	I administer...

    3.) It doesn't work well in an NFS environment..  It is unwise to
	depend on sgid/suid access in an environment where the mail
	spool may be mounted from another OS or where the client may
	not be trusted...

> the system supports the POSIX notion of giving away files on quota-less
> filesystems, and /var/mail is on such a filesystem, then life with

But BSD doesn't, and I can think of _no_ good reasons that /var/mail should
be required to be quota-less.  In fact, that strikes me as asking for trouble.

> mailers can become very mundane and routine with few risks to anyone.
> Of course it also helps if the delivery process can enforce local policy
> too, such as maximum mailbox sizes with decent bounce explanations; and
> if there's an ftruncate() system call....  If you can't give away a

Of course it would be nice, but do you know of any delivery agents which
actually do this?  (An honest question -- I've never seen any that do.)

> file on a given system, then the only change to this schema is that
> mailboxes must be created by root instead of by the mailman, and must
> never be removed.

Another point where you seem to be requiring more work for no real gain...

> Maybe we can blame all the CERT sendmail advisories on the silly need to
> support the filesystem quotas so rarely used in practice.  [0.5 ;-)]

So rarely used?  I've _never_ run a general use system without mail quotas,
and know of noone doing so!

> Please be very careful how you define "reliable" here.  It is extremely
> reliable when the correct algorithm is implemented properly.  What
> you're saying is only that many people cannot write correct code the
> first few times around.  There's nothing new in that!
 
I fail to see how your approach helps this...

--
				Jim Wise
				System Administrator
				GSAPP, Columbia University
				jim@santafe.arch.columbia.edu
				http://www.arch.columbia.edu/~jim
				* Finger for PGP public key *