Sending Messages -- Routing and Transport

Windows IT Pro

- Advertise

Sending Messages -- Routing and Transport
View the book table of contents

Author:	Tony Redmond
Published:	October 2000
Copyright:	2001
Publisher:	Digital Press

Windows 2000 and SMTP
The SMTP transport in Exchange 2000 is not based on the IMS as shipped in Exchange 5.5. In fact, the SMTP transport uses a completely different code base to the IMS and owes a large part of its heritage to the SMTP transport delivered in MCIS 2.0 and IIS 4.0. Performance and scalability are very important to an ISP mail system, so Exchange 2000 has inherited some major performance enhancements in its SMTP capability over the IMS and indeed MCIS. The most important of these are:

Pipelining: The ability to issue many commands without waiting for their acknowledgement, in the knowledge that the acknowledgements will eventually arrive in the same order that they are issued. SMTP was originally defined in RFC821, which states that an acknowledgement (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, which is defined in RFC 2197, avoids the overhead of waiting for command acknowledgements, 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.
DSN (Delivery Status Notification): The ability to tell you whether a message has been delivered successfully. Exchange 2000 supports delivery status notifications as defined in RFC 1891, 1892, and 1894. These replace the esoteric and often obscure non-delivery notifications generated by the Exchange 5.5 IMS. Parsing of DSN data is done to ensure that MAPI clients continue to receive the same type of delivery notifications they have in the past, while Internet clients receive notifications as defined in the RFCs. Figure 1 is an example of a delivery service notification for a message sent to an invalid recipient (mailbox not found), as viewed from Outlook Express. Figure 2 shows the same notification as seen from Outlook 2000. Note that the Outlook 2000 version comes from the System Administrator rather than the postmaster and offers the chance to the user to send the message again.
Chunking, or BDAT: Normally, the content portion of SMTP messages is sent in the form of one or more DATA statements. Each statement (or line) is terminated with a CR/LF, full stop/CR/LF sequence. This implementation is acceptable for small text-based messages, but less so 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).

BDAT (or binary data transfer) is defined in RFC 1830 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 messages to be sent and received very much more quickly than using the DATA command. Exchange 2000 servers always attempt to use BDAT after they have created outbound connections to another SMTP server. If the other server cannot support BDAT³, the connection is automatically downgraded to use the standard DATA command. A connection from Exchange 2000 to Exchange 2000 always uses BDAT. Together with the streaming file, chunking allows Exchange 2000 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 acknowledgements and checkpoints as large messages are passed across the wire. Opening up a connection and streaming data until an agreed point is reached allows more data to be transferred faster.

In addition to these commands, the basic Windows 2000 SMTP service (and therefore Exchange) support⁴:

VRFY (RFC 821): verify or ensure that the message can be delivered to a local recipient.
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 or not 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 authentication mechanism with a server. As shown in Figure 3, Exchange 2000 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.

      The list of commands may vary in the future with support packs and updates to both Windows 2000 and Exchange 2000. 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 3. As an exercise, you can issue the same command to an Exchange 5.5 server to discover the set of new ESMTP commands supported by Exchange 2000.

      Note that the commands listed by a particular server may not be the complete set. For example, the server queried in Figure 3 does not list the STARTTLS or TLS commands because a certificate is not available for the server to use to encrypt traffic.

      Table 1 lists the major differences between SMTP support in Exchange 5.5 and Exchange 2000. The most important difference is that SMTP is now at the heart of Exchange instead of being provided as an add-on connector.

      Windows 2000 and Exchange 2000 both depend heavily on SMTP to transport messages between servers. Indeed, the Exchange development group provides the code for CDONTS, which is shipped in every Windows 2000 server as part of IIS. The basic functionality in Windows 2000 is similar to that in many UNIX servers and can be described as a “no frills” messaging server. It does not include the capability to send messages between mailboxes. Instead, the SMTP functions provide Windows 2000 and other products with a well-known transport that can carry information between applications. The best example of this is inter-site AD replication, although doubtless there will be other examples created in the future.

      SMTP is installed by default with Windows 2000 Server, Advanced Server, and Datacenter edition. A modified form of the transport is installed with Windows 2000 Professional, but don’t expect to do any messaging with it. Only a single virtual server instance is supported on Windows 2000 Professional, and many of the extended SMTP commands are not enabled.

      SMTP is managed through the MMC snap-in for IIS, and its configuration data is held in the IIS metabase. The service runs in the INETINFO process, in the same manner as all the other protocols supported by IIS. Interestingly, Exchange configuration data is held in the AD, so a background process managed by the System Attendant is used to synchronize the AD with the IIS metabase. The same situation is true for all protocols and is a side effect of Exchange partitioning protocol support off to IIS.

      The base SMTP service supports many of the extended functions defined by ESMTP as well as virtual servers and scripting. The scripting capability is gained through CDO V2.0, which allows applications to create and submit messages through VBscript code. Messages can also be submitted through the standard SMTP listener port (25), or applications can generate text messages in SMTP format and submit them for processing by placing them in the SMTP drop directory⁵. No management capabilities are available. The service is so basic that it functions on the basis that SMTP either works and messages can be created or sent, or it doesn’t and the SMTP service must be restarted to correct matters.

      When Exchange 2000 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. The upgrade is accomplished through new a new event sink and some transport and protocol events that allow SMTP messages to flow into the Store via ExIFS. The net effect is to upgrade the CDO support from V2.0 to V3.0. The most important difference between the two CDO libraries is that CDO V3.0 (also called CDO for Exchange) understands mailboxes whereas CDO V2.0 doesn’t. Transport events extend the function of the transport core while protocol events extend the SMTP protocol.

      The point has already been made several times that Exchange 2000 and Windows 2000 enjoy a very close relationship. 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 from Figure 4. Inter-dependencies mean that you have to be careful when you manage components. For example, you shouldn’t reinstall the SMTP service from the Windows 2000 distribution without also reinstalling Exchange.

