Admin Features

  • Easy to install (only requires default build of PHP4)
  • Light weight and fast
  • Extensive multilingual capabilities
  • Modular – Easily modifiable to accomodate different backends
  • Activity Logging
  • Spam Prevention
  • Multiple host/domain support
  • Auto-appended Tag-Lines
  • Optional MySQL backend for improved scalability and performance
  • External SMTP server support
  • IMAP caching
  • Theme support [development]

Client Capabilities

  • POP3 & IMAP Support
  • Send, receive, file, delete messages
  • Create, rename, delete folders (requires IMAP)
  • Send/receive attachments
  • View images/html inline
  • Full featured Contacts list
  • Search messages (requires IMAP)
  • User defined colors
  • GPG/PGP support (requires GPG) [development]
  • Multiple sender identities
  • Spell checker (requires aspell)
  • Calendar
  • Bookmarks manager
  • Customizable – Over 2 dozen user preferences
  • Support for over 20 languages

Blurb on features

Easy to install

I’m a Mac user. I expect things to just work. When I first set out to write a webmail program, one of my requirements was that it should be easy to install. You shouldn’t have to recompile PHP or install a database, C-Client, or whatever, just to get a webmail program running.

With IlohaMail, you can get a webmail interface running in under 15 minutes, provided that you have a default build of PHP4 running. You don’t need the IMAP functions, no C-Client, and a database is strictly optional.

Obviously, the default file based user & session management scheme isn’t ideal for large scale deployment, and may have inherent security issues in some situations. The default version of IlohaMail has full support for a MySQL backend, although, you could also mix and match as you see fit. For an example, you could manage sessions and contacts using a MySQL database, and save user prefs using the default file based backend. Of course, you can dynamically switch backends by editing one config file.

Besides, anyone aiming for a large-scale deployment could probably afford a PHP programmer or two to modify IlohaMail to suit their needs.

Light-weight and fast

The custom IMAP library wasn’t there at first. But when I found how doggone slow the IMAP functions built into PHP were on older machines (i.e. Pentium 200MHz or less), I decided to write my own.

The custom written Iloha IMAP Library seems to be generally faster than the C-Client based library built into PHP. One example is how large attachments are handled.

With IlohaMail, base 64 encoded attachments are decoded and passed to the client line by line, typically 76 bytes at a time, regardless of the total size of the attachment. With the C-client based implementation, the server would have to load the entire attachment, decode it, then pass it to the client. This sucks up considerably more resources,
and negatively impacts response time.


IlohaMail’s modular design also makes it extremely scalable. Even though all required services (web, mail, db, etc) can be on one server, they can be on separate servers as well. One massively scalable setup might include two load balanced web servers running IlohaMail (with Apache/PHP), one database server running MySQL, two incoming mail servers with IMAP, and one outgoing (SMTP) server. Such a setup should be able to handle tens of thousands of users with ease.


Whether you like it or not, people have different preferences and needs. Programmers shouldn’t force people to do things a certain way, but give them options.

IlohaMail has (at the moment) close to 20 options that can be set by the user, and that doesn’t include the 9 colors that users can specify to get a little extra originality. As far as I know, IlohaMail is the only webmail that allows users to drastically change the look and feel.

For those that argue “Customizable looks cause head-aches in terms of support”. True, I have experience as a support tech.

But it’s easier to disable what’s there than to add a feature later.


I speak 3 languages, two of them, Japanese and English, at a native level. In fact, I started writing IlohaMail because I couldn’t find a decent webmail program that fully supported Japanese. As far as I know, IlohaMail is the only webmail program to be written from the ground up by someone who speaks a Western and Eastern language natively.

Why is this significant? Because someone who only speaks one language (or only latin derived languages) has little idea what multi-lingual support really entails, until he OpenSources it and hears that the Korean translator’s having problems making word orders work without rewriting some of the code, or that that the program can’t deal with a language having multiple charset encodings (as is the case with Japanese).


Another one of my personal requirements was that the interface should be in English, but it should still be able to support Japanese. As a result, IlohaMail can have an English interface, and still display/send messages in another language, if you prefer.