I know this thread mostly died out a few days ago, but I've been busy. Sorry
to jump in so late.

I like the qmail-ish ideas proposed here, but since we need working code,
how about a workable (and *working*) compromise?

At Panix, we've got a mail system running on NetBSD machines that does most
of what people here seem to want the most:

- delivery into $HOME/.mailspool/$USER (but that could easily be twiddled)
- mail.local is totally nfs-safe. You *can* deliver from multiple mail
  hosts to multiple clients safely.
- compatability with all the software we've ever thrown at it, possibly
  excepting one or two things (like mush, as pointed out earlier), which
  we could have solved without source mods by building a /var/mail full of
  symlinks.

The mail.local was worked on by me, Thor, and Eric Volpe. The nfslock code
is a library I wrote based on some work by Thor on something Chuck Crainor
wrote years ago. In a couple of years of use by thousands of users, we've
*never* seen mailbox corruption in mail.local. Since it uses dotlocks, all
the various mail clients are happy to work with it. (Yes, they *could*
conceivably break things if they're not modified to understand nfs locking
with libnfslock, but that's true no matter how you handle mail spools
when you're running across NFS; in practice we've never seen that either.)

libnfslock has a couple advantages over other code like it (such as procmail's)
in that it's a little bit paranoid about releasing dotlocks; it tries to
make sure that it owns the lock, so that it the protocol breaks in one way
(perhaps because of some code that's doing dotlocks without obeying all
the conventions, which can happen) it'll back off and not wipe out that
"stolen" lock, so a third process can't come along and stomp on the second's
work. There's still a possibility of corruption in the conflict between
the first process (using libnfslock) and the second, but you're less exposed.
libnfslock also eliminates certain security checks that are critical in
a common-directory environment (to protect against race attacks) but which
are just a performance loss in a private-directory environment.

Anyway, this stuff is at least moderately cool and is very nearly a drop-in
replacement for the current code. I'm happy to donate it to the NetBSD project
if it can find a roost in the tree...

/a

---
Alexis Rosen   Owner/Sysadmin,
PANIX Public Access Unix & Internet, NYC.
alexis@panix.com