Many modern companies of all sizes have operations in two or more countries and often have multiple points of connection to the Internet from their internal networks. Such companies typically use these points of connection as ingress and egress points for email flowing to and from their internal Exchange Server environment. Routing outbound email through the egress point that's geographically nearest the sender is typically a straightforward matter of using routing groups and connector costs (as the sidebar "Optimizing Outbound Email Flow" explains). Intelligently routing inbound email through an ingress point that's geographically near the intended recipient is more difficult. However, you can implement such a routing mechanism by using basic Exchange Server 2003 features.
Using Namespace Design to Optimize Inbound Email Flow
The simplest mechanism for optimizing inbound email traffic is to have some component of the email address indicate the geographic location to which a message should be routed while still on the Internet. For example, suppose that US-based employee Willie Nelson has the email address [email protected]. To optimize inbound email flow, publish a DNS MX record such that all messages that have the address component us.cantaz.com will be directed to the US mail relay mailrelay.us.cantaz.com. By doing so, email sent to Willie will be routed to him over the most efficient path to the SMTP connector geographically nearest him. Typically, this MX record will include the other ingress points as higher cost relays so that a failure at the lowest cost ingress point won't prevent successful mail delivery. (However, be aware that rerouting to a higher cost relay because of a failure causes mail routing to be suboptimal in terms of resource usage.) Similarly, each of the other location-specific MX records would be configured with backup mail-relay servers through the other locations.
Figure 1 shows an example of how such location-specific email addresses and MX records resolve to the most appropriate email relay. This form of mail routing is efficient because it causes messages to traverse the shortest span of the internal network and thus consume the least amount of internal bandwidth.
Using Address Redirection to Optimizing Inbound Email Flow
Optimizing inbound mail flow by using location-specific email addresses is efficient but doesn't provide an aesthetically pleasing email address or present a consistent email-address format for the company. Furthermore, most companies don't want email addresses to signify location; rather, a normalized or flat email address (e.g., cantaz.com) is usually preferred. Flat email addresses provide no mechanism to intelligently route the message to a specific geographic location.
To work with flat address spaces, you can use address redirection such that an SMTP relay accepts email at an ingress point, rewrites the address to a location-specific form, then reroutes the email back to the Internet for intelligent delivery to the appropriate location. Figure 2 shows such a mechanism. In this example, an email message is sent to user Johnny Cash at the flat address [email protected]. The MX record that handles the cantaz.com SMTP domain directs all mail for the domain to the US-based SMTP relay gatekeeper.us.cantaz.com. When gatekeeper.us.cantaz.com processes newly received email for [email protected], it determines that the user isn't hosted in the United States but rather in Europe, by using a routing table lookup to a directory of some form. Accordingly, gatekeeper.us.cantaz.com rewrites the recipient email address on the message, changing cantaz.com to eu.cantaz.com. The message, now addressed to [email protected], is delivered to another SMTP relay, gatekeeper.eu.cantaz.com, thanks to the MX record for eu.cantaz.com. Upon receipt of the message, gatekeeper.eu.cantaz.com delivers the message to the intended recipient.
Creating the Appropriate Network Infrastructure
The architecture that Figure 2 shows relies on several factors to ensure successful operation. One of these key factors is that mail received in one geographical location but bound for another geographical location isn't simply rerouted to the other location but is rerouted through an Internet connection.
The whole point of implementing an intelligent email routing architecture is to move load away from the internal mail systems so that email ultimately destined for a particular geographical location is routed there using the fewest possible internal resources. In the previous example, the SMTP relay (i.e., gatekeeper.us.cantaz.com) that changes the recipient's email address from [email protected] to [email protected] isn't part of the Exchange organization. If no address rewrite took place, the US Exchange organization would simply accept the message, then use the internal Exchange network to transmit the message to the appropriate European mailbox server. The message would travel across routing groups and Routing Group Connector (RGC) servers. By just rewriting the address and relying on an internal MX record to direct email to the internal European SMTP mail relay, the message is routed efficiently (to some degree) and there is reduced load and congestion within the Exchange organization. However, this approach still incurs load on internal network links because the message has been accepted into the company's network and is still being rerouted over internal trans-Atlantic network connections. So the approach I've just described represents some improvements to email rerouting, but there are still possibilities for further improvement. Rerouting messages via the Internet prevents a load from being incurred on internal trans-Atlantic network links. You can easily achieve such a preferred rerouting path, as Figure 3 shows, by configuring the MX record for eu.cantaz.com to resolve to a hostname that is accessible only over the Internet and never via internal network circuits.
For the sake of simplicity, my example presumes that all mail to the cantaz.com domain has a single ingress point: the gatekeeper.us.cantaz.com SMTP mail relay. But what if there are two gatekeepers: one in the US domain and one in the European domain? If 50 percent of all mail to the cantaz.com domain is bound for the United States and 50 percent is bound for Europe, then mail to the cantaz.com domain can be load-shared across the gatekeeper.us.cantaz.com and gatekeeper.eu.cantaz.com relays by using equal cost MX records, for the purpose of resilience. The gatekeeper.eu.cantaz.com SMTP mail relay would perform address rewrites for email that it receives but that is bound for US recipients, rewriting cantaz.com as us.cantaz.com and redirecting the email back out across the Internet and directly to the gatekeeper.us.cantaz.com SMTP mail relay.
However, if 70 percent of all mail to cantaz.com is bound for the United States and only 30 percent is bound for Europe, then such a load-shared mechanism is inappropriate. In such a case, 35 percent of all received mail will be redirected from Europe to the United States and 15 percent of all received mail will be redirected from the United States to Europe; thus, 50 percent of all mail must be redirected. If mail for cantaz.com isn't load-shared and is received only by the gatekeeper.us.cantaz.com relay, then only 30 percent of all received email will be subject to redirection. The figures I've quoted are merely for purposes of illustration. Actual implementations of SMTP mailers vary in the ways that they handle MX record costs so the actual percentages of mail that is rerouted could be more or less than the figure I've described. Whereas load-sharing in this example clearly isn't desirable, it still makes sense to have a lower preference MX record for cantaz.com resolve to gatekeeper.eu.cantaz.com so that a complete failure of gatekeeper.us.cantaz.com won't stop mail flow into the company. Therefore, for intelligent and efficient email routing, it makes sense to analyze existing mail-flow patterns to determine incoming email's ultimate destination, then appropriately configure and set costs on MX records.
Successfully Rewriting Email Addresses
Rerouting email along an optimal path by using a preferred SMTP relay is the simple part of our intelligent routing scenario and relies on fairly straightforward MX-record and SMTP configurations. The biggest challenge is implementing and maintaining a system that will accept messages and rewrite their addresses as required.
Many SMTP Message Transfer Agents (MTAs) are available (the freeware product Postfix and Process Software's PMDF come to mind), and most facilitate the processing of SMTP messages in conjunction with directory lookups and address (i.e., header) rewrites. You can also use Exchange 2003's Exchange Address Rewrite Tool (aka Exarcfg). You can download Exarcfg, which is part of the Exchange 2003 release to Web (RTW) toolset, at http://www.microsoft.com/exchange/downloads/2003/default.mspx. After downloading the exarcfg.exe executable, run it to create an Exarcfg folder containing the configuration utility (also called exarcfg.exe), a license agreement file, and documentation.
You can run Exarcfg from an administrative account on any system (not necessarily an Exchange server) in the same Active Directory (AD) forest that contains the Exchange system on which you want to perform address rewrites. To run the Exarcfg tool successfully the account from which you execute the tool must be a member of the Local Administrators group on the Exchange server and should have administrative permissions on the Exchange organization. In our example scenario, gatekeeper.us.cantaz.com resides in its own Exchange organization—and thus its own forest. This is necessary because the user objects specified in the rewrite environment will take part in the address-rewriting process, and the nature of the email addresses will be different from the email addresses specified in the Exchange organization that contains the user mailboxes. In essence, gatekeeper.us.cantaz.com simply performs an SMTP processing function and has no particular relationship with the Exchange organization that hosts the eventual recipient's mailbox. This separation of relay systems from the target Exchange organization is important: Without such separation, the address-rewriting and email-rerouting functionality can't be implemented.
To establish address-rewriting capability on the SMTP mail relay system, you first must enable the address-rewriting function on that system. To do so, open a command prompt and (on one line) execute the command
exarcfg -e -s: <server> -v: <vsi>
where the -e parameter tells Exarcfg to enable address rewriting; the -s parameter specifies the server on which you want to enable it, with server being the server's Fully Qualified Domain Name (FQDN); and the -v parameter specifies an SMTP virtual server, with vsi being the actual virtual server instance (typically 1, for the default virtual server instance). Thus, to enable address rewriting on the US SMTP mail relay server's default SMTP virtual server instance, use the command
exarcfg -e -s: gatekeeper.us.cantaz.com -v: 1
Exarcfg also supports an -l parameter that lists the current settings for a given server and a -d parameter that disables address rewriting on a given server. When you use the -l parameter, if you don't also use the -s parameter to specify a server, Exarcfg returns the current settings for all servers in the domain.
Running Exarcfg sets the last bit on the specified Exchange server's heuristics attribute, so you can achieve the same functionality on an SMTP mail relay system by using ADSI Edit and navigating to DC=com, DC=cantaz, CN=Configuration, CN=Services\CN=Microsoft Exchange,CN=cantaz\CN=Administrative Groups, CN=relay, CN=Servers\CN=gatekeeper,CN=Protocols,CN=SMTP,CN=1; selecting the heuristics attribute, and changing its default value (131072) to 131073.
After you enable the address rewrite functionality on an Exchange server, all messages that the SMTP service accepts in a relay capacity have their SMTP addresses changed by the Transport service. The Exchange server must find either a corresponding mail-enabled contact or a mail-enabled user object with the local AD (not the target Exchange organization's AD). The corresponding object must have a secondary SMTP proxy address that matches the message's current SMTP address, and the object's primary SMTP address must represent the rerouted SMTP address. In our sample environment, gatekeeper.us.cantaz.com receives messages addressed to [email protected] and the rewrites the address to [email protected]. Figure 4 shows the AD object that facilitates this address rewriting.
When the address rewrite takes place, the SMTP relay system reroutes the message back to the Internet, where the message is delivered to gatekeeper.eu.cantaz.com. This European SMTP mail relay, which typically is in a separate Exchange organization (although it can be in the same organization as the US SMTP mail relay), performs no address rewriting but simply forwards the message to an SMTP bridgehead server in the target Exchange organization. The user object that represents the Exchange mailbox for the recipient has two SMTP addresses: the location-specific email address must be a secondary SMTP proxy address so that the message can be delivered, but the primary SMTP address must be the normalized SMTP address, as Figure 5 shows. Thus, the primary and secondary SMTP addresses between the rewrite object and the actual user object are mirror images of each other. You will need to configure appropriate recipient policies so that the Exchange organization will accept all required email addresses.
Get Smart
The challenges of optimizing inbound mail flow have been historically difficult to resolve without using an awkward addressing format. However, with Exchange 2003—and some planning and configuration—you can intelligently route incoming Internet email. However, you must maintain the necessary configuration, which can be somewhat sophisticated. At the very least, you'll need to maintain two Exchange organizations: one for your users and one for your address-rewrite objects. You'll need to keep the directories between these two environments in constant synchronization to prevent interruptions to mail delivery. There are many tools that you can use to perform this synchronization, including Microsoft Identity Integration Server (MIIS); a Google search for directory synchronization tools will reveal many more options. And you'll need to configure your organization's MX records to control mail flow. Therefore, I suggest that you first establish a definite need for address rerouting. To do so, you need to analyze existing traffic-flow patterns to determine whether the savings on network traversal warrant the configuration overhead. In multinational organizations, rerouting often makes a lot of sense. Your mileage will vary, but you might find that you can recapture international bandwidth that you can then use for other purposes or even reduce costs by simply reducing the bandwidth on those circuits. If you're already near saturation point, implementing an intelligent email routing system will almost certainly free up precious network resources and improve mail delivery times.
