[ On Wed, December 4, 1996 at 18:43:25 (-0500), Jim Wise wrote: ]
> Subject: Re: Mail and locking
>
> 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.

What gave you that idea?  If the mail user agent is capable of using an
intermediate spool file or a mail access protocol such as IMAP or POP
(and which non-standard-to-NetBSD ones are not?), then an appropriate
protocol (movemail, POP, or IMAP for example) can be defined as the
standard mailbox access protocol for the mail domain, with trivial
clients supplied for wrappers around non-conforming MUAs.

>     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...

Again, this is untrue if a single mailbox access protocol is defined for
the mail domain.  In fact this should *reduce* the administrator's
workload, and I would highly recommend it in any case.

Of course many mail programs *are* prepared to run sgid (SysV rqmt).

>     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...

Then don't use NFS -- I wouldn't trust it for mail delivery in the first
place.  Multi-client mailbox access is an ideal application of something
like IMAP (or even POP).

> > 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.

No, *BSD, or at least NetBSD doesn't yet implement the POSIX option of
allowing non-root chown(2) for filesystems without _POSIX_CHOWN_RESTRICTED.

Just how many systems have you seen which do have quotas enabled, even
just for /var/mail?  I sometimes see on a peak of a dozen mail machines
a week, and I only know of a handful that have had quotas enabled.  I've
implemented them myself on a few more as a quick fix, but they're either
unusable or difficult to manage on many systems and therefore not used.

I see few enough systems which have /var as a separate filesystem, let
alone /var/mail a separate filesystem from the MTA queue filesystem.

> 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.)

I don't know for sure of any unix-based freeware delivery agents which
support mailbox size limits independently of quotas, though I know it's
a commonly requested option.  I think exim will have this feature soon,
and I know smail will.  There is at least one commercial MTAs with this
feature.  Smail will avoid resource starvation by delaying delivery if
the target filesysem is too full (and should also refuse connections if
the incoming queue directory is full).

In practice I wouldn't worry about allowing un-restricted chown() even
with quotas on /var/mail.  If in a well configured environment you would
forever lose all your mail if you were to chown away your mailbox in
some vain effort of avoiding the quota or trying to perform a temporary
denial of service attack on another user by using up their quota.  These
tricks are also easy to spot in a periodic security scan too, and since
no long-term damage would happen, I just wouldn't worry about it.

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

Creating mailboxes at account creation time is trivial, and if you do it
often enough I'd hope you already have an extensible mechanism for
automating the procedure.

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

Quotas are far too often ignored in practice.

-- 
							Greg A. Woods

+1 416 443-1734			VE3TCP			robohack!woods
Planix, Inc. <woods@planix.com>; Secrets Of The Weird <woods@weird.com>