Skip navigation

The Perfect Client

Which client is right for your IMS deployment?

In my November column, "Serving up Internet Mail Connections," I explained the benefits and mechanics of installing the Microsoft Exchange Server 5.5 Internet Mail Service (IMS). Now that you've set up the IMS, your end users need a way to use the IMS to exchange mail across the Internet. As I mentioned in my previous column, you can use POP3, IMAP4, Microsoft Outlook, or Outlook Web Access (OWA) to provide client access. You simply need to decide which method is best for your organization.

Making Everyone Happy
My friend Rick is a typical Exchange administrator. He runs a group of Exchange Server systems for an organization that serves about 2600 users who are spread throughout Texas and the surrounding states. Some of these users are office-bound, others are frequent travelers. His inhouse users were happy using Outlook 2000 on the LAN, but Rick wanted a better way to provide access for road warriors and remote users. How could Rick give these folks easy email access? The answer lies first in understanding how the clients communicate with the Exchange Server machine, then in choosing the method that makes the most sense for a given environment.

A Little Client History: POP and IMAP
In days of yore, all SMTP servers on the Internet ran UNIX, and practically every UNIX box was an SMTP server. For example, if I used a computer at the Georgia Institute of Technology (gatech .edu) to send an email message to a friend at Louisiana State University (lsu.edu), my UNIX box would use SMTP and the mechanisms that I described in the November column to get the email message to the lsu.edu mail server. The remote SMTP server would drop the message into a file, from which my friend would use a variety of fairly primitive command-line tools to read the message. However, this process didn't provide a good way for remote clients to access mail on a central server.

Enter POP, which is now in its third incarnation (i.e., POP3). POP lets a remote client pick up mail from a central server and read that mail locally. POP clients such as Eudora, Netscape Messenger, Outlook Express, and Pegasus became very popular as users began to appreciate the convenience of reading their mail from any location.

However, POP has flaws. The protocol stores mail on your client machine, much as Outlook stores personal store (.pst) files. This system is sufficient when you use only one client machine, but if you roam from machine to machine, you want to leave all your mail on the server. POP doesn't have a truly effective mechanism for users who aren't connected to the server. Further, the protocol doesn't let you store messages in folders on the server.

IMAP addresses POP's shortcomings. IMAP (the current revision is IMAP4) explicitly supports folders, which can contain mail messages and other folders. The protocol lets clients move messages between folders, peek at the contents of a message without downloading the entire message, and synchronize a local folder with a folder on the server. These capabilities make IMAP4 much more practical than POP3 for remote users. For example, when I'm on the road, I can use IMAP4 to access my Exchange Server mailbox from my laptops or my Handspring Visor, and my mailbox view is consistent on each device.

Exchange Server 5.5 supports POP3 and IMAP4, but you must enable these protocols if you want to use them. You can enable or disable the protocols at the site, server, or mailbox levels. This ability offers some interesting possibilities; for example, you can easily restrict IMAP access to users on a particular server, then add a firewall rule that permits IMAP traffic to only that server. (For more information about POP and IMAP, see John Green, "Electronic Mail Standards," November 1999.)

Rosy Outlook
Sometimes, Internet-protocol clients such as POP and IMAP don't provide enough functionality. Outlook, however, provides robust calendaring and complete support for forms and public-folder-based applications. Outlook can operate in two modes. In Corporate or Workgroup (CW) mode, Outlook uses remote procedure calls (RPCs) to communicate with Exchange Server. CW mode is Outlook's default method of talking to Exchange Server machines on a LAN. In Internet Mail Only (IMO) mode, Outlook can use POP or IMAP to communicate with any compatible mail server (including Exchange Server, of course). However, when you use IMO mode, you can't use Outlook's shared calendaring features.

In addition to Outlook, Microsoft provides a Web-based mail client: OWA. In Exchange Server 5.5, OWA is an odd beast: OWA is a set of Active Server Pages (ASP) and related components that use Messaging API (MAPI) to turn Exchange Server content into HTML. OWA's functionality is limited compared with Outlook's. For example, OWA doesn't support drag-and-drop functionality, and unless you install Service Pack 3 (SP3) or later on the Exchange Server machine, users can't access the Contacts folder. OWA 5.5 also has some performance limits, and in the past, users have questioned its reliability—leading many sites to install OWA on a separate dedicated server instead of on the organizations' Exchange Server mailbox servers. The good news is that OWA in Exchange 2000 doesn't use ASP; this change greatly improves OWA's speed and robustness. And as a bonus, Microsoft revamped the client interface. (For information about OWA 2000, see Tony Redmond, "Web-Enabling Exchange 2000," February 2000.)

Taking the Client Challenge
So, how do you decide which client to use? Several variables will influence your decision.

POP and IMAP have small security footprints; you can open one TCP/IP port on your firewall (port 143 for IMAP or port 110 for POP, or the Secure Sockets Layer—SSL—secured equivalents) to give clients access, with fairly low risk of compromise or exposure. The Internet protocols don't require any special configuration but need to provide some type of SMTP service to Internet-protocol clients—neither POP nor IMAP provides a way for clients to return messages to the server. Use significant caution when you enable SMTP relay: You don't want anyone to use your server to relay unsolicited commercial email (UCE). Typically, you want to enable SMTP relaying only for authenticated users (i.e., users who can log on to the server to check mail). For more information about Exchange Server client security, see Spyros Sakellariadis, "Using Exchange Clients Securely," October 1998.

The biggest problem with POP is that the protocol doesn't store mail on the server, so users can't keep all their mail in one place—a killer if they need to frequently switch client machines. And after users get a taste of Outlook, you'll have difficulty convincing them to return to POP, with its lack of server-side folders, search tools, and filters. But to let users get public folder and calendar access, you need to run Outlook in CW mode. In that mode, Outlook requires the passage of RPC traffic through your firewall—an extremely poor practice from a security standpoint (unless you use a VPN).

To return to my friend's dilemma, Rick's primary concern was security, so POP3 or IMAP4 would have been an acceptable choice. But some of Rick's mobile users work from several client systems, so POP's server-side storage restrictions negated the use of even the most capable POP3 clients. Rick's secondary concern was functionality—another blow to POP3. After considering the pros and cons of each option, Rick chose to equip his remote and roaming users with Outlook Express (in IMAP mode) and to deploy OWA on his Exchange Server machines to enable public folder and calendar access. The combination of IMAP and OWA works well for laptop users as well as users stranded on UNIX workstations or other platforms that don't support Windows or the 32-bit version of Outlook.

Choosing the right client is more art than science. Always keep an eye out for new technologies, such as the one I describe in the sidebar "A Berry Sweet Solution." The basic principle—delivering the functionality your users need in an efficient, easy-to-administer, and secure package—can apply differently to every organization. But now that you know your options, you can start your search for the perfect client.

Hide comments

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish