9.2 The evolution of SMTP

---

The earliest implementation of SMTP provides a very rudimentary means of transferring messages from one system to another. RFC 821 (and the closely associated RFC 822) only allows for the transfer of 7-bit ASCII text messages. If you monitor the traffic going to port 25 on an Exchange server, you can see that the interaction between SMTP servers is very straightforward. The protocol defines how to contact a server, how to transmit data to set up the connection and establish the link necessary to transfer messages, how to transfer the message content, and then how to sign off.

The major virtue of content simplicity is that nearly every email system can understand 7-bit text, and SMTP lived up to its name in its ability to send simple text messages between people. Success in the commercial email world depends on meeting user requirements, and the success of Windows as the desktop platform of choice introduced many new file types to the equation. Clearly, something had to happen to enable SMTP to transport the huge array of PC files that people wanted to send to each other. Equally important, while 7 bits are acceptable in a U.S.-English environment, many characters in daily use outside the United States are not included in 7-bit ASCII.

A new protocol developed to overcome the serious limitations in SMTP. MIME, or Multipurpose Internet Mail Extensions, supports binary attachments and guarantees message fidelity across SMTP gateways. Although specified in RFCs 1341 and 1342, MIME does not replace RFCs 821/822. Instead, MIME is fully backward compatible with early implementations of SMTP and is designed to extend the basic messaging functionality defined by SMTP. In some cases, you can still use UUENCODE as an alternative mechanism to transmit attachments. The MIME protocol defines a mechanism for declaring the different parts that might be included in a message, such as the header, body text, and attachments. At the same time, MIME defines the methods required to transform complex content so that a messaging system can transport this data as easily as if it were simple text. MIME meets its goals by introducing a number of new message header fields, including fields to specify the content type (text, multipart, application, message, video, and so on) and the content encoding scheme. Most MIME-encoded messages seen in an Exchange environment use the Base64 encoding scheme, which allows binary data to travel across transports originally designed for 7-bit transmission.

The collective evolution of SMTP and MIME provides the foundation for the Exchange Routing Engine, but only after extension of the basic protocols. The key development here is the definition of ESMTP (extended SMTP) in RFC 1869. ESMTP allows new commands to extend the basic protocol, either those defined in another RFC and so generally supported within the SMTP community, or commands intended for use by specific applications. Exchange uses ESMTP to support a wide array of the industry-standard extensions, as well as an extension of its own to support the propagation of link state routing information between servers. The S/MIME extensions allow the basic MIME protocol to accommodate the requirements of secure email. S/MIME enables the reliable transmission of encrypted messages and the keys necessary to decrypt the messages between SMTP gateways. Exchange has supported S/MIME since Exchange 5.5 SP1.

9.2.1 SMTP extensions in Exchange

Performance and scalability are very important to Exchange. The most important ESTMP extensions supported by Exchange 2000/2003 are:

• Pipelining:   The ability for an SMTP client to issue many commands without waiting for the server to acknowledge each command, in the knowledge that the acknowledgments will eventually arrive in the same order that they are issued. The original RFC 821 states that an acknowledgment (usually in the form 250 OK) is sent after each command. This implementation was necessary in the early days of computer networks, but is less important as the reliability of networks improved. Pipelining, defined in RFC 2197, avoids the overhead of waiting for command acknowledgments, speeds up communication between SMTP clients and servers, and so increases message throughput.

• 8-bit clean:   The SMTP transport complies with the 8-bit MIME standard (defined in RFC 1652), so it is able to pass and accept 8-bit MIME content without having to interpret it. Exchange servers send messages in 8-bit MIME format within a routing group, but downgrade to 7-bit format (Base64 encoded) inside a mixed-mode organization that contains an older Internet Mail Service (IMS). The logic here is that Exchange might eventually have to redirect the message via the IMS, and it is safer to ensure that all parts of the messaging system can transport the content from start to finish instead of constantly checking as the message passes through different servers. Exchange 2003 servers are able to make full use of 8-bit clean mode when communicating between bridgehead servers to eliminate the overhead of converting to and from 7-bit MIME format. Seven-bit MIME requires approximately 30 percent more overhead than 8-bit, so avoiding the conversion saves CPU cycles and network bandwidth.

