Navigation

• Home Page
• Project Status
• Performance Data
• Subversion Instructions
• Mailing Lists
• Supported Platforms
• Authors
• License Info
• Bug Reporting/Feature reqs.

Source and Documentation

• AlphaMail at Source Forge

YUM Repositories

• RedHat FC 4/5/6

---

AlphaMail

Features with Screen Shots

Detailed Message Indexes Message indexes include the subject and a snippet of the message body. Most character encodings are supported (see Perl::Encode for a list), and are transcoded to UTF-8 for display.
Index Filtering (search) Message indexes can be filtered by keyword (header/body search), quoted phrase, from, and to. The filter field is also UTF-8 compliant, and such a filter will apply to messages that are encoded in other character sets. For example, searching for a japanese word (as in the second screen shot) matches messages that are encoded in shift-jis as well as UTF.
Feature-rich Message Reading The message reading interface has many features, including the ability to show a message in an unformatted state (i.e. all space preserved, so you can view source code as it was typed), print view, full headers, and image previews (currently jpg, gif, tif, and png). Messages are also transcoded to UTF-8, so all modern browsers can display your international mail. AlphaMail also supports many popular attachment formats, so the attachment can be viewed before downloading. You can view full-size images, list files from zip and tar.gz archives, as well as preview word and excel files.
Message Composition Compose supports all common features, including address field completion, spell checking, draft messages, attachments, and message size limits.
Configurable Options There are many user-configurable options such as linkify, HTML image stripping, HTML sanitization, randomized signatures, and IMAP folder subscription (which changes the list of folders on the left edge).
Small Screen Support You can also change the interface (at login) to support your handheld device! This mode minimizes the on-screen controls for optimal use on PDAs and phones.

Paginated PDF versions are linked from the text. I hope to have a way to obtain statistics for other open source web mail systems soon so that I can show comparisons. However, in the interim I have some great performance graphs from an active production system at the University of Oregon, which serves about 20,000-40,000 users a day.

These statistics include all IMAP network latencies and server processing of the request. They also include hits where a folder had to be opened (before it was cached), as well as when a page selection took the user to a new (uncached) section of the folder. The short requests are almost certainly hits that went to the cache only (because the cache already had the data), and the longer ones are the hits that required IMAP processing.

The very long ones (over 10 seconds) correspond to back-end IMAP contention, usually locks resulting from multiple client access (we support direct IMAP access which can compete with locks in the web mail if people use both, which unfortunately they sometimes do).

These numbers do not include client transfer times or browser rendering.

• The first is a histogram which shows response times for message indexes on an hourly basis.
  Note that as you page through the hours around noon (our busiest time), the majority of requests are still being served in under 0.5 seconds.
• The second uses the same data to show a cumulative graph (i.e. what percentage of users saw a response time under x?). This gives exact numbers for the percentage of people getting specific response times. As you can see, at our busiest time (page down to the 14th at 1pm) 65% of the requests were served in under 0.5 seconds, and 92% of them were under 3 seconds.
• The same kinds of graphs for message reads: Histogram, Cumulative. As you can see, these are much faster than message indexes, with 95% of messages reads completing in under 0.5 seconds. Many of them faster than that (80% of them under 0.25s during the busiest time of day).

The production system was a dual 2GHz Opteron 246 x86_64 box with 4GB of memory. Here is the CPU usage graph for that system during the exact time period shown in the response time graphs. This graph uses running averages that span 5 minutes in order to smooth the noise (i.e. decoding an image for an icon view might cause a local 100% CPU spike). As you can see, the server is not ailing at all, and from a user perspective the response feels the same as from my idle development server. This indicates that it should be possible to serve about 40,000 users from this box before response time would be affected.

Another interesting graph is this scatter plot (older, but still valid), which shows that the folder size does not adversely affect response time: an intentional effect of the cache. Note: we are using mbox format, which should show horrible scaling for large numbers of messages.

1. It must not be abusive of the IMAP server. Webmail clients that don't use some form of middleware beat the imap server to death on every user mouse click. IMAP Proxies help, but they do not cache any of the actual data, this is particularly harsh when there are many users, since every mouse click can cause an entire re-read of the mailbox. My Performance tests on IMAP servers were my original motivation for this project.

   IMAP servers such as Dovecot and Cyrus can help by being more efficient, but porting from one mailbox format to another in a large environment can be an immense undertaking. (There are scalability issues with Cyrus itself, since many institutions want to use NFS filers, and Cyrus does not support them.)

2. Reading, sending, and organizing messages must be usable on all possible browsers, including those that are used by people with disabilities. It should downgrade gracefully when a feature is not supported. Currently, the only browser requirements are HTML 4 compliance and cookie support. All features that are enhanced with JavaScript are available via more traditional server interaction when JavaScript is not enabled. An AJAX-enabled mode is planned, but the wide browser support was more important for initial implementation.
3. A good feature set for the majority of browsers. We are modelling the advanced features after some of the best mail clients we can find.
4. International language support. Currently, AlphaMail supports composing messages via UTF-8, and should be able to read messages encoded in almost all languages and charater sets. The interface itself is not yet available in anything but English. See project status for the i18n interface status.

   $ cd /usr/local/src
   $ svn export https://svn.sourceforge.net/svnroot/alphamail/releases/alphamail-1.0.24 alphamail
   

   $ cd /usr/local/src
   $ svn co https://svn.sourceforge.net/svnroot/alphamail/src/alphamail alphamail
   

   $ cd /usr/local/src/alphamail
   $ svn update