Build your own open source messaging server

After reviewing commercial Linux messaging servers, we wanted to assess the practicality of building a similarly capable e-mail solution made entirely of open source tools. Going that route means giving up having a single vendor to turn to for support and a nicely packaged installation, but it could save a boatload in licensing fees.

For hardware, we chose a used but still healthy Pentium III 1.7GHz server with 1GB RAM, equipped with two 36GB SCSI disk drives — typical of a “leftover” common to thousands of datacenters. Although these specs may seem unimpressive, this setup provided adequate power to handle our 500-user load except under extreme circumstances.

After you have your hardware in place, select your favorite Linux distribution. We’re partial to Fedora Core 3, but just about any distribution should work. For the underlying MTA (mail transfer agent), we used Postfix. It’s robust and generally easier for a novice to configure than Sendmail, especially in its plain-English rule configuration. It also has helpful built-in features such as MIME filtering and is capable of checking addresses against public spam lists.

At the desktop, we reconfigured Outlook’s connection type to IMAP. We prefer this to POP3 because mail remains on the server. We also recommend configuring IMAP to run encrypted via SSL.

One drawback to IMAP is that it doesn’t natively support calendaring. Because we were using Outlook, we took advantage of its Internet Free/Busy feature on the clients. This is easily configured on each individual Outlook client to store schedule data on any shared directory instead of on an Exchange server, and it makes the Free/Busy information available to others. If your organization still has a Windows or Novell server around, use a directory there. Otherwise, a Samba share on the Linux server will work just as well.

Web-based e-mail is a nice feature to offer. Our choice for this was SquirrelMail, a PHP-based interface. Because some common PHP misconfigurations can pose a security risk, be sure to read the documentation. And, of course, run the site via SSL. A self-signed certificate may be sufficient for internal use, or see cacert.org for a free digital certificate.

The last requirement is a directory service. LDAP is a good way to offer a corporate address book because of its ease of supporting many different clients. OpenLDAP is one option. If you already have an LDAP directory such as Novell NetWare or Microsoft Active Directory, feel free to use that. Having to configure each workstation’s e-mail directory settings individually can be inconvenient, especially in a large organization. But if you’re savvy at the desktop level, this sort of thing can be scripted and automated.

Overall, we were up and running with our open source solution in a little more than three hours — but then, this wasn’t our first crack at it. Someone trying this for the first time should expect a longer configuration time. Even so, building the e-mail server is surprisingly straightforward.

Migration tools are a bit harder to come by. We haven’t found any free ones that work. That could make migrating Exchange mailboxes a manual process. For this piece of the project, it may be worth obtaining a commercial migration program if you have enough mailboxes. CompuSven’s E-mail Shuttle, which we used for our Stalker CommuniGate Pro migration, will work well for this purpose. A simple migration solution for a small office would be to back up each user’s e-mail into a .pst file and restore the information when the new IMAP profile is created.

In the end, it turned out that e-mail services can effectively run using only open source software. Even running on our slow leftover server, the open source packages handled all 500 nodes easily and with no immediately discernible difference from the client side.

The question isn’t whether it can be done; it’s how much you’re willing to put into it. The only features we didn’t find to be as solid as those of the commercial versions were migration and calendaring. Both of these have work-arounds, but the commercial packages definitely make the process easier. Also, although it’s not necessary to be a bearded Linux guru, Linux competence is essential, which introduces either a learning curve or an additional staffing cost.

Finally, open source’s biggest problem in many enterprises isn’t technical at all; it’s business-oriented: Many companies will be leery about building a critical resource such as e-mail on a platform with no support-contract safety net. Things will work fine as long as your Linux administrator is happy, but should he or she quit, the company will be left without an immediate recourse.

Setting up an open source e-mail system isn’t exceptionally challenging and can save you quite a bit of money compared with going commercial. If you’re not sure whether this solution is for you, put it on a spare machine and go for a test drive.