Implementing IMAP with UW imapd

Jauder Ho, Carumba.
jauderho@carumba.com

Abstract

This report talks about the IMAP implementation done for Transmeta. After extensive testing, the UW imapd was chosen for ease of integration into a hetrogenous environment. However additional modification was required for optimal performance.



This document is Copyright © 1999 Jauder Ho, all rights reserved. Trademarked material referenced in this document is copyright by its respective owner.



There have been lots of questions regarding IMAP and what a "good" implementation constitutes. The following describes what was implemented at Transmeta and it appears to be working well, we are happy to share what we know. Any suggestions are welcome. Please note that this discussion assumes that you are using the UW imapd server. If there is interest, separate pages for other IMAP servers can be created. As always, there is no guarantee that any of this will work. Patches have been updated and now apply against the IMAP 4.6 BETA release. Please send mail if there is a problem. You can get more information about IMAP at www.imap.org. Jack Snodgrass has put up a page about the Cyrus imapd program.

The recommended mailbox format is mbx. Unix spool files do not scale well and slow down tremendously when the folder contains more than 1000 messages. mbx uses preallocation and offers dramatic speedups. We have users with more than 8000 messages in their inboxes using mail at an acceptable interactive speed. However, mbx is *NOT* NFS safe. NFS brings up locking issues and is especially troublesome in mail related solutions. The UW imapd offers several other possible mail formats, read docs/drivers.txt for more information.

If the patches below are applied, this will enable backward compatibility with a current implementation (standard sendmail-based setup). For example, mail will continue to be delivered to the standard spool. This enables you to keep checking new mail with whatever mailer. But once you connect with an IMAP client, imapd will move your mail from the spool into the INBOX automagically.


Case Study:
The following describes the implementation done at Transmeta Corp. and can be used as a model for a mid-sized company with relatively heavy mail requirements. The hardware used is an Ultra2 with 512MB of RAM. Storage consists of a MultiPack with a 12GB RAID 0+1 partition for the mail spool. The mbx format was used as the typical user had 500+ messages in each mailbox. Message traffic is around 70k msg/day with a maximum observed message size of 1.5GB. Server uptime has been on the order of 250-300 days. The load average is around 0.2 so there is plenty of room to grow. Email clients vary from MS Outlook to Netscape Communicator to pine. Percieved mail reading performance is excellent with all operations taking at most a few seconds on even a relatively large mailbox.

Additionally, Tanstaffl Consulting presented a talk at Linux Expo 1999 titled "Replacing the Microsoft Exchange Server with Linux - A success story". This is excellent material to present to upper management.


Some creation/migration tools that have been written. They are pretty rudimentary, send any patches that extend them. You will have to modify the first couple of variables to fit whatever your site does.


all the patches
For your convenience, all the following patches together in one patch file.

use mbx format as default
This patch sets the default format which folders are created with to mbx instead of unix spool. Additionally, you can modify the same Makefile to remove any additional drivers that you think you will not need to save some space. We do this as we have lots of imapds running. You will want to modify CREATEPROTO and EMPTYPROTO if you want to do this.

change the definition of home directory
This changes what imapd thinks is the home directory of a user. Usually it is /home or whatever ~ expands to for a given user. However if user home directories are NFS mounted and you do not want to have anything to do with NFS (as you should), you can use this patch to set it to /var/imap/<username>/ with INBOX being the incoming mbx format inbox if you use the patch above. This allows you to keep all mailboxes in a single location. Netscape users also have the hidden benefit of not having to set the imap home directory. The option to set imap home directory has gone away with Netscape 4.5 although it still can be set by editing preferences.js. Please note that /var/imap is just something that we chose, you are free to put it anywhere you want. Using a two level letter hash so that you have something like /var/imap/u/s/user should enable you to scale pretty well.

NOTE: If you intend to use dmail in conjunction with some filtering program such as procmail, you need to recompile dmail after applying the patch above. The location of the home directory is hardcoded into c-client and hence dmail needs to know where to deliver mail to. dmail is part of the imap-utils package. imap-utils requires c-client.a from the imap tarball.

:0
* TOroot
| dmail +root

This example of a procmail recipe will deliver mail to /var/imap/root/root with this patch.

hide dot files
This causes imapd to avoid listing dot files when listing available folders. This is mainly for the benefit of Netscape users since Netscape writes a .mailboxlist to keep track of mailboxes in the imap directory. Think of it as the default doing the equivalent of a ls -a verses ls post patch.

use getrusage() for logging
This is very platform specific so it might require some tweaking. Output is passed to syslog(3). As of Solaris 2.6, maxrss and idrss reporting is broken. This might be fixed in Solaris 7. This feature can be toggled by adding -DVERBOSELOG to EXTRACFLAGS in the Makefile. imapTool is a perl script that analyzes the syslog file to generate statistics. This was patterned after some UMich reporting tools which are apparently not publicly available.

******************************************************************
*** imapd server usage from Nov 29 03:25:39 to Dec  2 12:11:24 ***
******************************************************************

NOTE: Only sessions longer than 5 secs are considered.

***************************
*** Summary Information ***
***************************

Total users:            117
Total hosts:            160
Total sessions:         2067
Total connect time:     192 days 1 hr 1 min 56 secs
Total CPU time:         2098.12 secs

Average connect time per session:       2 hrs 13 mins 47 secs
Average CPU time per session:           1.02 secs
Total swaps:                            0
Average swaps per session :             0

Average major page faults per second per session: 0.222
Worst case major page faults per second per session: 3.125 at Dec 1 21:17:05

***************************
*** Account Information ***
***************************

There are 158 accounts.
There were 123 active accounts in the last week.

Inactive accounts for more than 1 week:
[snip]

New accounts created in the last week:
[snip]

Most recent user: root@bofh.carumba.com (Dec  2 12:11:24)
            time: 2 mins 52 secs

Maximum number of concurrent users: 160 at Dec 1 14:06:34

******************************
*** Connection Information ***
******************************

Host                             Number of connections
----                             ---------------------
bofh.carumba.com                 250
[snip]






home | mail