If you use the UW IMAP server and performance is slow, it is due to UW-IMAP being in "slow locking mode." This can be corrected by changing the permissions on the directory containing the mail spools to 1777 (drwxrwxrwt) which allows lower level (faster) mailbox locking.

We have written a guide for improving the speed with UW. There is also a FAQ on this at UW. The below link jumps you to the appropriate section - you still need to scroll down to the right question. We suggest that you read both the FAQ and this guide. One might contain information that the other is missing. There's tons of good info available in both!

On my system (Mandrake 10.1, UW-IMAP, Postfix), it was always crash and i didn't know what caused it. When I changed the permission of /var/spool/mail to 1777, the problem is gone.

7.10 What does the message: Mailbox vulnerable - directory /var/spool/mail must have 1777 protection mean? How can I fix this?

In order to update a mailbox in the default UNIX format, it is necessary to create a lock file to prevent the mailer from delivering mail while an update is in progress. Some systems use a directory protection of 775, requiring that all mail handling programs be setgid mail; or of 755, requiring that all mail handling programs be setuid root.

The IMAP toolkit does not run with any special privileges, and I plan to keep it that way. It is antithetical to the concept of a toolkit if users can't write their own programs to use it. Also, I've had enough bad experiences with security bugs while running privileged; the IMAP and POP servers have to be root when not logged in, in order to be able to log themselves in. I don't want to go any deeper down that slippery slope.

Directory protection 1777 is secure enough on most well-managed systems. If you can't trust your users with a 1777 mail spool (petty harassment is about the limit of the abuse exposure), then you have much worse problems then that.

If you absolutely insist upon requiring privileges to create a lock file, external file locking can be done via a setgid mail program named /etc/mlock (this is defined by LOCKPGM in the c-client Makefile). If the toolkit is unable to create a <...mailbox...>.lock file in the directory by itself, it will try to call mlock to do it. I do not recommend doing this for performance reasons.

A sample mlock program is included as part of imap-2002. We have tried to make this sample program secure, but it has not been thoroughly audited. </i>

<<end fragment>>

I wouldn't mind if some one somewhere could decode the messages that come back out of the

<options><IMAP server information> SquirrelMail link. In particular I see occasional

"NO Mailbox vulnerable - directory /var/spool/mail must have 1777 protection" messages. Do they mean that

I have the 1777 problem, or that I don't? ( that "NO" is confusing) When I rerun the Imap server info process in SM this message isn't there the second time... so what is going on?

All the above suggestions are excellent - but when I tried them on our setup, SquirrelMail with UW IMAP was still too slow. It was taking 20-30 seconds to show each page, which is way too long to get any useful work done. I spent a long time going over all the hints above about how to speed up performance with UW IMAP, before I discovered that (for our setup) it was a fundamental limitation of the way UW IMAP works.

Most of the users on our system tend to keep very large mailboxes, with hundreds to thousands of messages. People use pine as their e-mail reader, and pine has no problem with this. It can handle such large mailboxes in a very speedy way. But SquirrelMail takes forever with those large mailboxes, *if* you are using UW IMAP. The reason for this is, every time SquirrelMail shows a listing of a mailbox, it calls three IMAP commands in succession. First it SELECTs the mailbox, then it EXAMINEs it, then it SELECTs it again.

Now here is the key point. On our system (maybe yours too), with a big mail box (hundreds or thousands of messages), each of those IMAP operations takes about 5 to 8 seconds. You do three of them, so there is no way, no matter what optimizations you do (PHP accelerator, caching imap proxy server, etc) that the pages will load in less than 15 to 20 seconds!

How can you see if this is the problem with your setup? It's easy. You just telnet to the imap client by hand and see how long the 'SELECT' command takes. If it's more than a second or two (tops), then no matter what you do, UW IMAP will probably be slow for you. Here's how to do that test.

Assume your username is smith, with password blegga, and your mailserver is mserver.mynet.com. First we connect to the imap server, which is on port 143.

Then we login (obviously, use your account and password, not "smith" and "blegga"!):

TYPE THIS: a01 login smith blegga

RESPONSE: a01 OK User logged in

(That 'a01' bit is part of the IMAP protocol, so type it too, just as I've shown.) Then we SELECT the mailbox. THIS is the step you want to watch and see how long it takes. Remember, SquirrelMail does three of these, so multiply the time you wait in this step by three, and no SquirrelMail mailbox listing page will be able to load faster than that:

TYPE THIS: a02 SELECT INBOX

RESPONSE: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen)

* OK [PERMANENTFLAGS (\Answered \Flagged \Draft \Deleted \Seen \*)]

* 1242 EXISTS

* 0 RECENT

* OK [UIDVALIDITY 1062186210]

* OK [UIDNEXT 1246]

a02 OK [READ-WRITE] Completed

