[Raw Msg Headers][Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: checking for new mail



I still use delivery to user home directories (but with IDA sendmail for
various reasons, some of them non-technical; fortunately, we have a
relatively light email load compared to cs.toronto.edu)

I find the advantages of delivery to home dirs outweigh the
disadvantages, in part because our users are distributed over a wider
range of machines and subnets (in some cases, on servers separated by
fragile or insecure low-speed WAN links over which we'll permit smtp, but
not nfs!).  At present, we use $HOME/.Mailbox as the file name -- we just
use a locally written delivery program instead of sendmail's local
delivery agent.  Over a year of experiment and no one's deleted it by
mistake yet (I wouldn't have believed it if I hadn't seen it with my own
eyes :-)

Delivering to user home dirs can't be all that uncommon -- MH seems
to have support for it already.  We use something like
mail            .MailBox
in the MH config file.

It turned out that most (all?) user agents honor the MAIL environment
variable as the location of the mailbox and do the right thing, so we
haven't had to modify much software -- just set MAIL to the right thing.
If we find software that doesn't honor the MAIL convention, we fix it to
honor the convention and send back the fixes to the author -- the fixes
are generic enough that authors tend to accept them.

We didn't change the locking protocol, but we do take steps to ensure
that mail is never delivered over NFS (mapping from user-name to
home-directory-fileserver-name, forward the mail there).  Again, this
seems to work, though I don't trust user agents to get this right.

Home directories filling up sends our users into a frenzy anyway, so we
keep a wary eye on that sort of thing.  Good budget for new disks,
fortunately :-)

	Mark.