1 Introduction

  Electronic mail has become one of the major applications for many computer networks, and use of this service is expected to increase over time, as networks proliferate and become faster. Providing a convenient environment for users to read, compose, and send electronic mail has become a requirement for systems administrators (SAs).

Widely used methods for handling mail usually require users to be logged into a designated ``home'' machine, where their mailbox files reside. Only on that one machine can they read newly arrived mail. Since users have to be logged into that system to read their mail, they often find it convenient to run all of their other processes on that system as well, including memory and CPU-intensive jobs. For example, in our department, we have allocated and configured several multi-processor servers to handle such demanding CPU/memory applications, but these were under-utilized, in large part due to the inconvenience of not being able to read mail on those machines. (No home directories were located on these designated CPU-servers, since we did not want NFS service for users' home directories to have to compete with intensive jobs. At the same time, we discouraged users from running demanding applications on their home machines.)

Many different solutions have been proposed to allow users to read their mail on any host. However, all of these solutions fail in one or more of several ways:

• they introduce new single points of failure
• they require using different mail transfer agents (MTAs)[15] or user agents (UAs)
• they do not solve the problem for all cases, i.e. the solution is only partially successful for a particular environment.

We have designed a simple filesystem, called the Home-Link File System, to provide the ability to deliver mail to users' home directories, without modification to mail-related applications. We have endeavored to make it as stable as possible. Of great importance to us was to make sure the HLFS daemon, hlfsd, would not hang under any circumstances, and would take the next-best action when faced with problems. Compared to alternative methods, hlfsd is a stable, more general solution, and easier to install/use. In fact, in some ways, we have even managed to improve the reliability and security of mail service.

Our server implements a small filesystem containing a symbolic link to a subdirectory of the invoking user's home directory, and named symbolic links to users' mailbox files. An example, using pathnames from our environment, is depicted in Figure 1.

  

Figure 1: Hlfsd resolving the NAME component of /mail/NAME

The hlfsd server finds out the uid of the process that is accessing its mount point, and resolves the pathname component home as a symbolic link to a subdirectory within the home directory given by the uid's entry in the password file. See Table 1.

 

Conditions: uid=ezk, gid$\neq$HLFS_GID, and /users/ezk/.mailspool/ is writable.  

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

/ users/ezk/.mailspool/NAME

users/ ezk/.mailspool/NAME

ezk/ .mailspool/NAME

.mailspool/ NAME

If the gid of the process that attempts to access a mailbox file is a special one (called HLFS_GID), then the server maps the name of the next pathname component directly to the user's mailbox (Table 2). This is necessary so that access to a mailbox file by users other than the owner can succeed. The server has safety features in case of failures such as hung filesystems or home directory filesystems that are inaccessible or full.

On most of our machines, mail gets delivered to the directory /var/spool/mail. Many programs, including UAs, depend on that path. Hlfsd creates a directory /mail, and mounts itself on top of that directory. Hlfsd implements the path name component called home, pointing to a subdirectory of the user's home directory. We have made /var/spool/mail a symbolic link to /mail/home, so that accessing /var/spool/mail actually causes access to a subdirectory within a user's home directory.

The rest of this paper is organized as follows. Section 2 discusses in detail the problems and limitations of other home-mail-delivery methods. Section 3 detail the design of the Home-Link File System and Section 4 describes the implementation of hlfsd. Section 5 evaluates our implementation. Related systems, conclusions, future directions, and alternative uses are described in Sections 6 and 7.