• Delivery Status Notification (DSN):   The ability to tell you whether the messaging system has successfully delivered to its final destination. Exchange supports delivery status notifications as defined in RFCs 1891, 1892, and 1894. The Routing Engine parses DSN data to ensure that clients interpret and display delivery information in a manner that may be specific to the client. For example, Internet clients such as Outlook Express receive DSNs formatted exactly as laid out in the RFCs, while Outlook receives DSNs formatted in the style used since the original MAPI clients. Microsoft upgraded DSN processing in Exchange 2000 SP2, and work continues in this area to ensure that users receive information that is understandable and clear. For example, Figure 9.1 shows a delivery notification that tells the recipient that Exchange was unable to transmit the message because it exceeded the acceptable size (5 MB) on the destination SMTP server. Enough human-readable detail is provided to allow a help-desk representative to interpret why the message was undelivered and to perform the steps necessary to get the message through. Engineers and users tend to disagree exactly where to draw the line between readability and technical accuracy, and ongoing work is required to cater to all possible causes that prevent message transmission, but Exchange is good in this respect. See Table 9.1 for a list of DSN error codes.

  
  Figure 9.1: A DSN displayed by Outlook 2002.

  Table 9.1: DSN Error Codes

  DSN	Meaning
  4.2.2	Mailbox quota exceeded.
  4.3.1	Flagged as a memory exceeded error, but is usually caused by a disk full condition somewhere (such as the disk holding the SMTP drop folder).
  4.3.2	The administrator has manually caused the message to be nondelivered.
  4.4.1	Host is not responding-could be a transient network error or the target server is down.
  4.4.2	Connection dropped between servers.
  4.4.6	Message exceeded maximum hop count.
  4.4.7	Message expired in queue.
  4.4.9	An SMTP connector has a non-SMTP address space defined, and Exchange attempted to use the SMTP connector to route the message.
  5.0.0	Hard categorization error, normally indicating that the message is corrupt. The error can also be provoked if SMTP cannot route the message, because no connector can handle the address on the message. You can often resolve this problem by ensuring that at least one SMTP connector can handle an address space of *.
  5.1.0	Generic categorization error, normally caused by a missing attribute on the message.
  5.1.1	An unresolved address-based on its SMTP or X.400 address, the address seems to belong to this Exchange organization, but a lookup cannot resolve the address against the directory.
  5.1.3	The address on the message does not conform to RFC 821 specifications (bad address syntax).
  5.1.4	More than one object in the directory has the address on the message, so it is ambiguous and the categorizer cannot resolve it.
  5.1.6	The recipient is in the directory, but does not have an associated Exchange server (home server or home Mailbox Store), so the categorizer cannot deliver the message.
  5.1.7	The sender of the message has a missing or malformed address in the AD, so the transport engine cannot deliver the message.
  5.2.1	The message is too big for delivery or the recipient's mailbox is disabled.
  5.2.3	The originator attempted to send a message larger than permitted or the recipient cannot accept a message of this size.
  5.3.3	The remote server does not have enough disk space to accept incoming messages.
  5.3.5	Loop back detected. The server is configured to loop back on itself.
  5.4.0	DNS lookup error (host not found, smarthost entry incorrect)
  5.4.4	Routing hop not found.
  5.4.6	A forward loop exists in the categorizer for this recipient.
  5.4.8	The categorizer was processing a message for a recipient with a mailbox on a remote server, but the FQDN of the remote server matches a local domain.
  5.5.0	An SMTP protocol error-you normally find an explanation about why the protocol error occurred in the DSN text. The 5.5.0 error in Figure 9.1 shows that the message size exceeded a limit set on a connector somewhere along the message path.
  5.5.2	SMTP commands are executed out of sequence.
  5.5.3	The sender of the message cannot address a message to so many recipients. You can configure recipient limits on both a per-user and an organization-wide basis.
  5.7.1	Access denied because the originator cannot send messages to this recipient. Alternatively, the user may be attempting to send a message on behalf of another user without the appropriate permission.

