Using MIXER for SMTP Internet Connectivity

Automatically route SMTP on X.400 over X.25

Many people who use SMTP and other messaging protocols based on the Internet Engineering Task Force (IETF) Request for Comments (RFC) 822 want to communicate with users on X.400-based systems. To make this communication possible, Exchange Server 5.5 Service Pack 3 (SP3) introduced the MIME Internet X.400 Enhanced Relay (MIXER) feature that RFC 2156 describes.

MIXER provides a method for mapping X.400 and RFC 822/MIME message formats, thereby improving communication between SMTP mail services (RFC 822/MIME and RFC 821-based protocols) and X.400 messaging systems. The MIXER functionality is most useful when you need to transport messages across a messaging backbone before Exchange eventually dispatches them to their final destination over an SMTP or X.400 gateway. MIXER ensures that the addresses that Exchange transports in the message header are correct when they reach the gateway.

MIXER Overview
The MIXER functionality lets you create an automatic gateway between X.400 and SMTP mail services without creating custom recipients to map SMTP and X.400 recipient addresses. The custom recipient strategy is valid when you have to map a finite number of addresses, but you can't use that strategy when the number of addresses is potentially infinite (e.g., when the destination domain is in the Internet).

MIXER supports three address-mapping types:

MIXER Components
To activate the Message Transfer Agent (MTA) MIXER feature on Exchange Server, you need the Exchange executable files included in SP3 (especially emsmta.exe and related DLLs), one Internet Mail Service (IMS) connector and one X.400 connector, two text files, and three new Registry values.

You must manually create the two text files (i.e., mcgam.in.txt and local.in.txt) in the MTA run directory (usually exchsrvrmtadata) to act as mapping tables for the MTA. In the mcgam.in.txt file, you specify mapping between X.400 addresses and SMTP and vice versa. For example, if you want to map the SMTP domain company.com to the X.400 address c=US; a= ; p=company, you must add the following strings in the mcgam.in.txt file:

company.com#prmd$company.admd$ .c$US#,

and the reverse

#prmd$company.admd$ .c$US#company.com

