Xref: utzoo comp.sys.hp:3404 comp.mail.misc:2569
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!eru!luth!sunic!chalmers!lindberg
From: lindberg@cs.chalmers.se (Gunnar Lindberg)
Newsgroups: comp.sys.hp,comp.mail.misc
Subject: Re: HELP mail problem
Keywords: hpux 4.3BSD mail
Message-ID: <3424@chalmers.se>
Date: 9 Nov 89 10:22:17 GMT
References: <147@engr.wisc.edu> <649@nastar.UUCP>
Sender: news@chalmers.se
Organization: Dept of CS, Chalmers, Sweden
Lines: 32

My personal guess:

    In SunOS 4.0 /bin/mail is setuid(root) but it performs a
    setuid(user) before writing to /usr/spool/mail/user and thus
    no NFS problem.

    The HP:s (just like BSD VAX:en) have /bin/mail setuid(root) but
    without the extra setuid(user) before writing. NFS converts
    "root" to "nobody" - and the write() fails.

Now, the Sun solution works well in an NFS environment, but requires
/usr/spool/mail to be rwxrwxrwx - I don't like that! The BSD solution,
on the other hand, protects /usr/spool/mail but does not work well
with NFS... Nice, isn't it :-).

I would suggest the following work-around:

    +	Make all clients that NFS-mount /usr/spool/mail send *all*
	mail (including $#local) to the NFS-server (/usr/spool/mail).
    
    +	On that server you do all writing to /usr/spool/mail and if
	you use a BSD-/bin/mail you can protect /usr/spool/mail in
	the way you find convenient (if you have a Sun-/bin/mail the
	setuid(user) still prevents that - but that's another story).

	If the server is down, but your client is up, that situation
	is taken care of in the standard SMTP way - you don't rely on
	any NFS magic to handle it for you. The only drawback is that
	you get some extra SMTP-traffic between server and clients; if
	that's worse the the corresponding amount of NFS I don't know.

		Gunnar Lindberg