3. System Architecture
This sections describes which servers were used and how they all fit together at a system level.
3.1. Software Selection
Choosing one piece of software over another can often become the place of holy wars on the scale of emacs vs. vi. One could write a paper debating the merits of each of the SMTP servers out there, for example. This section briefly describes our choices for an SMTP server, an IMAP server, an LDAP server, and webmail software.
3.1.1. Postfix
One of the most important aspects of our MTA/MDA was that it would easily support virtual users. The other one was that it would allow local users to continue to use procmail[17] for their filtering to keep their mailboxes in order. We also wanted to keep the configuration easy for the administrator. Postfix[14] fits the bill quite nicely.
Postfix is my attempt to provide an alternative to the widely-used Sendmail program. Postfix attempts to be fast, easy to administer, and hopefully secure, while at the same time being Sendmail compatible enough to not upset your users. | ||
| -- Wietse Venema [13] | ||
Postfix is designed modularly with many small programs working together to fill the mail service role. Most of Postfix runs as a non-root user and most parts of Postfix can run in a chroot environment. While still a relatively new mailer, it has a design that lends itself to long term security. Its configuration is straight-forward and very human readable. All of the parameters are of the "key = value" variety.
Starting with Postfix 1.1.x a virtual user mail delivery agent has been included. This makes delivery to virtual mailboxes very easy with only a few lines added to the config. It's also very easy to integrate LDAP into Postfix. Another benefit is the fact that it was made to be a drop in replacement for Sendmail. So, if a program is designed to work with Sendmail, it'll most likely work with Postfix.
It should also be noted that Sendmail [22], Qmail [18], or Exim [2] may work in this situation as well. We just had a greater familiarity and confidence with Postfix for this task. A lot of the rest of what is described in this document will apply to the other MTAs at a high level, but your mileage may vary when it comes to implementation.
3.1.2. Courier-IMAP
There are numerous IMAP servers for Unix available, the most popular being UW IMAP from the University of Washington [24]. UW IMAP, however, does not support the Maildir format nor does it support virtual users. Thus, we decided to use Courier-IMAP [1], a popular alternative IMAP server that works only with Maildir format.
Native support for Maildir was the original attraction to Courier, but it also has good support for virtual users, LDAP, and IMAP over SSL. It also integrates nicely with procmail since procmail can deliver to Maildir directly, too.
I should point out that procmail can only work for local users and not virtual users. In practice this works out fine because virtual users have no way of editing the .procmailrc file since they do not have shell access. If you want procmail for both local and virtual users, you may have to choose a different IMAP server or a different method of integrating the pieces.
3.1.3. OpenLDAP
There's really only once choice for Open Source LDAP servers and that's OpenLDAP [12]. It is more than capable of handling everything we need, including support for LDAP over SSL and advanced authentication encryption algorithms such as salted SHA and salted MD5. There have been some doubts as to the scalability and stability of OpenLDAP for huge systems, but we have not experienced any problems. You may consider using a commercial LDAP server such as iPlanet's Directory Server [9], Novell's eDirctory [11], or OctetString's VDE Directory Suite [25], all of which run on Linux.
3.1.4. Jamm
There wasn't really any software out there that did what we wanted in terms of easily allowing people to admin their own domains, so we rolled our own. Jamm [4] is a web application to manage virtual email account information stored in an LDAP directory. It is meant as an administration tool for sites using mail servers that store virtual user information in LDAP. Jamm is essentially an application specific LDAP editor and does not manage mail server specific configuration files. This makes Jamm quite portable to any SMTP, POP, or IMAP server so long as it supports LDAP. It also, however, means that some adminstration needs to take place outside of Jamm, such as cleaning up disk space of deleted accounts.
3.1.5. SquirrelMail
There are many choices of webmail systems. Some read directly from the file system, while others use IMAP or POP. We were recommended SquirrelMail [23], a PHP-based IMAP client, and it has worked out very well. Another webmail client that comes with good recommendations is IMP [7]. Be sure to check Freshmeat [3] for more options.
3.2. The Big Picture
Figure 1 shows how Postfix, Courier, Procmail, OpenLDAP and Jamm interact with each other. Postfix accepts incoming mail from SMTP and delivers it to the maildir mailboxes on the file system. It needs to have a list of valid users so it can bounce email for unknown users. It also needs to know where each user's mailbox is located on the file system so it can properly deliver messages. Postfix delivers the mail itself for virtual users and uses procmail as the MDA for local users.
Courier provides remote access to the maildir mailboxes via the IMAP and POP protocols. It needs to have a list of valid users and some means to authenticate them so users can log into their account. It, too, needs to know where each users' mailbox is located on the file system so it can read their messages.
Local user information can be accessed from the standard account database. A list of valid users can be obtained from /etc/passwd. The users' home directory, which can also be obtained from /etc/passwd, provides the location of the mailbox. Authentication can be handled by standard Unix mechanisms, such as pluggable authentication modules (PAM).
Virtual user information is stored in an LDAP directory since LDAP provides a mechanism for searching for valid users, getting user information, and authenticating users. It is possible to avoid an LDAP directory, but it will be more difficult to administer the virtual user information. For example, Postfix and Courier both support virtual users without LDAP using configuration files, but they have different file formats. It is possible to write scripts to keep these two sets of configuration files in sync, but it can be a chore and is error prone. Also, these file formats are not standard and require custom code to access them. LDAP is a much cleaner solution since it provides a standard interface for accessing the directory and many languages provided LDAP APIs. Jamm speaks LDAP and can manipulate the mail alias and account information stored in LDAP.
3.3. Mailbox Location
Local users' mail is stored in their home directory at ${HOME}/Maildir/ in the maildir format. It is standard practice for maildir delivery to go into the users' home directory rather than /var/. Both Postfix and Courier work with this standard behavior out of the box.
Unlike local users, there is no standard location for virtual
user's email. We chose to create a single Unix account, called
vmail, that holds all the virtual mailboxes.
[1]
Postfix and Courier support looking up the directory and Unix
account information out of LDAP. This document only describes
how to setup this system with one user, though you are free to
choose a different policy. Each virtual domain has a
subdirectory within the ~vmail/domains/
directory. For example, if there is a user
<john@example.com>, mail would be stored in
~vmail/domains/example.com/john/ in maildir
format.