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 :-P. 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!!
3 comments:
Zimbra's front end isn't java, but javaScript(AJAX)
By frontend, I don't mean the browser-end, but the application framework as such, which in turn generates the javascript (Ajax) based rich UI.
We went a similar route at first, and then also went to Zimbra, had issues simply with maintaining the installation, because Zimbra is great, and one of the fabulous things about it is how fast they come out with improvements, but maintaining the email system is not my primary responsibility, so we ended up at a hosted Zimbra provider...
... and haven't looked back since. *relief* 01 uses the network professional edition, which enables our Macs and Outlook clients both to desktop sync, recently integrated a third-party spam/virus solution that enables us to have control over domain, as well as per mailbox prefs, while it has room for improvement, it's pretty much the last thing we were looking for. Best of all? I've trained my users to contact their tech support first. :)
Post a Comment