For each mapping set, you must add the appropriate mapping strings in this file. You must define algorithmic mappings for the SMTP domain that produces an invalid X.400 address when MIXER automatically maps the address. Moreover, you must consider how MIXER maps names (in the address) between SMTP and X.400 formats. The Microsoft article "XCON: User Name Mapping Issues When Implementing MTA MIXER" (http://support.microsoft.com/support/ kb/articles/q239/0/07.asp) explains the limitations of the MIXER address-mapping scheme. Finally, if you have several MIXER servers in your organization, you must distribute the same mcgam.in.txt file on these servers to ensure consistency.

In addition to the mappings in the mcgam.in.txt file, the local.in.txt file contains Registry mappings that you apply for specific MTA MIXER servers. The Microsoft article "XCON: Exchange Server Message Transfer Agent MIXER Mapping Tables" (http://support.microsoft.com/support/kb/articles/q238/5/07.asp) explains how you use the local.in.txt file settings to override the mcgam.in.txt mappings.

Mappings.out.txt is the output of the MTA MIXER for a given mcgam.in.txt file; the MTA creates this file when the MTA starts without errors. Mappings.out.txt contains the MIXER mapping table that the MTA is using. If the MTA starts successfully, you'll find the string New Tables Loaded at the beginning of this file.

You can modify three Registry values that affect mappings:

Installing and Configuring MIXER
The most important aspect of the installation is planning the mapping scheme that your mail system architecture requires. With successful planning, configuring an Exchange server to act as an MTA MIXER is easy. Follow these steps:

Encapsulating an SMTP message on an X.400 connector causes message conversion, which is a CPU-consuming process. MIXER supports a special configuration that improves performance when you use the encapsulation method. This configuration instructs the MTA to encapsulate the SMTP message in X.400 without performing any message format conversion. To use this method, don't create any mapping file (i.e., instead of using a blank mcgam.in.txt file) and don't create the Reload Mixer Table and Strict Mixer Conformance Registry keys. When MIXER encloses the SMTP message in the X.400 DDA field, the message will contain the DDA field SMTP:after address instead of the RFC-822:. This configuration improves performance as much as 22 percent.

In "XADM: Installing Exchange Service Message Transfer Agent MIXER" (http://support.microsoft.com/support/kb/articles/q238/5/06.asp), Microsoft recommends using MIXER on a server that has only one X.400 connector and one SMTP connector. Microsoft also recommends not using MIXER on a message journaling server or on a distribution list (DL) expansion server.

To improve system performance, remember that both X.400 and SMTP services generate a lot of disk I/O on the subsystem during message processing. Best practice is to use two RAID 0 volumes, and place the IMCDATA directory (IMS work areas) on one volume and the MTADATA directory on the other, possibly on two separate SCSI channels. Always use a dedicated Exchange server to reserve CPU for the message format conversion. If the X.400 connector uses an X.25 line, ensure that the X.25 link that you use has enough bandwidth for your environment: 256Kbps is a reasonable value in most environments.

Finally, install the post-SP3 Information Store (IS) patches that the Microsoft article "XADM: Exchange Server 5.5 Post-SP3 Information Store Fixes Available" (http://support.microsoft.com/support/kb/articles/q248/8/38.asp) cites. These patches fix crucial bugs related to the IS and to MTA behavior.

Using MIXER for Internet SMTP Connectivity
When I first discovered MIXER, I was interested in its primary application: improving interoperability between SMTP and X.400-based mail systems. Later, I realized that you can use MIXER features in other situations. Let's look at how you can use MIXER to create secure SMTP connectivity between the Internet and a private network that is completely closed to regular Internet access. In this situation, you need to break IP protocol continuity from the Internet to the internal network, which is a secure way to avoid potential malicious intrusions from the Internet. I use an X.25 WAN to connect the internal network to the demilitarized zone (DMZ—a computer host or small network that serves as a neutral zone between a company's private network and the outside public network), hosted by an ISP. In addition, I use firewalls to protect and filter access to the SMTP/X.25 gateway (the MIXER server), both internally and externally. You need an internal firewall, especially if you don't completely trust the X.25 provider. Figure 1 shows a diagram of this system's architecture and server names.

Because the SMTP connector can't use an X.25 link, you must use two Exchange X.400 connector servers, one at each end of the X.25 link. Both external (GtwExt) and internal (GtwInt) Exchange servers have an IMS connector, which acts as a MIXER server. In this scenario, the MIXER on GtwExt uses the encapsulating mapping method to provide an SMTP/X.400 gateway that automatically routes the SMTP/IP message to the X.400/X.25 connection, and vice versa. Here's the great benefit of using MIXER: Without it, you can't automatically route SMTP over X.400 connectors (and vice versa) without using custom recipients.

Finally, you place another Exchange IMS in the internal network (SMTPInt) and install it in the production Exchange site. You can use a mailbox server, but I suggest using a dedicated server.

Here are the most important steps for building the infrastructure, including the settings for each server involved. I assume that your SMTPExt server can receive from the Internet SMTP messages with the destination domain company.com, which is the SMTP domain of the internal Exchange site.

The SMTPExt server is an SMTP server that forwards to the GtwExt's IP address all messages that have the destination domain company.com and uses DNS resolution for foreign SMTP domains. This server doesn't have to be an Exchange server; it acts as a standard DMZ SMTP server.

You must configure the external firewall, FWExt, to allow SMTP communication between SMTPExt and GtwExt. Depending on your ISP's needs, you can configure the firewall to allow other communications between servers in the DMZ and the Internet.

GtwExt is the first MIXER server in the configuration. GtwExt encapsulates SMTP on the X.400 DDA field for inbound messages. Conversely, GtwExt unencapsulates SMTP from the X.400 field for outbound messages, forwarding these messages in SMTP format to the SMTPExt server. Because Exchange Server 5.5 runs only on a domain controller, you must set up the Windows NT server as a PDC. Furthermore, during the Exchange setup, you must create a new Exchange site that includes only the GtwExt server. Here's how you configure the server:

GtwInt is the second MIXER server in the group. The configuration is similar to GtwExt; the primary difference is in the MTA routing table. GtwInt uses the IMS to route messages to company.com and the X.400 connector to route messages to foreign SMTP domains. Like GtwExt, GtwInt is also a PDC NT server. Note these similarities and differences:

FWInt permits only SMTP between SMTPInt and GtwInt. SMTPInt is an Exchange server member of the internal Exchange site. Its SMTP connector receives incoming messages from GtwInt and forwards all messages to the GtwInt server's IP Address. So, you configure the Address Space as follows: Set the Type to SMTP, the Address to *, the Cost to 1, and the Scope to Organization. Optionally, you can add security restrictions that accept connections only from GtwInt.

I suggest that you always enable message-tracking options for all servers so that you can easily troubleshoot problems when they occur. Finally, I suggest that you back up MIXER servers once with an offline backup. You can use this backup whenever you need it, ensuring minimal downtime.

A New Internet Mail Possibility
MIXER lets you broaden your Internet mail capabilities. If your company needs to provide Internet mail to the user, the architecture I describe ensures a high level of security. MIXER might work for you.