Note that this is testing to see how long it takes your INBOX to load. If you want to test some other mailbox, say "mail/hugebox", type this now: a03 SELECT mail/hugebox

The test is complete now, so logout:

TYPE THIS: a04 logout

RESPONSE: * BYE LOGOUT received

a04 OK Completed

Now, how long did that take? If the SELECT was very quick, then your UW IMAP server is working fine for you, and any problems must be somewhere else. If you have very large mailboxes and the select took a long time, well, your only option that I am aware of is to switch to a different imap server. I switched to Cyrus imapd. In my tests, a mailbox with 1242 messages (as shown above) took about 8 seconds per SELECT with UW IMAPD, but was near instantaneous with Cyrus imapd.

The reason for this difference is that UW IMAP uses the original, 'flat' mailbox format where all the mail is kept in one large file. It has to (or, at least, does) scan through that file for each SELECT and EXAMINE, which is intrinsically slow. Cyrus splits the mailbox up into one file per message and keeps a database of the structure of the mailbox, so those operations are much, much faster. This is an important difference to understand. If anyone on your system uses an email reader that requires the 'flat' mailbox format, then they will have to switch readers if you go to Cyrus. On the other hand, if everyone uses IMAP for their mail access, then it should theoretically be transparent whether you use UW IMAPD or Cyrus imapd. (Is it actually transparent? Not sure - I've tested it with pine and SquirrelMail, and both work fine, but remember to set the servertype of SquirrelMail to 'cyrus' when configuring it with conf.pl. Also, be aware that useage of things like .forward and procmail scripts is different with Cyrus - see http://www.oreilly.com/catalog/mimap/chapter/ch09.html for some discussion of this.)

A potential downside of Cyrus imapd, at least for me, was that I found it very hard to install. [Note added, Oct 2008: This was true when I first wrote this in 2003, but over the years, installing a cyrus mail system has gotten much easier. Many modern Linuxes have precompiled cyrus packages available now, and there is a lot more information available on the web about how to get this working.] I would say that it's not something you want to try as a novice. But if you do get it installed, wow, what a difference in speed. Using UW IMAP, even after I installed all the speed hints given above, mailbox listings of large mailboxes took 20 seconds or more per page. Using Cyrus imapd, it's less than a second each. It went from being basically unusable to being as quick as any page you ever load in your web browser.

How to speed up UW IMAP

By Larry Young <lyoung@zedak.com>

The article above describes UW IMAPD performance as intrinsically slow due to the need to scan a mailbox file in traditional sequential unix mailbox format. However, UW IMAPD supports -many- formats, and in fact will dynamically detect the format of your mailboxes and honor them. On my server I use the 'mbx' format which is an indexed format, and the speed improvement is vast. The only problem is how to create mbx format mailboxes for all your users.

I did this by putting an empty mbx-format mailbox called INBOX in the /etc/skel area that is copied when creating a user (Redhat Linux). However any new folder a user creates will still by default be created in the old format. For the user to create a new folder 'sample' in mbx format, he must specify the folder name as '#driver.mbx/sample'. Then UW IMAPD will create the folder 'sample' but in mbx format. Another approach is to configure UW IMAPD to default the format to mbx, but this unfortunately requires a change in the definitions within a C file in the source code and a recompile and install of the whole package.

[Note: How about a create_mbx_folders squirrelmail administrator option in config.php to prepend all (mail containing) folder names with "#driver.mbx/"?]

How to speed up UW with SquirrelMail

By Horn Wijaya <hwijaya@nodens.biz>

I got clients complained about this issue with very very slow SquirrelMail dealing with just 7MB of mailbox (22 emails). Seems ages to load the pages of emails. So searched up and down and before I acce that it's UW problem/limitation.... I found out that SORTING is the culprit. Once a user is using SORT of any kind, the whole thing slows down for that particular user ... forever. Until the SORT option removed from the pref file (manually).

Even when we revert the sort via SquirrelMail, it won't work, because I think the IMAP/SM needs to run through the whole data and examine and sort them before showing it on the screen according to the sort option we chose (even after reset the sort via SquirrelMail).

Raw is better, now it takes less than a second a page.

Hope this is useful! Cheers.

How to speed up UW with SquirrelMail

By Matthew Cox

Just wanted to confirm that Horn Wijaya had the easiest solution. Just deleting the "sort=0" line in the pref file dramatically speeds up page load times. This file is located in /home/user/.sqlmaildata/(email-address).pref

Same problem here on a Gentoo box using Courier. Deleted "sort=0" and she blazes now.

Second, the user can change the option to not sort by cycling through the sorting options. For example, the first time you try to sort by date, Squirrelmail sets sort=0 and puts the most recent at the top. If you click the date header again, sort=1 and the oldest are at the top. If you click it a third time, sort=6 and no sorting is done. "sort=6" is the default, so by deleting this line in the users' pref file, you effectively set sort=6.