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. |
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.
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.
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.
This example of a procmail recipe will deliver mail to /var/imap/root/root
with this patch.
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.
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.
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.
:0
* TOroot
| dmail +root
******************************************************************
*** 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]