Building Scalable Email Systems
Implementing Scalable Email Systems using Freely Available Components
IntroductionMany organizations are struggling with the problem of providing secure and scalable email systems to their users. This paper describes how we solved the problem of providing secure and scalable email to the users of Southern Illinois University School of Medicine in Springfield. This system is implemented using IMAP, SMTP, SSL and LDAP on the UNIX platform.
Our RequirementsAs we started to design a system to replace our current mix of Novell GroupWise and UNIX POP mail clients and servers numerous design criteria were developed.
Currently Available SystemsMany different email systems are available. Most commercial systems donít meet the design criteria of being Open Standards based. This eliminated Netscape Messenger, Microsoft Exchange and Lotus Notes. Of the freely available UNIX systems, the most popular, UW IMAP, was not known for it security. The Cyrus IMAP system from Carnegie Mellon was attractive because of its speed and the security provided by the sealed server design (eventually Cyrus was incorporated into our design)
General SolutionThe solution we finally implemented is an intelligent IMAP proxy. Rather than modify or develop an IMAP daemon, we decided to leave the daemon untouched and build a front-end to meet our design goals. The proxy works by implementing the non-authenticated states of the IMAP protocol. (LOGIN, LOGOUT, NOOP, CAPABILITY). The plain-text goal is achieved by implementing the SSL protocol in the IMAP proxy. Plain-text password exchanges are limited to our secured switched server network. The client connects to the proxy and attempts to login. The proxy accept the username and password and looks the username up in a username à host database. The proxy then connects to the host on which the userís mail exists passing the login information to the actual server and the proxy becomes just a "bit passer" for the IMAP connection. Users are unaware they are connecting to a proxy which allows us to distribute mail across several servers providing both fault tolerance and scalability. More than one proxy can be deployed using Round-Robin DNS or more sophisticated load balancing schemes. For example, an IMAP cluster could be front-ended with a load-balanced cluster of machines running the proxy. A single failure would not down the entire system. This system doesnít provide for backup if a back-end IMAP message store fails, but damage is contained to the lost mail store. The proxy does make several assumptions. First, the IMAP servers must have the same capabilities. The proxy must be able to return the IMAP serverís capability before the username is available. Reporting the wrong capabilities for an IMAP server can be very dangerous and could result in lost or corrupt email. Second, the proxy must have access either locally or via the network to a mapping of usernames to hosts. Our implementation builds a database (hash) on the local machine from our LDAP directory every day. The decision was made to build a local database to reduce the possibility that an overloaded network interface could cause database lookups to fail. Third, a delivery mechanism must be built that maps usernames to their final mail storage server. Our implementation uses information in a LDAP directory to distribute mail delivery data to several inbound mail handlers. This code requires the following pieces:
Our Specific Solution
In our environment, we were already building a fault-tolerance Kerberos and LDAP infrastructure. We have several geographically distributed Kerberos servers that provide password information for many of our services and several geographically distributed redundant LDAP servers, which we reference by a round-robin DNS host name. LDAP provides the distributed username to IMAP mail store host mappings used by our proxies and mail exchangers. Our individual IMAP mail servers use CMUís Cyrus mail server. Cyrus was chosen because itís fast, sealed and integrated nicely with our Kerberos environment. At present we have 2 IMAP servers running Cyrus. Our proxies are actually implemented on our IMAP servers. The proxy runs on the official IMAP and IMAP-SSL ports and the Cyrus daemon runs on a different port, to which only the proxies can connect. Users connect to a round-robin DNS host named. Imap.foo.bar which resolves to both IMAP servers. Each server runs the proxy which in turn connects the user to the correct IMAP mail store.