The Prayer Webmail System

Prayer is yet another Webmail interface for IMAP servers on Unix systems.

It exists because we weren't terribly happy about the characteristics of existing Webmail interfaces: in particular scalability problems with common open source Webmail packages and the lack of flexibility that commercial packages would give us. This doesn't mean that Prayer is trying to compete with existing Webmail packages. It just means that Prayer is better suited to our particular environment.

We've been running Prayer as our Webmail service since late 2001: initially as a pilot service and then as a full supported service since July 2002. We've had surprisingly few problems in that time: mostly obscure browser effects that we have had to work around.

The code has been released under the GNU public license and is available from our FTP server at: ftp://ftp.csx.cam.ac.uk/pub/software/email/prayer.

Why "Prayer"?

Malcolm Beattie, formerly of Oxford University Computing Services released a Webmail package named WING early in 1999. It was unusual at the time in that it used persistent IMAP connections and it was written using Apache/mod_perl rather than mod_php. We came to the conclusion that the WING code that was available to us in 1999 and 2000 was not sufficiently mature to use for our own Webmail system. Consequently (and with some reluctance) we decided to start writing our own package. Prayer was the in house development name for this package, a simple play on words to acknowledge the strong influence that WING had over Prayer development, especially in the early days. But at the end of the day, everything needs a name.

Performance/Scalability

Persistent Login Sessions: Written entirely in C as HTTP to IMAP Gateway. No scripting languages. Single Webmail gateway can run on a number of small independent systems: Simple horizontal scalability if needed.

Small page sizes (typically less than 1 KByte compressed) give fast browser refresh rates even on dialup links. In a LAN environment, Prayer will serve pages as fast as the browser can render them, even under high concurrent load.

Simplicity

Few external dependencies Doesn't use Javascript or Frames. Doesn't need cookies:

User Interface

Message display Mailbox list Search Hierarchical folder listing Compose Personal Addressbook Account management using auxiliary server
David Carter <dpc22@cam.ac.uk>