Edwin H. Kremer Department of Computer Science Utrecht University
Edwin H. Kremer Department of Computer Science Utrecht University
Edwin H. Kremer Department of Computer Science Utrecht University
http://www.cs.uu.nl/technical/services/email/architecture/email.html
1. Introduction
The use of electronic mail (email) at the Department of Computer Science at Utrecht University started early in 1985. Quite a few things have changed in the 12+ past years: in the late eighties it was rare to find a user with a mailbox of size over 200KB, now it is common to find mailboxes of size near to 25MB. Statistics on the Internet backbone show that the Email volume on the Internet is still rapidly increasing. The growth is causing us trouble... Chapter 2 describes our previous, traditional email environment, explains where the (daily) trouble occurs and where limits have been reached. Chapter 3 describes a modern, scalable, client/server based email environment; this is where we are migrating to. Chapter 4 summarizes the changes for the users.
1 of 4
3/6/2014 11:45 PM
http://www.cs.uu.nl/technical/services/email/architecture/email.html
There are quite a few areas where this configuration is growing beyond its limits: in performance, reliability and maintenance costs. Problems raised in these area's: Mailboxes have grown to huge sizes. Because all workstations are accessing the mailbox via NFS, reading mail and updating a mailbox causes a lot of network traffic. When the mailbox is very large (mailboxes with 500 messages and size of 15MB are quite common) this also takes a fair amount of time. As the load on the servers rises, processing time per mailbox increased rapidly. While the mailbox is being read, it is also locked to prevent concurrent updates when a new message arrives. In addition, NFS is notoriously known for its very unreliable locking behavior. On our busy network, the combination of huge mailboxes and NFS locking simply takes too long and is the cause of loss of email several times each day! NFS will hang a system. Because NFS is a very persistent protocol, the desktop workstation will suffer serious performance degradation or come to a grinding halt if the central mail server infix.cs.uu.nl is down. NFS is also not fully portable to heterogeneous environment and does little to nothing to address the needs of disconnected or nomadic users. Sendmail exists on every desktop system. As said before, sendmail maintenance is very time consuming and also a challenge, because it is very complex software. Sendmail tops the list of programs on the Internet that have had the most security problems in their lifetime, due to its complexity. An update of sendmail on all our systems takes about a full week of work, because it has to be compiled and installed for every architecture. Every desktop system has its own queue for outgoing email: this queue can fill up or come to a halt without being noticed easily. This will stop all user's email from being delivered. The local presence of sendmail is only required by ancient mail clients like elm, Zmail and mailx. There's no other reason why it should be there. Replacing these by modern mail clients, will eliminate this problem. Spam and UCE. Unsolicited Commercial Email (UCE) and `spam' is exploding. Abuse of our email facilities by spammers increases and it taking away a huge amount of resources. Preventing this is tricky and
2 of 4
3/6/2014 11:45 PM
http://www.cs.uu.nl/technical/services/email/architecture/email.html
is best done at a central server. Our goal is to eliminate the problems listed above and to provide a fast email environment that is dial-tone reliable and will cause a major decrease in Total Cost of Ownership (TCO).
Figure 2 above shows the modern email environment in more detail. If you compare Figure 1 and figure 2, you will notice the following differences:
3 of 4
3/6/2014 11:45 PM
http://www.cs.uu.nl/technical/services/email/architecture/email.html
No Sendmail on the Desktop. Sendmail has been eliminated from all desktop systems, thereby reducing the TCO (Total Cost of Ownership). No NFS Mailbox Sharing. All mailboxes, both the normal `incoming' mailbox (/var/mail/user) and the users' `saved' mailboxes ($HOME/Mail/...) reside on the server. All file I/O operations are performed by the server. Initially, only the message headers are transferred across the network. Reduced Number of Email Tools on the Desktop. This is causing most of the pain for the users, because some of them will have to learn to use a different mail program. The reason for this is that development on tools like elm has stopped a couple of years ago. That software simply can't work in the modern environment. On the UNIX platform, pine is the most preferred mail client program. Using migrating from elm will master pine in only a couple of hours. The advantage is that pine can be used for news reading/posting too! Spam and UCE. Postfix (or sendmail) on the server side will be equipped with special restricted-rules that will stop spammers from abusing our site as a mail-relay and will stop UCE from well-known sites. Introducing IMAP. On the server side the IMAP server provides access to mailboxes trough the Internet Message Access Protocol version 4, revision 1 (IMAPv4rev1). Whereas the POP protocol downloads full messages from a single mailbox per user to the client system, the IMAPv4 protocols are considerably more flexible in downloading portions of messages, synchronizing after disconnected operation, updating the mailbox and maintaining a hierarchy of host message folders for the user. POP will typically be used by people who carry their own notebook computer and want to answer email while on the bus/train. IMAPv4 will typically be used by people who prefer to have their email at a single well defined, reliable (backups!) location - they will access their mail via the network, no matter if they are at the office, at home or somewhere abroad.
4 of 4
3/6/2014 11:45 PM