Address Rewriting in Exchange Server 2003

Many situations benefit from address-rewriting technology. In short, address rewriting lets a server map one address to another. A simple example would be changing an internal address to a public-facing address, such as changing [email protected] to [email protected], when a user sends a message from within a company to a recipient on the Internet. Similarly, as a message arrives from the Internet addressed to a public-facing address (e.g., [email protected]), it would be readdressed to an internal address (e.g., [email protected]). This type of technology is conspicuously absent from Exchange 2000 Server, forcing us to make do with a border SMTP service, such as sendmail or Postfix, or to fall back on the Exchange Server 5.5 Internet Mail Service (IMS) and its RerouteViaStore registry setting (as the Microsoft article "XIMS: How to Force SMTP Messages Through the Information Store" at http://support.microsoft.com/?kbid=238471 describes). I'm happy to report, however, that the technology is part of Exchange Server 2003, so you can set up and use this handy new feature in your Exchange 2003 environment.

The Scenario
The most obvious situation in which you can benefit from address-rewriting technology is when one company merges with or acquires another company. After such a merger, the companies need to appear as one entity. Having a common email address across companies and potentially across email systems and Exchange organizations is one aspect of presenting a unified front. Address-rewriting functionality offers a solution in this environment.

Let's build a fictitious scenario to use as an example of such a situation. A consulting company called Top Feeder has purchased its rival, Bottom Feeder. Top Feeder's IT staff has decided that all email entering or exiting either company will traverse the Top Feeder Exchange 2003 environment. This environment is represented by the SMTP domain, top.tst. Because the two companies need to present one external presence from a messaging standpoint, all Bottom Feeder users must be addressable through a top.tst address even though email is actually delivered to their native environment, bottom.tst. For this setup to work properly, a naming convention must be in place to avoid naming conflicts. Figure 1 shows a graphical representation of the scenario.

To better understand the scenario, let's examine what occurs when a user called Bottom1 in the Bottom Feeder organization sends a message over the Internet. When Bottom1 sends a message, the From field will have an address of [email protected]. Because all messages to the Internet will traverse top.tst, and because the appearance of one messaging domain is desired, Bottom1's address needs to be rewritten so that the From field contains [email protected]. When the recipient replies to the message, the reply needs to route back through top.tst to the bottom.tst environment. For this process to work successfully, you need to create a contact for the user [email protected] in the top.tst Active Directory (AD), assign the contact certain attributes, then configure Exchange to take advantage of those attributes and rewrite the addresses.

To prepare your systems to take advantage of Exchange 2003's address-rewriting feature, begin with the following steps:

Now, when Bottom1 sends email over the Internet, the message will go to [email protected] and have a From field that contains [email protected]. The top.tst and bottom.tst forests are connected through an SMTP connector. The connector on the bottom.tst bridgehead has an address space of "*" and forwards all messages to an Exchange 2003 SMTP Virtual Server in the top.tst forest.

The bridgehead server in top.tst looks up all recipients in the From, To, and CC fields of the message. If the recipients are in the bridgehead server's local AD, the bridgehead server rewrites the addresses to match their primary SMTP address. After performing the address rewrite, the bridgehead forwards the message to the Internet through an appropriately configured connector.

When the recipient receives the message, the From field now contains the rewritten address [email protected], as Figure 4 shows. When the recipient replies, the message returns to the top.tst bridgehead. The bridgehead performs a directory lookup, determines that the target address is [email protected], and forwards the message through the appropriate connector. In this case, the connector is a bridgehead server in top.tst, configured with an SMTP address of @bottom.tst and pointing to a bridgehead server in the bottom.tst organization.

The address-rewrite feature, when enabled, works both when an externally submitted SMTP message arrives at a bridgehead server and when a Bottom Feeder user sends a message through the Top Feeder bridgehead to the Internet. Originating addresses for internal mail for the hosting organization (i.e., top.tst) going out to the Internet or for internal mail staying within the organization (i.e., mail between top.tst and bottom.tst) don't need to be rewritten; those messages will skip address rewrite on the bridgehead server or servers. The only exception to this rule is when an email client such as Microsoft Outlook Express, Netscape, or QUALCOMM Eudora submits a message. These messages will undergo address rewrite on the bridgehead server, assuming the clients use the rewrite-enabled bridgehead as their SMTP server.

This new feature rewrites addresses only for messages coming from the partner or subsidiary company and going out to the Internet. The feature doesn't perform or permit extensive token replacement, as sendmail or other third-party products do.

Enable Exchange Address Rewriting
By default, Exchange 2003 disables address rewriting on all SMTP Virtual Servers. Enabling address-rewrite functionality requires manipulation of an AD attribute on the SMTP Virtual Servers on which you want to perform address rewriting. After you enable the address-rewrite feature, Exchange rewrites message header information (defined in Internet Engineering Task Force—IETF—Request for Comments—RFC—822 as the From, Reply-To, and Sender data) with the respective contacts' primary SMTP addresses. This means that you must first set the primary SMTP proxy for every contact for which you want rewrites to take place. Tools such as HP's LDAP Directory Synchronization Utility (LDSU) or Microsoft Identity Integration Server (MIIS) 2003 make this setting easy to automate for entire organizations.

On its Web site, Microsoft recently provided a tool called exarcfg.exe, which lets you more easily enable or disable address rewriting; the tool will likely be available in Exchange 2003 Service Pack 1 (SP1). Unless you have the tool, you need to manually configure the rewrite feature as follows:

Address Rewriting and Content Changes
Address-rewrite operations involve pushing the message to the Exchange Store, invalidating the existing MIME format, and forcing a MIME­to­Messaging API (MAPI) conversion. A consequence of this conversion is that the message changes to MAPI format, so the transport protocol must rerender the message's format before the message goes out across the Internet. The transport renders the message according to the matching Internet Message Format (IMF) of the recipient's domain or, if the recipient is a contact, based on the contact's personal content setting (personal content settings override IMF settings). However, the transport isn't RFC 822­content clairvoyant, meaning that even if no address rewrite is required, the above operations still happen. So the content is rerendered even if the message has From and To addresses that don't need rewriting, as in the case of addresses that don't have equivalent contacts or mailboxes in the rewrite domain or addresses that already match their primary SMTP proxies in the rewrite domain. The bottom line is that all SMTP mail submitted by the subsidiary Exchange organization or environment will go through this address-rewrite and message-conversion process. Test your environment extensively to ensure that this behavior causes no problems.

One last note about address rewriting: A performance hit occurs on the Exchange Server whose SMTP Virtual Server performs rewrites. No specific numbers are available to show how large the performance degradation is, but you'll want to monitor performance after you enable the feature to determine the effect.

A Little Preparation
Exchange 2003's address-rewriting technology works great and is easy to implement. All you need is a simple AD attribute change on the appropriate SMTP Virtual Server and the appropriate contact creation between the routing-and-rewriting Exchange organization and the subsidiary environments. Address-rewriting functionality is valuable in multiforest and multiorganization Exchange 2003 deployments as well as in environments for which Exchange is the primary entry point to and from the Internet.