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 mark@minasi.com 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 mark@minasi.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.
End of Article
Prev. page
1
[2]
next page -->
