Source and Documentation

YUM Repositories

AlphaMail

This is the home page for AlphaMail, a mod_perl webmail solution with a
C++ middleware component that is intended to make the system highly
scalable. It is written using C++, perl, and HTML::Mason, and accesses mail
stores through IMAPS. It is in active production use at the University of
Oregon, and currently supports many *NIX variants with any RFC-compliant
IMAP server including UW, Cyrus, and Dovecot.

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.

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.

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.)

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.

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.

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.

Tony Kay is moving to a research position, and will no longer have time
to be the primary developer and maintainer of AlphaMail. He plans to continue
to work with the project, but in much reduced capacity. It is likely that this
will stall future extensions indefinitely, unless someone wishes to volunteer
some development time.

AlphaMail uses GNU autoconf 2.59, and builds cleanly on many
platforms. The primary difficulty is meeting all of the dependencies for
the Perl libraries. You must have mod_perl 2.0, libapreq2, and various
perl modules. The cpan(1) command can build and install most of these
without a problem. See the admin guide for a Quick Start guide.

I have tried to limit my dependencies to things that most modern
distributions have access to in a package format. For many systems, run
the configure script (which will report on missing or old Perl
dependencies) and then just look for packages that resolve those.

Red Hat, Debian, Gentoo, etc.

We no longer have resources to maintain binary ports. Build files for
various platforms are available in the aux/build subdirectory of SVN.

Mac OSX - Darwin Port

I have written a set of darwin port files for the Darwin Ports system. I do
not have time to maintain, test, or update these, though I sometimes play
with it when I want a version on my Mac Book Pro. I would be happy for a
volunteer. The files are in the Devel SVN repository at
aux/build/darwin/portfiles. They are also available from the releases
directory, along with a guide to using them (OSX_HOWTO.txt).
See also the local repository instructions at opendarwin.org.