Exchange 2000 and SMTP

Simple Mail Transfer Protocol (SMTP) is the cornerstone of messaging interoperability across the Internet. Microsoft Exchange Server has always been able to send messages to other SMTP servers by using the Internet Mail Connector (IMC), an optional added-cost component for Exchange Server 4.0, and the Internet Mail Service (IMS), a standard component available to all Exchange Server 5.5 and 5.0 servers. Although anyone can now opt to install the IMS, SMTP connectivity isn't at the heart of earlier Exchange Server versions. The IMS is like any other connector to email systems (e.g., Lotus Notes, cc:Mail, IBM PROFS) and functions as a partner service to the X.400-based Message Transfer Agent (MTA), which makes all the decisions about how to route messages within an enterprise. Routing is a process that assesses the addresses in message headers and decides how best to transport the messages inside and outside a messaging system's boundaries. In Exchange Server 5.5 and earlier, the MTA performs this function. In Exchange 2000 Server (formerly code-named Platinum), a brand-new SMTP-based routing engine takes over.

The architecture that groups different connectors around the MTA goes back to the earliest designs for Exchange Server and reflects the position that X.400 once held as the standard for messaging interoperability. Currently, SMTP holds that position—specifically, the enhanced versions of SMTP that the major messaging systems now implement. SMTP is at the heart of Exchange 2000's message routing and will keep mail flowing during your migration from older Exchange Server systems.

Before Exchange 2000 hits the streets, you need to understand SMTP's history and evolution, its integration with Exchange Server, its role in routing and administration, and its future in the messaging realm. You also need to know how routing groups logically group servers together for the process of sending email. I've based this article's technical information on Exchange 2000 beta 3. The graphical appearance of the screens might change before the software's final release. However, the details about how routing works is unlikely to vary from what I describe.

SMTP's History and Evolution
In 1982, the Internet Engineering Task Force (IETF) defined SMTP in Request for Comments (RFC) 821 and RFC 822. True to SMTP's name, the original protocol was simple and concentrated on the task of sending 7-bit plaintext messages across an IP link between a client and a server. Port 25 is the default port for all SMTP operations.

Since 1982, SMTP has evolved to accommodate the requirements of today's messaging environment. Not surprisingly, given the Internet's pace of change, evolution has been brisk in recent years. Extended SMTP (ESMTP) and Multipurpose Internet Mail Extension (MIME) are the two major advances that have enabled SMTP to deliver highly functional messaging systems.

ESMTP. ESMTP lets vendors add extensions to the basic SMTP service so that they can deal with different classes of messages or other functionality. Exchange Server 5.5 supports ESMTP also because it allows easier pickup of messages queued at ISP mail systems. You need this capability if you connect to the Internet through an ISP and aren't online all the time. The ISP holds messages for your domain until a connection exists, at which point you can instruct Exchange Server to fetch the messages for delivery to local recipients.