• Chunking or BDAT: Normally, servers transmit the content portion of SMTP messages as one or more DATA statements. Each statement (or line) terminates with a CR/LF, full stop/CR/LF sequence. This implementation works well for small text-based messages but is less successful when dealing with very large encoded attachments of the type that circulate in corporate messaging systems today (PowerPoint presentations, large Word documents, MPEG files, and so on). RFC 1830 defines BDAT (or binary data transfer) as part of the "chunking" ESMTP specification and replaces the standard DATA command. BDAT always passes an argument, which specifies the number of octets contained in a message bodypart, and then proceeds to stream content to the server until all the data is transmitted. No attempt is made to interpret or understand the content, and the server only has to wait until the expected amount of data has arrived to know when transmission is complete. This approach allows the SMTP virtual server to send and receive messages much more quickly than by using the DATA command. Exchange servers always attempt to use BDAT after they have created outbound connections to another SMTP server. If the other server cannot support BDAT,^[1] Exchange automatically downgrades the connection to use the standard DATA command. Connections between Exchange 2000/2003 servers always use BDAT. Together with the streaming file, chunking allows Exchange 2000/2003 to process messages containing audio or video content very efficiently. Chunking provides SMTP with a big advantage over X.400, which is relatively chatty in terms of acknowledgments and checkpoints as large messages pass across the wire. Opening up a connection and streaming data until the correspondents reach an agreed-upon point allows the SMTP server to transfer data faster. However, if a message fails in the middle of transmission, chunking does not allow servers to restart from a checkpoint, and they must resend the complete message.

In addition, Exchange (and the basic SMTP service provided by Windows) supports the following:^[2]

• VRFY (RFC 821): verify or ensure that the server can deliver a message to a local recipient. While the verb is present, Exchange does not use it.

• EXPN (RFC 821): expand a distribution list into individual recipients. The command asks the server whether the recipient is a distribution list and, if so, to return the membership of the list.

• ETRN (RFC 1985): an extension of the standard TURN command, which reverses sender and receiver roles. The standard TURN command enables clients to download messages for a domain but does not include any validation mechanism. Thus, it is possible that a rogue system could attempt to download messages held on a server (normally managed by an ISP) for a site or domain other than itself. ETRN provides a mechanism for a client SMTP system to request download for a specific queue of messages. The host server can then decide whether to honor the request and dequeue the messages.

• SIZE (RFC 1870): provide an indication of how large a message is. SIZE also advertises the maximum size of a message a server will accept.

• TLS (RFC 2487): a method to use transport-level security to protect the communications between SMTP clients and servers.

• AUTH (RFC 2554): a method to allow an SMTP client to negotiate an agreed-upon authentication mechanism with a server. As shown in Figure 9.2, Exchange supports GSSAPI, NTLM, and LOGIN as authentication and encryption mechanisms. Exchange 5.5 supports NTLM (NT Challenge/Response) and TLS (Transport-Level Security), both of which implement an SSL-secured connection.

  
  Figure 9.2: Extended SMTP commands supported by Exchange.

The list of commands may vary in the future with support packs and updates to both Windows and Exchange. To verify the current list of commands supported by SMTP on your server, TELNET to port 25 on the server and issue an EHLO command. The server returns a list of keywords for the commands supported by the server, as shown in Figure 9.2. The version number reported at the top of the screen tells you which version of Exchange is on the server.

