GNU Info

(am-utils.info)Distributed Mail Spool Service

---

Next: Why Deliver Into the Home Directory? Prev: Centralized Mail Spool Directory Up: Background to Mail Delivery

---

Enter node , (file) or (file)node

Distributed Mail Spool Service
------------------------------

   Despite the existence of a few systems that support delivery to
users' home directories, mail delivery to home directories hasn't
caught on.  We believe the main reason is that there are too many
programs that "know" where mailbox files reside.  Besides the obvious
(the delivery program `/bin/mail' and mail readers like `/usr/ucb/Mail',
`mush', `mm', etc.), other programs that know mailbox location are
login, from, almost every shell, `xbiff', `xmailbox', and even some
programs not directly related to mail, such as `emacs' and `trn'.
Although some of these programs can be configured to look in different
directories with the use of environment variables and other resources,
many of them cannot.  The overall porting work is significant.

   Other methods that have yet to catch on require the use of a special
mail-reading server, such as IMAP or POP.  The main disadvantage of
these systems is that UAs need to be modified to use these services --
a long and involved task.  That is why they are not popular at this
time.

   Several other ideas have been proposed and even used in various
environments.  None of them is robust.  They are mostly very
specialized, inflexible, and do not extend to the general case.  Some of
the ideas are plain bad, potentially leading to lost or corrupt mail:

automounters
     Using an automounter such as Amd to provide a set of symbolic links
     from the normal spool directory to user home directories is not
     sufficient.  UAs rename, unlink, and recreate the mailbox as a
     regular file, therefore it must be a real file, not a symbolic
     link.  Furthermore, it must reside in a real directory which is
     writable by the UAs and MTAs.  This method may also require
     populating `/var/spool/mail' with symbolic links and making sure
     they are updated.  Making Amd manage that directory directly
     fails, since many various lock files need to be managed as well.
     Also, Amd does not provide all of the NFS operations which are
     required to write mail such as write, create, remove, and unlink.

`$MAIL'
     Setting this variable to an automounted directory pointing to the
     user's mail spool host only solves the problem for those programs
     which know and use `$MAIL'.  Many programs don't, therefore this
     solution is partial and of limited flexibility.  Also, it requires
     the SAs or the users to set it themselves -- an added level of
     inconvenience and possible failures.

/bin/mail
     Using a different mail delivery agent could be the solution.  One
     such example is `hdmail'.  However, `hdmail' still requires
     modifying all UAs, the MTA's configuration, installing new
     daemons, and changing login scripts.  This makes the system less
     upgradable or compatible with others, and adds one more
     complicated system for SAs to deal with.  It is not a complete
     solution because it still requires each user have their `$MAIL'
     variable setup correctly, and that every program use this variable.