Until recently, users accessing their Microsoft Exchange Server mailbox from a remote location used Dial-Up Networking (DUN) or Remote Access Service (RAS) to dial their office and connect to the Exchange Server. This process usually involved a long-distance phone call and contention for the dial-in lines at the office. The release of Exchange Server 5.0 changes that scenario. Exchange 5.0 lets you access mailboxes on the server using Post Office Protocol 3 (POP3). This development means that email clients, such as Eudora, Pegasus, or the Microsoft Exchange client, that have the Internet Mail Service (IMS--formerly Internet Mail Connector, IMC) installed can access regular mailboxes on an Exchange email network over the Internet.
This article discusses installing and configuring support for POP3 on the Exchange Server. To support access from clients on the Internet, you must also install and configure the Exchange IMS to provide the requisite connectivity. Exchange Server 5.0 includes both POP3 and the IMS software.
POP3 support is only a small part of Microsoft Exchange Server's functionality. This article presupposes that you know how to set up and use Exchange Server and the IMS. (For tips about installing Exchange, see David Geiger, "Seven Tasks to Get Started with Microsoft Exchange," September 1996.) In addition, this article assumes that you are familiar with the basic concepts of TCP/IP and of Simple Mail Transfer Protocol (SMTP)/POP3 messaging. For information about how to set up and use the IMC/IMS and a basic tutorial about SMTP and POP3, refer to my book The Microsoft Exchange Server Internet Mail Connector (Duke Press, 1997).
An example best explains the POP3 support. Figure 1 shows a typical Exchange Server email system connected to the Internet. In this example, an Exchange organization, SAKES, has one site, Athens. The server Kifissia has several Exchange mailboxes and is running the IMS. The IMS is configured to deliver mail using Domain Name System (DNS) for address resolution, and the LAN is connected to the Internet via a permanent connection (for example, a T1 line to an Internet Service Provider--ISP). Figure 1 also shows an SMTP/POP3 server on the Internet at pop3.dcnw.com. SAKES is running Internet Shopper's NTMail on this server and has four POP3 clients installed.
This configuration, which has been available since Exchange Server 4.0, supports Exchange users trading mail with users on the Internet. The Exchange users in the SAKES organization are running the Exchange client configured with the Exchange Server delivery service; the IMS on Kifissia converts all mail between the Internet and Exchange users. For example, when Exchange user George sends mail to Internet user Judy, his mail is in an Exchange proprietary format until it reaches the IMS on Kifissia. The IMS translates George's mail into native SMTP format before forwarding it to Judy on the Internet. The process occurs in reverse when Judy replies to George. (Chapter 2, "SMTP Mail Basics," of my book describes this interchange in detail.)
All users in the SAKES organization use the Exchange client configured with the Exchange Server service to send and retrieve their mail. This process requires that users have an authenticated remote procedure call (RPC) connection to Kifissia. This requirement is restrictive for Exchange users who need to access their mail from a remote location. The RPC connection is also a problem if you want to support third-party email clients, such as Eudora or Pegasus mail.
Figure 2 shows a common scenario. The Exchange user Chris connected to the Internet from a remote location, perhaps by dialing in to a local ISP from a hotel room or connecting through a LAN at a customer's location. Achieving an RPC-based connection to the Exchange Server under these conditions is relatively difficult (but not impossible), and the standard Exchange client configuration mentioned above is impractical. However, using the POP3 support available in Exchange Server 5.0, Chris can access his mailbox to send and receive mail without an RPC connection.
Installing POP3 Support
You install POP3 when you install Exchange Server 5.0. During the installation, you pick the protocols you want to support. The installed site shows these protocols--in Screen 1, all the new Internet protocols--in a new container at the site level. If you double-click POP3 in the right window, you can configure the default properties for the POP3 access to the Exchange mailboxes.
The General tab of the POP3 Properties dialog box, shown in Screen 2, lets you specify whether the Exchange Server will provide POP3 access to mailboxes. If you enable the protocol, you can specify other parameters from the remaining tabs. For example, the Authentication tab lets you specify how clients can authenticate themselves to the server to gain access to the mailbox. Exchange 5.0 supports two methods to authenticate clients. The first, Basic (Clear Text), refers to the standard method supported by the Request for Comments (RFC) 1225. Users who want to use a POP3 mail client such as Eudora to download their mail connect to the Exchange Server over TCP/IP. After the server acknowledges the connection, the POP3 client sends the command
followed by a carriage return and linefeed. The server responds with either +OK or -ERR, depending on whether the server finds that username. The client then responds with
again followed by a carriage return and linefeed. If the password is correct, the client can send further commands to retrieve and delete mail. Notice that the authentication is in clear text; that is, all the text is in pure 7-bit ASCII.
Clear text is the Internet standard for POP3, and all the standard clients--Eudora, Pegasus, the Exchange client with the IMS installed, and the proprietary mail clients that you buy at your local computer superstore--implement clear text. It is, however, clearly insecure. Anyone watching the bits on the network with a sniffer (for example, the Microsoft Systems Management Server--SMS--Network Monitor) can read your entire message as it goes by.
The second authentication method is the Windows NT Challenge/Response sequence. Challenge/Response uses an encrypted method for logging on to an Exchange Server over the Internet and requires an email client that supports the authentication mechanism. The number of third-party clients that support Challenge/Response is limited: Microsoft euphemistically says that clients are "forthcoming," though I have yet to see one. But the method is secure.
The Message Content tab in the POP3 Properties dialog box lets you provide a default message-encoding format. In Exchange Server 5.0, the default encoding scheme can be one of several variations on MIME, Binhex, or uuencode; and the default language can be one of the character sets Exchange Server supports. You can override these defaults at the individual mailbox level or the message level.
The final tab is Idle Time-out. You can use this tab to specify whether the server will disconnect users who are on the system for extended periods without any activity. This capability is useful if you want to prevent users from logging on and leaving the connection current for a long time while they do something else, thereby unnecessarily hogging your resources (such as memory control blocks and handles).
Although you configure POP3 support at the site level, you can override the site-level configuration at the server level. If you drill down to the server level in the Exchange Administrator, you will see a Protocols object. The Protocols object lets you specify the default POP3 support for your site but change the POP3 support server by server, if necessary.
The basic tabs in the POP3 Properties dialog box at the server level are the same as those at the site level. You can enable or disable the protocol at the server level, too. For example, you can set up a site where users on only a couple of servers have POP3 access; this mechanism controls message routing and reduces the number of machines to which you need to provide TCP port 110 pass-through on the routers. In addition, the General tab contains a check box that lets you specify that you want the servers to inherit all the values from the site-level object, to simplify configuring default servers.
You can override the default site- or server-level settings at the mailbox level, as well. Screen 3 shows the Protocols tab for the mailbox of user Chris at the Athens site. (Figure 2 shows where Chris fits in the SAKES organization.) You can enable or disable POP3 support for this individual mailbox, independent of the site or server defaults. If you enable POP3 support, you can use the message encoding format default for the site or provide a different setting for this user only.
Testing with Telnet
After you set up the Exchange Server to support POP3 access to a mailbox, you need to test it. The easiest way to test the support is to use Telnet to make a TCP connection to port 110 of the Exchange Server and manually send the commands as if you were a POP3 client trying to download mail for a specific user. (For tips about using Telnet, see John Enck, "Stupid Telnet Tricks," February 1997.) Screen 4 shows the start of an interactive Telnet session attempting to connect to port 110 of the server kifissia.sakes.com, as the RFC governing POP3 requires.
This Telnet session will connect only if kifissia.sakes.com is running a POP3 service (for example, Exchange Server with the IMS installed, configured, and running and POP3 installed). In addition, of course, you must define the host name kifissia.sakes.com in the DNS or a local hosts table. If this connection succeeds, you can test the POP3 support on kifissia.sakes.com by sending commands to the server to download mail. Listing 1 shows the sequence of such an interactive session.
If you configure the POP3 support on the Exchange Server correctly, when you make a connection to port 110 of the server, the server sends back a +OK message to confirm that it is listening on that port. If the server is down, the Telnet session won't succeed (you'll get a timeout error), and you'll have to try again later. Once you make the connection, identify the user. In Listing 1, you see the command
The server confirms that it has a mailbox for that user, and you send the command
where <password> is the password for Chris's mailbox. If the password is correct, the server locks the mailbox for exclusive access, and the client can retrieve and delete messages. Entering
displays how many messages Chris has, and entering
retrieves the second message.
In this case, Chris has a message from George, another Exchange user, that says, "Can you read this?" After you download the message (and save the transfer to disk), you can delete the message (with the command dele 2), and quit the session (with the command quit).
Testing POP3 support with Telnet is quick and direct. If you haven't configured the POP3 service on the Exchange Server correctly and you haven't installed POP3, the Telnet session will fail. Using Telnet to test POP3 support eliminates other potential sources of error, such as errors in configuration of the POP3 clients.
Configuring POP3 Clients
After you test the POP3 installation, you can configure the Exchange client for POP3 access to the mailbox. Figures 1 and 2 (page 82) show Exchange user Chris who needs to access his mailbox from both the LAN and the Internet. In this case, you can configure two profiles for Chris's Exchange client, one with the Exchange Server service and one with the IMS. Configuring one profile with both services is redundant on the LAN and slow to load up when the user is on the Internet because the user has to wait for the Exchange Server service to timeout. The IMS is the POP3 client for the Exchange client and is available either with Microsoft Plus! for the Windows 95 Exchange client or with NT 4.0.
To configure IMS in an Exchange client, you create a profile and add IMS to the list of delivery services. First, select Services from the client's Tools menu and from the Services dialog box (shown in Screen 5), click Add, and then select IMS from the list of services. To configure the connection between the client and the POP3 server, click Properties to bring up the Internet Mail properties window, shown in Screen 6.
To reach the POP3 server, the client needs to know either the IP address or the host name of the server. You can fill in the Internet Mail server box with the host name of the server if the client is using DNS and the server's name is registered in the DNS. Screen 6 shows the client pointed to the Exchange server kifissia.sakes.com. If the server isn't in the DNS, you can enter its IP address. If you register with an ISP for a POP3 mail account, the ISP will tell you the name of the mail server.
Next, you need to configure the client to request mail for a specific user by entering the mailbox name and the correct password for that user.
The Advanced Options button lets you send outbound mail to a different server from the one specified in the Internet Mail server box. This option is useful if you configure some servers specifically for outbound mail and others for inbound.
The Connection tab, shown in Screen 7, lets you specify how the client physically connects to the server. If you can connect your desktop to the remote server's network before bringing up the client (for example, if you are on a LAN connected to the Internet, or you have already used RAS to connect to an ISP), select Connect using the network. With this option, the client can immediately create a port 110 connection to the server and download mail without dialing the server first. If you have not already connected to the ISP's network, select Connect using the modem and configure an entry in the RAS phone book for the ISP.
After you have configured the Internet Mail delivery service in the client, you can launch the profile and retrieve mail from the Exchange Server using POP3 over the Internet. This process eliminates much of the hassle of retrieving your mail while you're on the road and eliminates a need for maintaining a bank of modems at the office to support dial-in connections to the LAN.