Note that the commands listed by a particular server may not be the complete set. For example, the server queried in Figure 9.2 does not list the STARTTLS or TLS commands, because a certificate is not available for the server to use to encrypt traffic. Servers issued with certificates will display these commands when they respond to an EHLO query. Apart from the list of commands, Figure 9.2 also reveals some information about the server. The version number reported by the SMTP server reveals the version of IIS that is running on the server, in turn revealing some information about Windows. In this case, we see that the server reports version 6.0.3790, meaning that this server runs IIS 6.0 on Windows build 3790, which turns out to be the RTM build of Windows 2003. You can discover similar information about the version of Exchange running on a server if you TELNET to port 110 (POP3) or 143 (IMAP4) and examine the version number. For example, a version number starting with 6.0 means an Exchange 2000 server, while anything starting with 6.5 means Exchange 2003. The numbers after 6.0 or 6.5 reveal the service pack level, so 6.0.6249.0 indicates a server running Exchange 2000 SP3, and 6.5.6944.0 is the RTM build of Exchange 2003. Why does one protocol reveal information about Windows and another informs about Exchange when IIS controls all the protocol stacks? Well, SMTP is a basic Windows service, so its version number depends on Windows. POP3 and IMAP are services provided by Exchange, so their version number depends on Exchange. See section 9.2.4 for a discussion on how to suppress banner information reported by protocol servers.

Windows and Exchange both depend heavily on SMTP to transport messages between servers. Indeed, the Exchange development group provides the code for CDONTS, which ships with every Windows server as part of IIS. The basic SMTP functionality in Windows is similar to that in many UNIX servers and is a no frills messaging server. The basic SMTP server does not include the capability to send messages between mailboxes. Instead, the SMTP server provides Windows and other products with a well-known transport that can carry information between applications. The best example of this is intersite AD replication, and SharePoint Portal Server is another good example, since it uses the SMTP service to send subscription messages to users after users add new documents to its repository.

Administrators manage the SMTP service through the Internet Information Services MMC console, and IIS holds its configuration data in the IIS metabase. The SMTP service runs as part of the INETINFO process, in the same manner as all the other protocols supported by IIS. Because the AD holds the Exchange configuration data, a background process managed by the System Attendant synchronizes the AD with the IIS metabase. The same situation is true for all protocols.

The SMTP service supports many of the extended functions defined by ESMTP as well as virtual servers and scripting. Clients can generate and send messages programmatically or by communication through the standard SMTP listener port (25). Alternatively, applications can generate text messages in SMTP format and submit them for processing by placing them in the SMTP drop directory.^[3]

Apart from the functions available through the IIS MMC console, no management capabilities are available to control or manipulate the SMTP service. You can, therefore, conclude that the SMTP service is so basic that either it is working or it is not. In other words, if you can create and send messages, then the SMTP service is operational. If problems occur, you usually have to restart the SMTP service to correct matters.

When Exchange is installed, the base SMTP service is upgraded (not replaced) to add the features for advanced queuing and routing and the new SMTP command verbs to enable link state routing updates. Exchange upgrades SMTP capabilities by adding a new event sink and some transport and protocol events that allow SMTP messages to flow into the Store via ExIFS. Transport events extend the function of the transport core, while protocol events extend the SMTP protocol. After the upgrade, the most important difference is that the extended SMTP service understands how to process messages sent to mailboxes.

Figure 9.3: Dependencies of the SMTP service.

Because Exchange upgrades the basic SMTP service to add its own set of events, it follows that the SMTP service becomes a very large dependency for Exchange. In fact, Exchange also becomes a dependency for the SMTP service, as you can see in Figure 9.3. Interdependencies mean that you have to be careful when you manage components. For example, you should not reinstall the SMTP service from the Windows distribution kit without also reinstalling Exchange.

9.2.2 SMTP virtual servers

Windows and Exchange both implement SMTP protocol support in the form of virtual servers managed by IIS. A virtual server is composed of an IP address, IP port, and protocol. This is a major difference from the previous implementation in first-generation Exchange servers, where a connector (the Internet Mail Service) binds SMTP protocol access to a specific port. Once bound, SMTP remains associated with that port, and only one instance of the protocol can exist on a server. For example, the Exchange 5.5 IMS usually binds to port 25, so port 25 is the only port that can accept SMTP traffic. Now, the default virtual server for SMTP is a combination of the SMTP protocol, a port, and one or more IP addresses. The virtual server handles all SMTP traffic sent to those IP addresses and port. Exchange takes the same approach with the virtual servers for the other Internet protocols. For example, the default virtual server for HTTP is composed of HTTP and port 80, and so on.

