E-mail: Exchange Server 2003 or Open Systems?

In this article I'll talk about the hardware and software components you'll need to build an e-mail system based on either Microsoft Exchange Server 2003 or an Open Systems e-mail server such as CommuniGate Pro or MailOne. In all cases I'll focus on the I386 hardware environment and on software that supports both standard Internet clients and the Outlook MAPI client.

There are several e-mail server software options you should consider. On the proprietary side, they include Microsoft's Exchange Server and IBM's Lotus Notes. Open Systems solutions include basic Unix Sendmail, Stalker's CommuniGate Pro, and OpenOne's MailOne. On the client side, there are a number of good Internet e-mail clients such as POP3 or IMAP4; but in many cases, you must support the Outlook MAPI client that comes with Microsoft Office.

E-mail System Hardware

Whichever software your customer decides to use, they'll need solid hardware to support their e-mail server. An e-mail system must be both reliable and available, and for this reason, I'm not a fan of build-it-yourself server solutions. An e-mail server, at minimum, should include well-tested components, a hot-swappable SCSI RAID 5 array, and registered error-correcting memory. Redundant power supplies and cooling fans are also advisable. Also, don't forget to include a decent backup device, at least a 4-mm. DAT 4 or a 40- or 80-GB DLT tape drive. Finally, you need a vendor who will stand behind its hardware and help you troubleshoot and fix problems fast.

id
unit-1659132512259
type
Sponsored post

For my clients, the minimum is a Dell PowerEdge 1600SC server with 1 GB of RAM, one or two 2.4-GHz Xeon processors, at least 36 GB of RAID 5 storage, and a DAT 4 tape drive. Other vendors offer similar systems. Check out these systems on the Internet; you'll be surprised how much server a dollar gets you.

If a customer balks at even these modest costs, tell them how they'll save much more than the cost of the server in both reduced downtime and faster recovery from minor or major disasters. Use my mantra: "Cheap costs big time!"

If you can't convince that client with these arguments, I strongly advise that you not accept the job. When the el-cheapo server fails, guess who will be blamed for the customer's penny pinching? That would be you.

E-mail System Software

Now let's get back to building our system. How do you select an e-mail server product? Here are some key issues to cover:

Let's look at each of these considerations in some detail.

Surviving the Operating Systems Wars

Compared with selecting server hardware, selecting the software is difficult. First you need to wade through the Microsoft vs. Open Systems debate. There is a strongly rational component to this debate. However, it can also quickly turn into a religious war similar to the heated, passionate and ultimately irrational discussions between supporters of Apple- and Windows-based systems. Though my major focus these days is on Microsoft Exchange, from years of experience with both Unix Sendmail and with so-called Open Systems e-mail systems, I have developed a healthy respect for non-Microsoft e-mail alternatives.

Did I just call Linux a so-called Open System? Yes, and here's why. On the one hand, Linux remains open in the sense that there is a community of Linux users who collectively enhance a common Linux kernel that is available either free or for a nominal cost. But on the other, some Linux vendors are creating proprietary versions of the operating system.

This means future versions of Linux could have features, such as proprietary e-mail hooks or even full-fledged e-mail systems, that won't run on the free version of Linux. In other words, Linux is beginning to sound proprietary. Not convinced? Then consider Red Hat's heavy focus on building a proprietary Linux offering. Also, look at the relatively high prices some Linux vendors now charge for their own server products.

Don't get me wrong: Truly open Linux products are very good and can serve as the basis for a fine e-mail system. Nor am I faulting the Red Hats of this world for trying to build a better mousetrap, and to finance those mousetraps. Finally, I understand that while volunteers are great, sometimes mission-critical work gets done only when people are compensated for that work.

So even if your operating system is open, you must understand that the truly good e-mail systems for open operating systems are not really open. Instead, these systems are essentially proprietary and commercially supported.

Hackers and Viruses

One strong argument for Linux and Unix mail systems is that both have been less prone to external attacks than Microsoft's Windows and Outlook MAPI clients. The vulnerability of Windows and Outlook is due in part to their architectures, which make it easy for even a novice hacker or virus builder to wreak havoc on them. To be fair, some of the argument is also the result of negative or ambivalent feelings toward Microsoft as a company, as well as the trophy-grabbing mentality that dominates hacker culture.

Regardless of whether you ultimately go with Windows or Linux, firewalls are the best way to protect the server environment.

The best way to protect Outlook MAPI clients that access Exchange Server is with a server-based anti-virus product. Two examples are: Trend Micro's ScanMail and GFI's MailSecurity.

In an Open Systems environment where Outlook MAPI clients are supported, the best option is an Internet gateway product. Two examples are Trend Micro's Internet Gateway and GFI's MailSecurity. Also, consider workstation-based anti-virus programs that can detect and deal with Outlook-based viruses, such as Norton Anti-Virus, Trend Micro's PC-cillin, or Trend's server-managed workstation protection package OfficeScan.

For POP3 or IMAP clients that access an Open Systems e-mail server, consider two options: Either server-based software such as Sendmail Inc.'s Anti-Virus filter or workstation based anti-virus programs such as Alwil Software's avast! 4 desktop products.

Note that I did not include Microsoft's Exchange Server in my list of vulnerable Microsoft products. In my experience, Exchange Server is no more prone to attack than any SMTP host (port 25) or HTTP (port 80) server, which, with Exchange 2003, need be the only externally exposed components of Exchange. More on this later.

Servers Are Nothing Without Clients

A good e-mail server should provide POP3, IMAP4, and HTTP client access. A really good e-mail server will also support the popular Microsoft Outlook MAPI clients. POP3 clients download a copy of e-mail messages from the server to the user's local POP3 inbox. IMAP4 clients can access messages in all of a user's folders on a server (inbox, deleted items, sent items, etc.) and can either download copies of messages or access them directly on the server. HTTP clients provide Web-browser access to server-based inbox and other folders with no local copies of messages. Outlook clients are most like IMAP4 clients with the added bells and whistles of server-based calendars, phone contacts, task lists, etc., and tight integration into the Microsoft Office environment.

POP3 client support is a universal feature of almost all e-mail systems, from basic Unix Sendmail to Microsoft's Exchange. IMAP4 server-side support is available in most third-party Open Systems e-mail systems and in Exchange. HTTP message access is available in some Open Systems third party e-mail systems and in Microsoft Exchange. In my experience, the Microsoft HTTP client has the best and most user-friendly interface.

Microsoft's Outlook MAPI client is widely used. The latest incarnation of Outlook is the 2003 flavor. It is a wondrous product full of fantastic capabilities. All of those capabilities are supported by Microsoft Exchange or other Microsoft server products. Most of these capabilities are also supported by add-ons to e-mail systems such as CommuniGate and OpenMail. Interestingly, where support is not provided it is usually because the Outlook feature has not been well documented by Microsoft.

Historically, most e-mail access by Outlook MAPI clients has been over internal networks. Access over the Internet worked, but it required that port 135 be open on a firewall protecting a network with Exchange servers. This was so that Outlook and Exchange Server could communicate with each other using Microsoft's Remote Procedure Call (RPC) protocol.

If you've been living in a cave for the last year, this may come as a surprise, but port 135, the source of the recent So Big and other worm attacks on Microsoft Windows servers, is now such a no-no that most ISPs have closed it to incoming traffic. RPC over TCP/IP and port 135 is now pretty much a thing of the past.

Fortunately, Exchange 2003 includes the ability to connect an Outlook MAPI client to an Exchange server using RPC over port 80, the standard Web-browser port. You need Windows 2003 and Exchange 2003 servers as well as Windows XP-based Outlook 2003 clients, but safe Outlook-MAPI-to-Exchange-Server Internet links are now possible. Some cynics may see this as a neat way for Microsoft to sell all its new software in one fell swoop. But RPC-over-HTTP required significant enhancements to Windows 2003 and XP that Microsoft says would be very difficult with earlier Windows server and client operating systems.

By now you can see why Unix's truly Open Systems Sendmail is a weak choice for most serious e-mail implementations. POP3 tends to be a one-workstation product. What you do in your local POP3 inbox -- for example, deleting messages or moving messages to other folders -- is not reflected on your mail server. If you access your mail server from multiple workstations, unless you leave a copy of your messages on the server, you will only see and download messages that have arrived since the last download on your other workstation.

Bottom line: With POP3, your inboxes on multiple workstations are totally out of sync with both each other and POP3 on the server side.

Note: There are enhancements to Sendmail that add some missing features. In my experience, the best and most reliable of these come from Sendmail Inc.

Managing E-mail Servers

Compared with managing operating systems, e-mail system management is fairly easy. Still, you don't want a foggy user interface standing between you and such tasks as managing SMTP services or e-mail data stores or inter-mail server communications.

In my experience Microsoft's Exchange interface is the easiest one around. To be sure you can live with it, check out the interface on the Microsoft Exchange Web site, and then compare any other e-mail server interface to it.

Backing Up Is Critical

Given the critical nature of e-mail systems, effective backup is essential. You must be able to back-up the files that contain user messages and any publicly available folders on your customer's e-mail server. Microsoft Exchange Server 2003 includes support for consistent state backups of both the Windows 2003 server where Exchange is installed and the Exchange message and public folder databases. This functionality is available in Windows 2003's built-in backup program and is now or soon will be available in third-party backup programs such as Veritas Backup Exec and UltraBack.

Backup of third party e-mail solutions for Linux is supported by Linux's own backup functionality and by third-party backup solutions such as Networker from Legato.

Remember, not all your backups have to be to tape. Disk-based backups are not only becoming popular, but they are also eons faster than most backups to tape. Just be sure to back-up to a disk other than the one where your e-mail files reside.

What's It Cost?

Open Systems e-mail solutions using third-party software tend to cost less than a Microsoft Exchange solution. But they are not free, not by a long shot. For example, Stalker Software's CommuniGate Pro costs about $50 per user for a 50-user setup vs. about $70 per user for the same size Microsoft Exchange Server system, including client licenses. For more on CommuniGate Pro pricing, see my recent VARBusiness article on the product.

Conclusions

When it comes to e-mail systems, the choices are almost endless. This Recipe provides some of the key issues you'll need to consider when building mission-critical systems for your customers.

As a next step, browse the Internet, stopping at the various vendors discussed here, and gain as much understanding of their products as you can. Nearly all the vendors listed in this article provide evaluation versions of their products. You can download these and test them for a limited period of time. Keep your mind open, and have fun.

BARRY GERBER is an IT consultant, author, and professional photographer. He is the author of a recent book, Mastering Microsoft Exchange Server 2003 (Sybex, 2003).