Info Node: (am-utils.info)Distributed Mail Spool Service
(am-utils.info)Distributed Mail Spool Service
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.