When you upgrade an Exchange 5.5 server that hosts an Internet Mail Service (IMS), the default SMTP virtual server takes over the role played by the IMS. The address space defined in the configuration of the IMS becomes an SMTP connector that runs as part of the virtual server. You can have more than one SMTP connector on an individual server, a useful configuration if you want to process outbound mail to different destinations in a different manner. For example, you might decide to create a special SMTP connector to handle messages going to nonurgent personal Internet mail services such as hotmail.com, msdn.com, aol.com, and so on. You can then configure the connector with a schedule to pass messages outside normal business hours, so that messages sent to commercial destinations receive a higher priority.

Routing group and SMTP connectors both use the SMTP protocol and are therefore associated with a virtual server. All of the connectors tied to a virtual server respect its properties, which control how the virtual server operates. You can view and work with the properties of the virtual server through ESM by selecting the hosting server, opening the protocols container, and then selecting the virtual server. Apart from logging, you do not have to restart a virtual server or connector before a change to a property becomes active. ESM signals any updates as events that the virtual server recognizes, so the effect of making a change to a server's properties is almost immediate. Table 9.2 outlines the default settings for SMTP virtual servers.

Table 9.2: Important Settings for an SMTP Virtual Server

Virtual SMTP Server Property	Default Value	Other Possible Values
Outbound security	Allow anonymous connections. Exchange servers ignore this setting, since they establish their own credentials before sending messages.	Require basic authentication (clear text) or TLS (encrypted) with an X.509 server certificate
Inbound security	Allow anonymous connections (must be set to allow IMAP and POP clients to send messages)	Require basic authentication or TLS
Port number	25	Any free IP port
Limit message size	2,048 KB (2 MB)
Limit number of messages per connection	Unlimited
Limit number of recipients per message	Unlimited
Outbound retry intervals	First, 15 minutes; second, 30 minutes; third, 60 minutes; then 240 minutes until timeout
Delay notifications	Send after 12 hours
Expiration timeout	2 days
Local delivery delay	12 hours
Maximum hop count	15
Smart host name	FQDN or IP address of smart host server
Connection controls	All servers can connect	Define a list of servers that are allowed to connect to this server
Relay restrictions	All servers that can connect can relay (submit messages for onward delivery)	Define how servers handle attempts to relay messages

If you run in a heterogeneous messaging environment that includes UNIX or Linux servers, you should also check that the FQDN of the server is a value that SMTP MTAs running on the UNIX and Linux servers can resolve. The RFCs that govern DNS (1034 and 1035) do not accommodate the underscore character in server names, but Windows is quite happy if you use an underscore to name a server. For example, the name EXCH_SVR is perfectly valid for Windows, but when it appears in an FQDN (EXCH_SRVR.abc.net), some SMTP MTAs may refuse connections and will not transfer messages. In this situation, you probably do not want to rename the server, so it is good that you can work around the issue by accessing the Delivery property page for the SMTP virtual server, then Advanced, and then change the server's FQDN to remove the underscore (in this case, to EXCHSVR.abc.net). Now, whenever the SMTP virtual server connects, it passes the name you define, rather than the default value, and the remote MTA is happy. You may also want to update the DNS PTR record for the server to the new name so that it can be resolved externally.

9.2.3 Relays

The default SMTP virtual server is the basic building block for the routing group and SMTP connectors, the two preferred ways to link Exchange servers together. You do not need to define a second virtual server unless you really have a good reason to use another. Performance is not one of the reasons. Virtual servers are multithreaded anyway, so creating a second virtual SMTP server does not increase the ability of the computer to process SMTP messages any faster. Remember, all incoming messages arrive at port 25 and are then processed by the default SMTP virtual server. You can create another virtual SMTP server that sends outgoing messages through another port, but you have to ask yourself why you want to add any more complexity to your administrative environment than you already have. You only need to configure separate virtual servers when a requirement exists to handle messages sent to specific domains in a different manner, or when you want to handle messages above a certain size or messages with a particular priority.