SMTP Virtual Servers
The SMTP protocol in both Windows 2000 and Exchange 2000 supports the notion of virtual servers for the protocols supported through IIS. This is a major difference to Exchange 5.5, which binds its protocol access to specific ports. Once bound, the protocol 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. Exchange 2000 defines a virtual server to be a combination of a protocol and port number. The default virtual server for SMTP is therefore a combination of SMTP and port 25, and all SMTP traffic is channeled through port 25. The default virtual server for HTTP is composed of HTTP and port 80, and so on.

      A virtual server can be configured or bound to all IP addresses, in which case it is able to process messages coming from any address, or it can be bound to a specific set of addresses, in which case it is only able to process messages generated to those specific IP addresses. The default is to have a single virtual server that listens to port 25 for incoming messages from anywhere.

      When Exchange 5.5 is upgraded to Exchange 2000, the default SMTP virtual server takes over the role played by the Internet Mail Service (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 configuration that might be deployed if you wanted 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 non-urgent personal Internet mail services such as hotmail.com, msdn.com, aol.com, and so on. The connector can be configured with a schedule to pass messages outside normal business hours, so that messages sent to commercial destinations receive a higher priority.

      Settings applied to a virtual SMTP server are respected by any of the connectors that use that virtual server. The settings can be viewed and altered by selecting the virtual server you want to work with from the SMTP container in the protocols section of an administrative group. Use right-click to access the properties of the virtual server, and then navigate to the place you want to check or change. Like the IMS, many different properties affect the way the server works. Some of the properties are exposed through advanced options on the different pages. Figure 5 shows one of the more common operations — changing the data that the server logs as connections are made. The default location for log files is \WINNT\SYSTEM32\LOGFILES\SMTPSVCx where “x” is the number of the server that you want to work with. The default SMTP virtual server takes number 1. Unlike the IMS, you do not have to restart a virtual server or connector before a change to a property is effected. Changes are signaled as events that the servers recognize and action, so the effect of making a change to a server’s properties is almost immediate.

Relays
The default SMTP virtual server is the basic building block for the Routing Group and SMTP connectors, the two major ways to link Exchange 2000 servers together. You don’t 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. Outgoing messages can be sent using another port, but you have to ask yourself what you want to add any more complexity to your administrative environment than you already have? Separate virtual servers are usually only configured to handle messages sent to different domains, or when you want to handle messages above a certain size or of a particular priority.

      Table 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’s 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 that all connections were secured through TLS. 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. In this situation, creating an extra virtual server and dedicating it for relay work is a good example of how Exchange 2000 is far more flexible than previous versions. Remember that the address space must be clearly defined for each virtual server, even for a virtual server set up to handle purely internal mail. The virtual server doesn’t know that mail is sent to an internal addressee — it must be told by having the address space set with the value of internal SMTP addresses.

      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 they are intended for, such as allowing SMTP clients like Outlook Express to send messages. The Internet is a great place, but it has some seedy quarters and practices. The people who engage in spamming, where large quantities of unwanted commercial e-mail are sent to clutter up mailboxes, often use systems as an intermediate relay to disguise where the messages are being generated. You may not realize that your system has been “borrowed” by spammers unless you receive complaints about e-mail that you know hasn’t come from one of your users, or you see sudden spikes in system load caused by an external program that sends thousands of messages. You can defend your system by restricting its capability to relay. By default (Figure 6), only Exchange 2000 servers that connect to other Exchange 2000 servers are able to relay messages. This may not be what you want, as you may want to support the transmission of messages from other non-Exchange servers, so review the situation and make whatever adjustments you think are necessary to secure your systems.

To test whether your system can be used as a relay, issue the following commands from a DOS prompt.

TELNET
IP address 25
HELO (or EHLO) 
MAIL FROM: Bill.Gates@Microsoft.com 
RCPT TO: Your address 
DATA 
I think
you have done an incredible job with Exchange 2000. Well done! 

Bill

³ Exchange 2000 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.

⁴ 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

⁵ By default, the mail drop directory is \exchsrvr\mailroot\pickup. The directory is moved from the Windows 2000 default location when Exchange 2000 is installed on a server.

Page: 1, 2, 3, 4, 5, 6, 7, 8

ADS BY GOOGLE