In his "Inside Out" column, Mark Minasi recently described the workings of the Simple Mail Transfer Protocol (SMTP) and Post Office Protocol (POP) 3 Internet email protocols (for a list of articles about these protocols, see "Related Articles in Windows NT Magazine," page 178). This article goes a step further and describes how Microsoft Exchange Server 5.5 works with these protocols. Specifically, I'll describe what happens behind the scenes when you compose an email message in an Exchange Server-based network and send the message to a recipient on the Internet.
Internet Message Transport
When you email an Internet recipient, the mail server you connect to uses SMTP to transport the message to the recipient's email server. Let's look at an example to see how this process works.
Suppose I'm connected to my corporate messaging network and I want to email my friend Mark at email@example.com. After I compose and send the message, it leaves my desktop and travels through my corporate network until it reaches an Internet mail gateway. On my network, this gateway is server Hermes, with host name hermes .paradigms.com.
When Hermes receives the email message, it examines the recipient's address and attempts to locate the SMTP mail server on the Internet that houses Mark's mailbox. To locate the correct mail server, Hermes queries a Domain Name System (DNS) server for the mail exchanger (MX) and address (A) records for the domain. (For more information about DNS, see "Related Articles in Windows NT Magazine.") Because I'm sending a message to firstname.lastname@example.org, Hermes will look for MX and A records that match minasi.com. If you perform an NSLOOKUP for minasi.com on any DNS server connected to the Internet, you see the following information:
minasi.com MX preference = 10, mail exchanger = arlington.minasi.com
arlington.minasi.com internet address = 18.104.22.168
This information tells Hermes that the Exchange server for my network should deliver email for anyone at minasi.com to server arlington.minasi.com, which has an IP address of 22.214.171.124. To send email to email@example.com, Hermes attempts to connect to TCP port 25 of the Arlington server. To receive SMTP email, Arlington must run SMTP host software and respond appropriately when any server sending SMTP email connects to it. You can Telnet to TCP port 25 of Arlington to see the reply Hermes will receive, which will look similar to the following reply:
220 arlington.minasi.com ESMTP Server (Microsoft Exchange Internet Mail Service 5.5.1960.3) ready
This information tells Hermes that the Arlington server is an SMTP host ready to receive email. In addition, Hermes can see that Arlington is running Microsoft Exchange Server and the Internet Mail Service (IMS), and supports Enhanced SMTP (ESMTP). At this point, Hermes hasn't confirmed that Arlington will receive email for the domain minasi .com or that user firstname.lastname@example.org exists, but Hermes trusts the DNS records. Hermes then begins to transfer my email message to Arlington using SMTP.
Exchange Server's SMTP Support
In addition to being the Internet mail gateway for my network, Hermes runs Exchange Server 5.5. My mailbox is on another server (Athena), and I use the Outlook email client. Unfortunately, I don't know whether the mailbox for email@example.com is on Arlington or on a remote network server, and I can't be sure what email client Mark will use to read my message. As a result, I assume that the environment looks similar to what you see in Figure 1.
Figure 1 shows two Outlook clients (Patmos and MarkPC) and three Exchange servers (Athena, Hermes, and Arlington), with differing functions. My email client is on Patmos, and Mark's email client is on MarkPC. My mailbox is on Athena, and Mark's mailbox is on Arlington. IMS is running on Hermes and Arlington, and the Message Transfer Agent (MTA), which delivers the email to the proper recipient, is running on all three Exchange servers.
Figure 1 also shows a DNS server (with host name dns.dcnw.com) running at an Internet Service Provider (ISP). IMS and MTA are true NT services that you can view under the Services applet in Control Panel, as Screen 1, page 180, shows (you will see IMS in the list of NT services only if you install it on an Exchange server on your network).
All Exchange servers must run four core services: MTA, the Information Store, the Directory Service, and the System Attendant. The Information Store houses email messages and recipients' mailboxes. The Directory Service maintains the directory, including the address book and address-book lookups. The System Attendant is a base service that all the other services depend on.
Within an Exchange-based organization, the servers' MTA services deliver all the email. These services use SMTP, X.400, or MS Mail addresses to locate and identify the Exchange recipients. Individuals with Exchange mailboxes can always address and send mail to other Exchange users in the same Exchange-based organization using the SMTP address format (i.e., user@ domain). You don't need to install and configure IMS to enable this level of email delivery. However, if you install and configure IMS on any of the organization's Exchange servers, individuals can send email to users within the organization and on external mail systems (e.g., the Internet). In the example in Figure 1, my email message to Mark travels through the system as follows:
1. I use the Outlook client on Patmos to compose and submit my email message for delivery. The message is in a proprietary Microsoft format and Outlook uses Messaging API (MAPI) function calls to deliver the message to Athena, the Exchange server that houses my mailbox.
2. MTA on Athena recognizes that my email message is addressed to a recipient outside my network, so it transfers the message to Hermes, the only server with an external gateway.
3. MTA on Hermes receives my email message from Athena, sees that the message is addressed to a recipient outside my network, and hands the message to the local IMS for processing.
4. IMS on Hermes converts the message from MAPI binary format to SMTP plain text. IMS then performs a DNS query (e.g., to dns.dcnw.com in Figure 1), and connects to IMS on Arlington to deliver the plain text message via SMTP.
5. IMS on Arlington checks the recipient, recognizes firstname.lastname@example.org as a local address, and translates the plain text message back to MAPI format.
6. MTA on Arlington receives my email message from the local IMS, and places the message in Mark's mailbox on Arlington.
7. Mark reads the message with the Outlook email client, using MAPI, POP3, or the Internet Message Access Proto- col (IMAP).
Several actions happen in step 2 of this process. When I submit my email message to Athena, MTA looks at the Exchange Global Address List to determine whether the email@example.com address belongs to someone in my organization. Because this address is outside the organization, MTA looks in a Gateway Address Routing Table (GWART) to determine whether a server in the organization can deliver external mail. When my company installed IMS on Hermes, the software put an entry into the organization's GWART that said, "Hermes can handle all outbound SMTP mail." Consequently, when Athena's MTA looks at the GWART to determine which server can deliver my email message, it finds Hermes. IMS on Hermes then processes the mail according to the requirements in the Request for Comments (RFC) for SMTP messaging. Note that only two computers (Hermes and Arlington) in this scenario must support the SMTP protocol. The other computers in the network don't require any additional software, and you don't need to modify their existing software to enable SMTP messaging.
Exchange Server's POP3 Support
When my email message arrives in Mark's inbox, Exchange stores the message in the Information Store (priv.edb) on Arlington, which I assume houses Mark's mailbox. Mark can read my email message with any email client, including those that use POP3, MAPI, and IMAP.
A POP3 server listens on TCP port 110 for a user such as Mark to connect, identify himself, and download his mail. With Exchange Server, the Information Store service listens on TCP port 110. You don't need to install and run any additional service (such as an Exchange POP3 service) for Exchange to support POP3, and you don't even have to install IMS in the organization. However, you must enable POP3 for a user at the site level, the server level, or the mailbox level.
A Protocols container at the site level includes a POP3 object. Screen 2, page 182, shows the properties of the POP3 object. When you select the Enable protocol check box, the Information Store listens on the server as TCP port 110 for user requests. You can Telnet to TCP port 110 of the server to see the reply a client program will receive, which will look similar to the following reply:
+OK Microsoft Exchange POP3 server version 5.5.1960.6 ready.
This response tells the client that the server is a POP3 server and is ready to authenticate users and give them their email. At this point, the client identifies the user and requests email using POP3. When you enable POP3 at the site level, you automatically enable it at the server and mailbox levels. Screen 3 shows the properties of Mark's mailbox on Arlington, and displays the protocols enabled for his mailbox.
Screen 3 shows that Mark can access his mailbox with several protocols, including POP3. Mark's mailbox inherits these protocol settings from the Exchange server, but you can modify these settings for each mailbox by clicking Settings. Screen 4 shows the details of Mark's POP3 settings.
You can turn off POP3 support for a particular user, or you can change the parameters that determine how the server handles POP3 messages. As you can with many Exchange features, you can define a default behavior for a group of users and override it as necessary.
Now that you have an idea of how you can use Exchange Server with SMTP and POP3 to deliver and read email, you can start to optimize the email clients within your Exchange-based organization. In a future article, I'll describe how you configure various Microsoft email clients (Exchange, Outlook, Outlook Express, and Internet Explorer) to use different protocols such as SMTP, POP3, IMAP, and HTTP with Exchange Server.