Table 9.2 lists many of the important settings that you can apply to an SMTP virtual server. The settings give some insight into the reasons why you might want to create a new virtual server. For example, let us assume that you want to allow a specific set of external systems to use your server as a relay, but you only want them to be able to send messages of a certain size, and an authentication connection is necessary. You could apply these settings to the default virtual server, but then they would affect all connections, and you might want to allow messages sent locally to be larger, have more recipients, or not require an authenticated connection. Remember that you must clearly define the address space for each virtual server so that it can process email for various domains.

Mail relays are an integral part of the SMTP architecture, so the fact that a server allows relaying is not bad in itself. Relays are fine, as long as they are controlled and used for the purpose that you want to use them for, such as allowing IMAP4 clients such as Outlook Express to send messages by making a connection to an SMTP server. The Internet is a great place, but it has some seedy quarters and practices, most notably spam or unsolicited commercial email.

9.2.4 Changing SMTP banners

SMTP servers respond to incoming connections with a banner message, which contains information about the type of server and the version of the software it runs. For example, if you TELNET to port 25 on an Exchange 2000 server, the default response of the SMTP server is:

220 server name.domain name Microsoft ESMTP Mail Service, Version 5.0.2195.2966 ready at <time> 

A hacker may be able to use this information to determine how best he or she can attack the server. The response tells the hacker the version of the software (5.0.2195 indicates the RTM build of Windows 2000, with 6.0.3790 meaning the RTM build of Windows 2003). Hackers also know that the server is ESMTP capable and so will respond to a wider set of commands. You can frustrate hackers by changing the banner to whatever string you like by editing the IIS metabase. This is a good example of the dependency that Exchange has on the IIS, since there is no way to edit the banner through ESM or any other Exchange-specific utility. Follow these steps to change the banner:

• Download an IIS metabase editing tool such as MetaEdit^[4] and install it on the server where you want to change the SMTP banner.

• Open the utility and navigate to the node for the SMTP virtual server. Remember, a physical server can support multiple virtual protocol servers, and the IIS metabase contains separate information for each virtual server. The node for the default SMTP virtual server is Lm\Smtpsvc\1.

• Click on the Edit option, click New, and then click on String to add a new string value.

• Verify that the entry in the ID box is Other, and type 36907 in the space to the right of the ID box (Figure 9.4). The identifier for the string used in the banner is 36907.

  
  Figure 9.4: Editing the IIS metabase to change an SMTP banner.

• Type the new banner string in the Data box and click on OK.

• Exit the metabase edit utility.

• Use ESM to stop and restart the SMTP virtual server. On a cluster, you have to do this with the Cluster Administrator utility.

TELNET to port 25 on the server to test that the new banner is effective. You should see the default banner replaced by the string that you input into the metabase. Figure 9.5 demonstrates that the string input in Figure 9.4 has replaced the default banner.

Figure 9.5: The SMTP banner is successfully changed.

Remember that you must manually implement this change on every server that connects to the Internet before your SMTP network is prevented from offering information to potential hackers.

9.2.5 Installing Exchange servers in the DMZ

When you design your messaging infrastructure, you need to look at how to connect Exchange to the Internet. Large enterprises typically create a DMZ to isolate the internal network from the external network and place only the servers necessary to accept and transfer messages to and from the Internet into the DMZ. You have to decide whether to put an Exchange server into the DMZ and make it the first point of contact for incoming SMTP messages or use another option.

