3 Design

  We named our file system the Home-Link File System, because that's all it does -- provide symbolic links to files and directories in a user's home directory. The soft link has a fixed name, but unlike regular soft links, what it points to is ``dynamic'' depending on who accesses the symbolic link. The ideas that this filesystem represents are not limited just to handling electronic mail -- that is only one application of this filesystem. See Sections 7.1 and 7.2 for other ideas.

Our key goals in designing HLFS were:

1.

To provide every user with the ability to read mail from any host.

2.

To ensure that all MTAs and UAs in use, as well as any other utilities which depend on the standard mail spool directory, face no problems from the change in the underlying filesystem.

3.

To minimize the possibility of mail being lost or bouncing back to the sender.

4.

To provide more privacy for users' mail files.

Since most sites provide access to users' home directories from any host, it made sense to store incoming mail there as well. That way, as long as users could log into a host and access their home directories via NFS, their mail would be accessible as well. This solved the first problem. Also, since users must login in order to read their mail, causing their home directories to be automounted, no extra mounts are required in order to begin reading mail.

The second problem was solved by making sure that the final access of the mail spool directory remains a ``real'' directory (not a read-only pseudo-filesystem provided by an automounter). All UAs access the spool directory for reading and writing the user's mail file and create lock files there. That means that /var/spool/mail needs to be readable, writable, and searchable for UAs and MTAs so that lock files can be written and removed. See also Section 4.6. For the purpose of writing the mail and lock files, a subdirectory inside the user's home directory is sufficient, since it is already owned by that user. Ensuring that users cannot access other users' files can easily be achieved by protecting this subdirectory.

In order not to change the behavior of programs like comsat[21,23], from or finger, which are designed to read any user's mail, we implemented a special check for a designated group. If the effective gid of the process is the designated group, we assume that such a special program is executing, and hlfsd arranges to do the lookup not only of the real spool directory, but of the mailbox itself. See Table 2.

 

Conditions: gid=HLFS_GID for any uid.  

Pathname left Value if symbolic link

/ var/mail/NAME

var/ mail/NAME

$$\Rightarrow$$ mail@ /mail/home/NAME

/ mail/home/NAME

mail/ home/NAME

$$\Rightarrow$$ home@ NAME

./ NAME

$$\Rightarrow$$ .mailspool/NAME

.mailspool/ NAME

Note that this method only supports read access without locking; however, this is sufficient for all programs that need to access other users' mailboxes. All that is required is to set these programs to be setgid to the designated group.

The third problem is solved by ensuring that all operations which might hang hlfsd are performed in the background, while still providing service in the parent or child process. Furthermore, if hlfsd is not running anymore, or if the user's home filesystem is full, mail gets delivered to an alternate directory (See also Section 4.3). A cron job (running several times a day in our department), looks at the alternate directory, and attempts to resend messages in it to their rightful owners. All that is incurred is a delay in mail delivery, which, in most cases, is no longer than the length of time between consecutive invocations of the lost-mail remailing script.

Having a special mail-spool subdirectory owned and controlled by the user also addresses the last problem, that of privacy. Users can change the protection bits on their mailbox directory inside their home directory so that it is readable and searchable only by the owner. Any other program or user, unless running as the superuser on the same host, would not be able to find out whether a user has new mail, how much of it there is, or when it was last read.