Many thousands of Exchange Server organizations worldwide still run Exchange Server 5.5, which continues to serve its masters (both users and administrators) well. One of the product's most powerful components is the Internet Mail Service (IMS), which connects Exchange 5.5 to the world of SMTP and Internet mail. However, few administrators fully use the IMS's ability to perform sophisticated forms of address mapping and rewriting, despite its usefulness. Organizations that maintain multiple email environments—especially organizations that are in the midst of migrating to Exchange 2000 Server—can use the Exchange 5.5 IMS as an effective mail switch.
Inbound Addressing
When your organization maintains multiple email environments—Exchange 2000, Exchange 5.5, Lotus Notes, and UNIX mail, for example—you can use an Exchange 5.5 server as a mail switch and Internet gateway. This standalone server (i.e., one that exists in a separate Exchange organization, unconnected to any other Exchange server) can accept incoming messages from an external source—typically the Internet—then route those messages to the destination email system that hosts the recipient's mailbox. Figure 1 shows an example of this type of environment.
Most companies don't like to publicize their internal addressing structure. Also, although addressing structures that contain system-specific information can help identify the messaging system to which to route a message, these structures tend to complicate addresses (and generally make them ugly). Therefore, most organizations settle on a flat addressing structure, along the lines of firstname.lastname@organization.com, for public use. In the environment that Figure 1 shows, the public address for the email user Douglas Corrigan—[email protected]—follows this format. However, when messages addressed to [email protected] reach the Exchange 5.5 mail switch, the IMS converts them to a private format—[email protected], [email protected], or [email protected]—that the IMS then uses for internal routing. This private format is never exposed outside of the internal email environment. The primary reason is simple: Having a consistent, well-defined public email-addressing structure means that email routing must be insulated from any internal system or domain-name changes. The secondary reason is that public email addresses should be aesthetically pleasing and look good on a business card, as well as be easy to spell and remember.
Even internal email systems can benefit from public email-addressing structures, which let you build resilient backbone environments to which you can connect all your email systems. When you use these structures, internal users can always email their colleagues through a public address and be confident that, somewhere on the backbone, that address will resolve to an expanded form that's suitable for routing and the recipient will receive the message.
Using the Exchange 5.5 IMS to perform this kind of public-to-private address translation is simple. Effectively, the mail switch in our example performs the following high-level operations:
- accepts inbound mail for firstname.lastname@wwairways.com
- looks up a directory service that maps firstname.lastname@wwairways.com to an internal address format (e.g., lastnamefirstinitial@e2k.wwairways.com)
- relays the original message, with the rewritten recipient address, to the target email system
To perform these tasks, Exchange 5.5 uses custom recipients. A custom recipient is simply a means of giving an external recipient an alias in the Exchange 5.5 Directory Service (DS). In other words, a custom recipient supplies a mapping between a user's display name and public (i.e., external) email address.
In our example, you need to create a custom recipient for Douglas Corrigan, then configure that recipient to map to the SMTP alias [email protected]. However, our whole point in having a custom recipient is to forward email to another email system, so you also need to configure the recipient with a second, internal alias—[email protected]—as Figure 2 shows. (Note that an uppercase "SMTP" specifies the primary SMTP address, whereas a lowercase "smtp" specifies a proxy or alias.)
Use Microsoft Exchange Administrator to configure these address values. The order in which you list these addresses is irrelevant and has no effect on inbound address rewriting. The actual rewrite address is specified by the custom recipient's target email address, which you configure in the E-mail field on the General tab of the custom recipient object's Properties dialog box, as Figure 3 shows. When the IMS on the Exchange 5.5 mail switch receives a message addressed to [email protected], the IMS determines that the message is destined for the custom recipient Douglas Corrigan, then immediately reroutes the message to the recipient's specified target email address (i.e., [email protected]).
Outbound Addressing
Using the Exchange 5.5 IMS as a mail switch for inbound traffic is straightforward. Rewriting addresses for outbound email, however, can be more complex.
In the simplest approach, which Figure 4 shows, the originating internal email system is an Exchange 2000 or Exchange 5.5 system. Therefore, you can use Exchange's built-in ability to have multiple SMTP aliases but use one as a primary alias or Reply address. (You can use the Microsoft Management Console—MMC—Active Directory Users and Computers snap-in or Exchange Administrator to set the Reply address in Exchange 2000 or Exchange 5.5, respectively.) The user's Exchange 2000 mailbox receives email addressed to [email protected] by virtue of the secondary SMTP alias; the mail switch rewrites the public address to this internal address. However, any email that originates from the user automatically uses the SMTP Reply (aka originator) address [email protected].
However, if you plan to use the Exchange 5.5 IMS as a true mail switch, you want the mail switch itself to rewrite the originator address. For example, suppose that in the more complex, multimail system scenario that Figure 1 shows, a UNIX mail user wants to send a message to an Internet recipient. In this case, rewriting the originator address at the mail switch is easier than configuring the rewrite at the source email system. Thus, when a message leaves the UNIX mail system, the originator address is in the private form [email protected]. When the message reaches the Exchange 5.5 mail switch, the IMS must rewrite that address to the public form [email protected], as Figure 5 shows.
So, how does the IMS perform this rewrite? Let's assume that Douglas Corrigan is a UNIX mail user. The custom recipient needs two associated SMTP aliases: the primary, public SMTP alias SMTP: [email protected] and the secondary, internal SMTP address smtp: [email protected]. As I explained earlier, the order of these aliases is irrelevant when you're dealing with inbound email-address rewriting, which simply needs to identify a user that matches the inbound message's recipient address. However, the addresses' respective values are important to outbound originator-address rewriting. These values tell the IMS that when it processes email for which the originator address is [email protected], it needs to rewrite that address as [email protected] as the message leaves the Exchange IMS Connector. Along with configuring these aliases, you also need to manipulate a couple of registry settings.
First, go to the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIMC\Parameters registry subkey and set the AddressRewrite entry (of type REG_DWORD) to 1. (Create the entry if it isn't present.) This setting tells the Exchange 5.5 IMS to use the values for the SMTP primary and secondary aliases to rewrite the message's RFC-821 From header. (This header is the originator's address on the envelope part of an SMTP message. Chances are you won't ever see this header unless you look at an SMTP log file.)
Then, set the ResolveP2 entry (of type REG_DWORD) to 64 to rewrite the RFC-822 From field (the field that shows in message headers). Setting the value to 64 resolves only the RFC-822 From field, but you can also rewrite several other header fields if they're present; set the value to rewrite all these headers. (The Microsoft article "XFOR: ResolveP2 Registry Setting Expanded in Exchange 5.5," Q174755, http://support.microsoft.com, describes the possible values.) In a typical Exchange 5.5 environment (i.e., one that hosts mailbox users rather than one that serves only as a mail switch), setting the ResolveP2 registry to any nonzero value has an interesting effect. When incoming email for a local Exchange mailbox recipient passes through the Exchange 5.5 IMS, the IMS checks for the presence of a custom recipient for the message originator. If the IMS finds such a recipient, it overrides the sender's Personal Name and SMTP address, which the message would usually display, and instead shows the custom recipient's Display name. If you maintain many custom recipients for external users, you can set the ResolveP2 value and modify the external users' sender addresses so that they're more aesthetically pleasing.
When Exchange resolves the RFC-822 From field, two rewrites actually take place. The IMS rewrites the SMTP-style originator address with the values you specified for the SMTP primary alias and rewrites the RFC-822 Personal Name or From field with the custom recipient's Display name value. Exchange processes many fields when it parses message headers. As well as rewriting the originator address, Exchange also rewrites sideways recipients, rewriting any addresses in the To or Cc fields to replace private addresses with public addresses.
During Migrations
The IMS's mail-switching functionality is also particularly useful during migration from an Exchange 5.5 environment to an Exchange 2000 environment. A common approach to such migrations is to build a completely separate Exchange 2000 organization—that is, to perform a true interorganizational migration. In a simple environment, you might be able to use the Active Directory Connector (ADC) in interorganization mode and simply represent Exchange 2000 users as custom recipients in the Exchange 5.5 DS. But in complex environments (e.g., in which you have multiple Exchange 5.5 organizations, in which you're migrating to multiple Exchange 2000 organizations), a good practice is to have one mail hub that can accept all inbound Internet email and make intelligent and appropriate email-routing and address-rewriting decisions. In these circumstances, the model that Figure 1 shows is indispensable.
Of course, the downside to this model is that you need to maintain the Exchange 5.5 DS with custom recipients for all email users across all the email systems in your environment. Typically, however, this requirement isn't as challenging as it might seem and is merely a matter of synchronizing directories among multiple email systems.
The mail switch's associated Exchange 5.5 DS effectively becomes a central directory hub that you can easily use to ensure unique SMTP addresses across the whole internal email environment. Many directory-synchronization products, including Hewlett-Packard's HP LDAP Directory Synchronizer (LDSU) and Microsoft Metadirectory Services (MMS), are available. However, both LDSU and MMS are expensive, enterprise-scale products that require a relatively high degree of configuration.
Alternatively, you can use a little scripting, Windows 2000's built-in Csvde or Ldifde utilities, and Comma Separated Value (CSV) or Lightweight Directory Access Protocol (LDAP) Data Interchange Format (LDIF) files to roll out your own directory-synchronization tool. (See http://msdn.microsoft.com for information about developing such scripts.)
Make the Switch
When the demands of your organization require a mail switching hub, inbound and outbound address rewriting, or a centralized naming and addressing service, the Exchange 5.5 IMS can be a powerful and simple solution. In an upcoming article, I'll explain how you can use Exchange 2000 to achieve similar results.