Many complex issues drive this choice, including the overall computing and messaging infrastructures, security, and antivirus and spam protection. However, the essential decision is whether to use Exchange or another mail server in the DMZ. Because Exchange relies so heavily on the AD, if you want to use Exchange, you have to open up additional ports in the internal- facing firewall to permit the Routing Engine to resolve email addresses and read configuration data. Reducing the number of open ports is important, because the less open ports you have, the less chance hackers have to exploit holes in the firewall. For this reason, many enterprises choose to install an SMTP relay host in the DMZ and keep all their Exchange servers in the internal network. The most common relay host configuration is one or more UNIX or Linux servers running software such as sendmail or postfix. An alternative approach is to create a special Exchange organization and AD forest for email routing and put it into the DMZ.

The relay server may take on several roles, including:

• Acting as the entry point for incoming SMTP messages

• Acting as the exit point for outgoing SMTP messages

• Acting as a block for incoming spam

• Acting as a block for incoming inappropriate messages or outgoing messages that may contain sensitive or commercially secret information

• Acting as a check to ensure that the intended recipient works for the company by validating email addresses against the enterprise directory

You can do all of these things with Exchange, so functionality is not the issue. If you want to deploy Exchange into the DMZ, make sure that you understand the consequences of maintaining the necessary open ports.

9.2.6 The ongoing role of the X.400 MTA

The Routing Engine now performs much of the work done by the MTA for first-generation Exchange servers. Table 9.3 compares the function served by the MTA in Exchange 5.5 with its current workload.

Table 9.3: Difference in MTA Roles between Exchange 5.5 and Exchange 2000/2003

MTA in Exchange 5.5	MTA in Exchange 2000/2003
Controls intrasite RPC message management	Routing groups replace sites as the basis for routing. Exchange uses SMTP to send messages between routing group members. The MTA is still responsible for controlling RPC communication to Exchange 5.5 servers in mixed-mode organizations.
Controls intersite traffic across site and X.400 connectors	The MTA can connect old Exchange sites to routing groups. You can also use an SMTP connector, which may be faster.
Determines message routing (the GWART)	Routing is determined by the link state table, which is managed by routing group masters. In a mixed-mode organization, the SRS provides data for inclusion into the GWART for Exchange 5.5 servers to use.
Manages connections to X.400 messaging systems (1984, 1988, 1993)	The MTA continues to manage connections to X.400- based messaging systems.
Manages Exchange Development Kit (EDK) connectors	The MTA still manages connections made by connectors built using the EDK. Most fax connectors fit in this category.

By default, Exchange allocates an X.400 address to every user with a mailbox. The X.400 address is critical within a mixed-mode organization, because older Exchange servers use the X.400 address to route messages to mailboxes. You should not delete the X.400 addresses from mailboxes unless you are positive that they will never be required again. Given that the addresses take up little space in the AD, it is best to leave them alone.

An Exchange organization that operates in native mode transmits all messages via SMTP, so you might assume that you can disable or remove the MTA from servers. However, while it is possible to remove the MTA, the ramifications for server operation are unpredictable, because Microsoft has not completely tested all possible scenarios for servers with a removed MTA. For this reason, while it would like to be able to run Exchange in a pure SMTP configuration, Microsoft does not support servers if you remove the MTA.

Over time, Exchange collected many different connectors, ranging from fax connectors to those that support other messaging systems. Microsoft never upgraded some of the older connectors to use SMTP, including its own IBM PROFS and IBM SNADS connectors, which are now obsoleted in Exchange 2003 along with connectors for Lotus cc:Mail, Microsoft Mail, and so on.

^[1] . Exchange looks for the "chunking" keyword in the response to its initial EHLO command. If the keyword exists, Exchange knows that the other SMTP server supports BDAT and is able to accept binary transmission.

^[2] . The Internet Mail Consortium maintains a chart comparing functionality of different SMTP servers. The chart is available at http://www.imc.org/features-chart.html.

^[3] . The mail drop directory for the default SMTP virtual server is \exchsrvr\mailroot\vs1\pickup. The directory is moved from the Windows default location when Exchange is installed on a server.

^[4] . Microsoft Knowledge Base article Q232068 explains how to download and install the MetaEdit utility.

---