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 Willie.Nelson@us.cantaz.com. 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 Johnny.Cash@cantaz.com. 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 Johnny.Cash@cantaz.com, 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 Johnny.Cash@eu.cantaz.com, 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 Johnny.Cash@cantaz.com to Johnny.Cash@eu.cantaz.com 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.