SquirrelMail - Webmail for Nuts!

When saving, enter the following:

 _____                    ___    ##   ## 
/  __ \/'\_/`\     /\    (  _`\  ###  ## 
| /  \/|     |    /  \   | | ) | #### ## 
| |    | (_) |   / /\ \  | | | ) ## #### 
| \__/\| | | |  / ____ \ | |_) | ##  ### 
 \____/(_) (_) /_/    \_\(____/' ##   ## 
                                 ##   ##

Visit Preferences to set your user name

See also important non-UW-specific speed information at SquirrelMailPerformance.

----

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!

UW FAQ: http://www.washington.edu/imap/IMAP-FAQs/faqs.xml#problems

Their is also a more in-depth explanation of this in the UW-IMAP source distribution. Try {{imap-[version]/docs/locking.txt}}

''Please note that you do not need to modify the permissions of the mail spool files, just the directory.''

----

'''!SquirrelMail & UW IMAP - Performance Hints'''
''By Ali Nedjimi <lrdfrx@club-internet.fr>, 2000-08-15''

First, you should download the latest IMAP server. (ftp://ftp.cac.washington.edu/imap/).

'''1. During an authentication error, a long delay can occur (UW Specific)'''

This delay is due to a wait time (call to a sleep(3) function) designed to prevent password/guessing attempts.

You can disable it in the source code :

you should go to :
 {{[where_you_installed_the_source]/src/osdep/unix}}

edit the file named : {{env_unix.c}}

and search for "{{sleep (3);}}"

I chose to comment this line, you could just adjust it to sleep(1);

'''2. Decreasing LOGINTIMEOUT (UW Specific)'''

A login timeout occurs when there`s no activity on the login step
The default is 3 mn, you can reduce it in the source code.

edit {{[where_you_installed_the_source]/src/imapd/imapd.c}}

look for :
    #define LOGINTIMEOUT 3 MINUTES

and change it to whatever you want. I generally use 1 minute for autologout.

'''3.Disable DNS Lookup (UW Specific)'''

Tell UW to never do gethostbyaddr() calls on sockets in the client and server.

edit {{[where_you_installed_the_source]/Makefile}}

and set EXTRACFLAGS like this :

It gives an interesting response time boost but you souldn`t set this if you are using an authentication mechanisms like Kerberos V.

You should`t set it if you`re doing virtual hosting (It`s said in UW docs but I`m not sure that it won`t work).

'''4. Change permissions of /var/spool/mail (UW Specific)'''

As said in UW FAQ and confirmed by some guys, changing the permissions of /var/spool/mail from 751 to 1777 can speed up !SquirrelMail UW access.

You may be able to find this entry in their FAQ here:
http://www.washington.edu/imap/IMAP-FAQs/#7.10

(It used to be [http://www.washington.edu/imap/IMAP-FAQs/FAQ-00013.html here], but the page changed and the link is not working.)

text of link http://www.washington.edu/imap/IMAP-FAQs/#7.10 ref'd above is:

<<fragment>>

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?

'''5. Avoiding inetd server`s limitation  (UW & other imap daemons)'''

(This section has been moved to ConnectionsPerMinute)

'''6. Optimizing via inetd.conf (UW & maybe other imap daemons)'''

(This section has been moved to DisablingTCPWrapper)

'''7. Use PHP built in httpd instead of PHP CGI (UW & other imap daemons)'''

(This section has been moved to SpeedingUpPHP)

----

'''How Fast Can you Go? <Diagnosing UW IMAP performance problems>'''

''By David Pierce <dpierce5@san.rr.com>''

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.
TYPE THIS: {{telnet mserver.mynet.com 143}}
RESPONSE: {{Trying 123.237.234.12...}}
{{Connected to mserver.mynet.com (123.237.234.12).}}
{{Escape character is '^]'.}}
{{* OK [CAPABILITY IMAP4REV1 LOGIN-REFERRALS STARTTLS AUTH=LOGIN] mserver.mynet.com IMAP4rev1 2001.315rh at Sat, 30 Aug 2003 11:08:06 -0700 (PDT)}}

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.

''bdgenz''

----
''By Dave''
Two points about "sort=0" causing slowness.

First, you may want to look at http://www.squirrelmail.org/docs/admin/admin-6.html#ss6.3 .  If your IMAP server is capable of doing such, having it do the sorting significantly helps.

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.

Summary of change:
Add document to category:

Editing SpeedWithUW