A perfect mail server setup is a holy grail for systems departments in any organisation, whatever maybe it’s size.

Whether to host the mail server locally, or outsource the hosting ? Will the data be safe ? Will the service be secure ? Will my provider be stable and is 1Mbps enough for my mails and internet access ? What solution do we adopt ? What will be the ROI/TCO/TLA ?

These and a zillion other questions arise in the minds of the systems, finance and other top management guys. In our company, we’ve been advising, deploying and maintaining a number of email servers for small organisations to large organisations with users ranging from only a couple to hundreds. Initially, we deployed custom home grown solutions using Postfix, Courier, Squirrelmail, OpenLDAP, MySQL, Spamassassin, ClamAV, Amavis along with a user management module, we wrote in PHP.

The installations were (are, in some cases) very robust, stable, scaling and had been extended extensively beyond the initial requirements (For eg, integrating with PureFTPd). Though we and our clients were very happy with these, we always felt the need for more features – to manage mail queues, better analysis and statistics amongst others.

In the meantime, there was a product which was making news as a featureful but open source email system – Zimbra. I took a look at the Zimbra, and was elated by the fact that Zimbra used the same open source components that we used to build our own system. Then, I was taken aback when I discovered most of the frontend was written in Java. Also, their complete IMAP/POP/Mailbox implementations are in Java – specific to Zimbra. Actually, I don’t have anything against Java. In a couple of projects, I used to even enjoy the breaks I got while java code got compiled . But nevertheless Zimbra wasn’t for me. Yet!!

After a couple of months, when a customer asked for some very particular features. We discovered that it would take us aeons to implement that same features and integrate, given our limited resources. We finally bit the bullet and worked on deploying Zimbra for the client. Basing it on Debian GNU/Linux Sarge, we had a wonderful learning experience with Zimbra. We wrote several tools and utilities using which we migrated the users seamlessly and efficiently. Zimbra took off.

But, later we came across several bloopers with Zimbra – the distribution list didn’t work, (btw, Zimbra’s console management client works well), the number of new mails were misleading. Since the code was in java, we couldn’t take the code, repair the same in a shorttime.

Recently, we upgraded Zimbra from 3.1.2 to a fairly large project Zimbra-4.5. It was such a wonderful experience – stage-by-stage application upgrade, it is very rarely used elsewhere.

… To be continued!!