Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
For a small business, moving from Microsoft Exchange to an alternative mail server such as Palo Alto, Calif.-based Hewlett-Packard Co.’s OpenMail running on Linux can look like a good idea.
One of my small business clients had been running Exchange for two years. During that time, they have had to reinstall the program twice and reboot the system at least twice a week. By the time I was hired to fix the problem, the mail server had degraded to the point that you could not even add users to the Exchange system. Instead of continuing to pour resources into an obviously bad investment, my client asked if there were any alternatives.
One problem, however, was that the company insisted on continuing to use Microsoft Outlook. Although Outlook 2000 can use any POP or IMAP mail server, the client was particularly attached to Outlook’s shared folder and shared calendar capabilities. This requirement appeared to eliminate most of the possible replacements for Exchange.
Six months earlier, however, I had run across OpenMail, and had installed it in my consulting firm for testing. What I found was that I was able to use Outlook 97 for basic calendar sharing and the product’s advanced IMAP support, through Netscape Mail, was excellent. OpenMail also offers complete MAPI (Messaging Application Protocol Interface) based transport for Microsoft Windows. The MAPI interface allows OpenMail to provide services to Outlook that mirror the capabilities of Exchange, such as shared folders, calendars, and event notification.
HP is promoting OpenMail as a drop-in replacement for Exchange. Among other things, it has announced a Linux port, and a promotion where OpenMail licenses for 50 users or less are free.
That helped create the incentive for my client not only to try a new mail product but also to deploy Linux as the underlying operating system. The free version of OpenMail, however, doesn’t include support. So when we ran into implementation problems, and the costs for solving them started to mount, the client decided to toss OpenMail in favor of a completely open source solution, running on sendmail.
Installation: a no-brainer
Once we got the go-ahead from the client, we began installing OpenMail. To back up existing mail files, we had every user move all of his or her shared information to a personal folder. Since personal folders are placed on the local drive, we could then safely delete Exchange and proceed to install Red Hat Linux and OpenMail on the old Exchange server.
Installation of OpenMail is a no-brainer, as it uses the RPM (RedHat Package Manager) format. OpenMail also supports multiple languages, so it is a good idea to install a preferred language package. During the installation I only found one thing frustrating: the installation path of the binaries. On more traditional UNIX systems the installation path for secondary programs (programs that are not part of the operating system) is /opt . On Linux, however, it is usually /usr/local. OpenMail installs itself within /opt which in my case caused problems because of hard drive space, since I had partitioned my Linux system to have a small / partition without a separate /opt partition. I therefore had to move /opt to /usr/local/opt and then use the ln command to link back to the /opt location.
Configuring OpenMail was not difficult. HP provides basic documentation with the download, which walks you step-by-step through getting OpenMail up and running. Installing and configuring OpenMail took only about 30 minutes. However, this is where the no-brainer portion of OpenMail stops and the “remember that this is a Unix product begins.”
Administration of OpenMail is done either via the command line or a Windows-based GUI. This was disappointing. I would have liked to see a Web-based interface or a native GUI administration tool for Linux. It seems like companies think that just because we are Unix/Linux people that we prefer the command line. Well, ok, maybe we do prefer the command line, but a GUI is nice for administrative tasks. As an example:
To add a user to the OpenMail system from the command line you have to follow these steps: omaddu -n Sandy Smith / Acme, Boston -p xxyzzy -F This adds the user Sandy Smith at mailhub Acme, Boston with a password of xxyzzy.
Then you have to set the outgoing SMTP Return address: ommodent -e G=Sandy/S=Smith -n INTERNET-ADDR=sandy@boston.acme.com Which sets the headers on all Internet bound mail to sandy@boston.acme.com.
Then you must tell sendmail where the user sandy@boston.acme.com actually resides. You can do this by editing the /etc/aliases file and adding the line: sandy: sandy.smith/acme_boston
Then you must execute the command: newaliases
A GUI interface for routine tasks like this could certainly make life easier for administrators. And for OpenMail to succeed in the small business arena, it’s practically a necessity.
Consultants who deal with small companies need to be able to provide solutions that are reasonably self-manageable. Windows and Exchange meet this requirement. While they suffer from many of their own problems (including the inability to stay up without crashing for any extended amount of time), they integrate seamlessly, and they are simple enough for a reasonably savvy small business owner to manage without feeling intimidated.
OpenMail also lacks other features that makes tasks such as adding users more difficult. For example, OpenMail does not use SMTP-based addresses. Instead, it relies on its own proprietary naming style, which is reminiscent of archaic X.400 naming conventions. To send mail outside the system, therefore, you have to map the OpenMail-style names–such as Joshua Drake / Command Prompt, Oregon–to SMTP-style names like joshua@commandprompt.com.
You must also remap the OpenMail username to the Linux username through the aliases file (/etc/mail/aliases) for incoming mail. This is a very complicated way of doing things and should probably be rethought. Within a standard environment on Linux adding a user and allowing that user to send and receive Internet mail is as simple as adduser
Designed for the enterprise
OpenMail, with its roots in HP-UX and Solaris, was designed for large organizations. While troublesome for small business, its bizarre naming convention may suit large corporations that must distiguish between multiple departments, buildings, cities, and countries. As it is designed for the enterprise it offers some very nice features as well.
On machines using mailers such as sendmail, for example, the mail files are stored in plain text in a specific directory (on Linux: /var/spool/mail). This is not usually a security concern because of file permissions. It can, however, be a performance problem if you run a large system. OpenMail uses a message store, similar to a database, to store all of its content. This allows for a greater amount of scaleability at a reduced performance hit.
OpenMail also comes with, and runs by default, an LDAP (Lightweight Directory Access Protocol) server. The LDAP implementation used in OpenMail is top-notch. It is easy to interface with (via the command line or Windows based administrator program) and a breeze to set up. If you have ever tried to set up LDAP on Linux you will know that someone who comes up with a decent, easy-to-configure LDAP service for Linux is going to make a killing.
A statically-linked motif client for Linux and a Web-based client for Linux are also included with OpenMail. Both are useable but not nearly as pretty as other clients for Linux, such as Kmail or Balsa.
Too late for OpenMail
In order to use Microsoft Outlook’s calendaring and shared folders with OpenMail you must install the MAPI service that comes with OpenMail. When we installed the service we found that it would lock up intermittently and we would have to use the task manager to kill Outlook and start over. We also found that when moving large amounts of data to the message store, the MAPI service provider would lock up. This was frustrating for my client since these problems had never occurred with Exchange. It was frustrating for me, because I suggested the solution. Sending messages with attachments was also difficult. Any type of MIME encoding would cause the message to get munged beyond readability on routing to the recipient.
Fixes do exist for these problems. And as we later determined, except for the MIME issue, all the problems we had with OpenMail were due to Outlook and the MAPI service provider. But we didn’t know that at the time, which meant that it was too late for OpenMail for this company. The free version of OpenMail does not include technical support from HP, and after two days of fiddling with it, the client decided to remove OpenMail and run POP/IMAP and sendmail. Implementing and configuring a solution based on sendmail — including Outlook — took a mere four and a half hours. Half a day to configure 27 copies of Outlook 2000s and Linux to operate via POP/IMAP and SMTP looked pretty reasonable compared to the two and a half days we spent struggling with OpenMail.
If you are looking for the enterprise capabilities of HP OpenMail or Microsoft Exchange, remember that sendmail will not offer them to you. Sendmail only handles SMTP. In order to achieve a level of functionality that is similar to the HP and Microsoft offerings; you will need to install an IMAP/POP server, and an LDAP server. Sendmail worked for my client because they were running Linux which comes with sendmail and the IMAP/POP server.
Small businesses are very price-sensitive. That’s why Linux looks very attractive when compared to a $799 five-user version of Windows 2000 Server. OpenMail, which is free for 50 users or less, holds a similar attraction. But in order for OpenMail to succeed with small businesses, it will need to have an intuitive interface for non-UNIX people to use. And Hewlett-Packard will need to improve the product’s integration with packages like Outlook, so companies don’t spend days wrestling with it. Because for at least one company, that was a deal-killer.
Joshua Drake