Earlier versions of Exchange Server support some ESMTP commands. (For more information about ESMTP, go to the Simpler-Webb Web site at http://www.swinc.com.) For example, to support SMTP over dial-up connections, Exchange Server 5.5 added the extended turn (ETRN) command extension, which also simplifies message dequeuing. (For more information about ETRN, check out http://www.exchangepop3.com/ep3/support.faq/r.faq.general.whynotuseetrn.html.) To support authenticated and encrypted connections between Exchange Server and other SMTP servers, Exchange Server 5.5 Service Pack 2 (SP2) and later versions added the AUTH=LOGIN, STARTTLS, and TLS extensions. To determine the level of ETRN support that an SMTP server offers, you can use Telnet to connect to port 25 and issue an EHLO command. The server responds with a list of keywords for the extensions it supports. Screen 1 shows the support that Exchange Server 5.5 SP2 offers, and Screen 2 shows the list that Exchange 2000 offers. The most important of these new extensions are CHUNKING, PIPELINING, Delivery Status Notification (DSN), and X-LINK2STATE (which I talk about later).

• CHUNKING supports streamed-mode data transfer, which means Exchange 2000 can send and receive messages in binary chunks rather than line by line. Older SMTP servers, including the IMS, process SMTP messages as if they were composed of lines of text instead of the complex structure of body parts (i.e., the pieces that make up a message) we see today. From a performance perspective, the ability to process message data on a binary basis is important—especially as attachments grow larger.

• PIPELINING also aids performance.
  It lets the SMTP server issue a set of commands without pausing to wait for an acknowledgment from each command.
• DSN lets Exchange 2000 provide standard delivery and nondelivery notifications to users. These notifications replace some of the esoteric and cryptic content that Exchange Server 5.5 sends to users when messages fail to get through via the IMS.

MIME. Sending plaintext messages can be boring, especially in today's graphical age. Early encoding schemes such as UUencode let correspondents exchange attachments and formatted text, but these schemes typically weren't well integrated. Also, you needed to precisely configure the tags that different attachments used before you could confidently send an attachment that the recipient could understand.

MIME solves this configuration problem by establishing rules for the labeling and transmission of different data types within messages. Basically, MIME tells mail systems how to process body parts so that recipients see exactly what the sender intended. You're probably accustomed to using MIME to send items such as Microsoft Word documents and Microsoft PowerPoint presentations between companies. MIME is also the basis for the transmission of streaming data such as audio and video messages, which tend to be much larger than documents or presentations. A famous example is the 25GB Phantom Menace trailer, which caused many email systems to gasp for breath as users forwarded the trailer to friends.

Connector limitations can restrict the size of outgoing messages and stop users from sending such large attachments to other companies; however, circulating large attachments can stop or retard the flow of internal mail. Administrators justifiably worry about the impact that large messages have on systems and discourage people from sending large voice or video attachments. However, large attachments are the way of the future. You can only expect to see an increasing number of large attachments floating around your network.

SMTP and Exchange 2000
Microsoft built Exchange 2000 on the premise that SMTP is the basic protocol for all server-to-server communications—a radical departure from previous implementations, which use remote procedure calls (RPCs) for most server-to-server communications. The move away from RPCs is welcome. When they work, RPCs are great, but they require a lot of bandwidth to work effectively all the time. When RPCs don't work, large message queues can accumulate very quickly. Moving away from RPCs is part of Exchange 2000's general tendency to replace proprietary Microsoft protocols with Internet protocols. Exchange 2000 uses RPCs only when connecting to a downstream server in a mixed-mode organization. (A mixed-mode organization supports both Exchange 2000 and earlier servers.) This use is logical, because RPC is the only protocol that provides guaranteed availability across every version of Exchange Server.

In earlier versions of Exchange Server, you needed to separately install and configure SMTP support. By contrast, SMTP automatically installs on all Exchange 2000 servers. Indeed, every Windows 2000 (Win2K) server installs a basic SMTP service that lets applications send data between servers. Win2K uses this capability to replicate Active Directory (AD) information between Win2K sites. After you install Exchange 2000, the basic SMTP service extends with new capabilities, including support for mailboxes and the advanced queuing mechanism. Technically, Exchange 2000 upgrades the SMTP service to support Collaboration Data Objects (CDO) 3.0 instead of 2.0. Among the other changes, the advanced queuing mechanism allows the implementation of mailbox and connector restrictions. Installing the first Exchange 2000 server in a forest updates the AD schema to support the additional attributes that these restrictions require. In addition to the mailbox quotas that Exchange Server 5.5 supports, you can now stipulate that a connector is available only to specific users or barred to others, or that messages of a certain size can travel across a connector only at specific times.

The fact that Exchange 2000 extends Win2K's basic SMTP service illustrates the tight integration between the OS and the messaging server. Whereas Exchange Server 5.5 and Windows NT have a close relationship, Exchange 2000 and Win2K connect at many different points at a lower level. This weave of interconnections complicates systems administration and places a premium on attention to detail. To manage an Exchange 2000 system successfully, you must be aware of all of the dependencies and linkages. Screen 3 shows that the SMTP service depends on Microsoft Internet Information Server (IIS), the Exchange Server Information Store (IS), and Exchange System Attendant services. Problems that occur with IIS or the IS might affect the SMTP service. Likewise, if the SMTP service experiences difficulties, you probably won't be able to send messages between your server and other Exchange servers, or to the outside world. An SMTP malfunction will also affect other applications. For example, because replication between Win2K sites can occur through SMTP messages, AD intersite replication might stop working if you misconfigure SMTP on a domain controller.

Virtual Servers
Through IIS 5.0, Win2K implements virtual server support for a selection of Internet protocols, including HTTP, SMTP, POP3, and Internet Message Access Protocol 4 (IMAP4). Think of a virtual server as a combination of a protocol, port number, and configuration data. Multiple virtual servers can run on one physical computer, so you can now run multiple SMTP virtual servers on one Exchange 2000 server. The default virtual server will connect to port 25, but you could equally assign other virtual servers to use other ports and then use those virtual servers to handle email going to different domains. This important piece of functionality lets Exchange 2000 support many different email domains on one server, which is something that ISPs need to do all the time. Additionally, Exchange 2000 supports multiple SMTP connectors on a virtual server. Think of IMS as an SMTP connector. Today, you can run only one SMTP connector on a physical computer, but with Exchange 2000 you can configure multiple connectors, each for a specific purpose. For example, you might configure one connector to route messages to internal systems and another to send all external mail and direct that external mail through a SmartHost system, where a virus checker checks messages before they go to the Internet.