Microsoft made great efforts to ensure that Exchange 2000 linked easily to popular e-mail systems. Exchange 2000 includes connectors for Lotus Notes, Lotus CC Mail, MS Mail, and to Novell’s GroupWise. However, if you’re attaching to any other mail system, you’ll have to use a generic connector, such as the SMTP or X.400. Although SMTP is very popular, sometimes you’re forced to use X.400 because the foreign system doesn’t support it. What do you do in such a case? In this Daily Drill Down, I’ll look at X.400 and how Exchange can use it to connect to other mail systems.

Why use X.400?
One of your main purposes in choosing a connector is to facilitate an exchange of directory information between two mail systems. By its very nature, the X.400 protocol conveys an object’s location within the directory structure. Why is this important and why would you want to use X.400 to begin with? And if both systems already support Internet-based e-mail, then why is it even necessary to link the systems together? Why not just allow the mail to flow between the two systems by passing through the Internet as it presently does?

There are three reasons for linking the systems together using X.400. First, when you link an Exchange server to a foreign mail system via one of the supplied connectors, you can perform directory synchronization, which means that Exchange becomes aware of the mailboxes that exist within the foreign mail system and vice versa. This makes it possible for your users to easily create distribution lists that include mailboxes on the remote mail system.

Second, once the two mail systems are linked and their directories have been synchronized, you can migrate from one mail system to the other. For example, you could migrate Lotus Notes servers into an Exchange environment.

Finally, in many situations, you can conserve bandwidth. The link can be set to direct traffic destined for the foreign mail system along a specific path and at specific times or intervals.

Also, SMTP is the native Exchange 2000 messaging format and is usually the preferred choice; however, there are some mail systems that simply don’t support SMTP. Many commercial e-mail systems instead run X.400. In such cases, using an X.400 connector may be your only option. Mail systems that use X.400 instead of SMTP include:

  • AT&T StarPRO Enterprise Messaging
  • Alcatel 4300L PABX
  • Alcatel NET400 No E-mail
  • Data General AV/400
  • Dispatcher/MacX.400
  • HP X.400 OpenMail Encyclopedia
  • MacX.400
  • NET-TEL Route400

Another reason to use X.400 might be because the organization you’re connecting to requires you to use it. For example, X.400 is especially popular in Europe because SMTP doesn’t support French-language diacritics. Likewise, the Canadian federal government has adopted X.400 as the communications protocol of choice between government institutions.

X.400 also has additional features that make it a better choice than SMTP in many situations. These features include:

  • Notifications—X.400 can provide notifications to the sender to let him or her know that the message has been successfully delivered. SMTP only tells you when a message fails to go through. Additionally, X.400 can automatically include receipt notifications. SMTP mimics this functionality with the return receipt function, but it’s not the same thing.
  • Security—X.400 addresses aren’t as spoofable as SMTP addresses because the sender information is certified. Additionally, X.400 is fully traceable ensuring the path that the message travels is valid.
  • Speed—The X.400 standards dictate that 95 percent of all mail be delivered within 45 minutes. Additionally, X.400 allows you to set priority markers. This means that you can schedule more important messages to go before lower priority ones. Traditional SMTP mailers send everything at once.
  • Efficiency—Because X.400 transmits messages in a binary format, it’s more efficient. This is especially true when transmitting attachments because SMTP messages transmit in text and use Uuencode or Base64 to transmit attachments, which causes the overall message size to be larger.

The anatomy of X.400
Looking at X.400, you might find it a bit intimidating. That’s understandable, because even though X.400 is known as a “standard,” sometimes it seems like there’s nothing standard about it. For example, depending on the mail system you use, an X.400 address might look something like this: c=US;a=;p=PoseyEnterprises;o=SouthCarolina;s=Posey;g=Brien. Alternatively, it could look something like this: /C=US/ADMD= /PRMD=PoseyEnterprises/O-SouthCarolina/G=Posey/S=Brien.

An X.400 address contains a lot of information, especially when compared to the SMTP addresses that most of us are accustomed to looking at, such as brien@brienposey.com. The structure behind an X.400 address is actually quite logical, though. Notice that an X.400 address is composed of letters followed by an equal sign (=), a value, and a semicolon (;) or slash (/).

The letters within an X.400 address and the values that they represent convey a directory location by working from left to right, from the least specific information to the most specific information. For example, in the address above, which is bogus by the way, the C stands for country. In that example, the country is set to U.S. The next value is A, which stands for the administrative management domain. Administrative management domains represent public e-mail message services such as ATTmail and MCImail. The next component of the address, P, represents the private management domain. If you’ve always worked in an Exchange environment, a private management domain may sound foreign to you; however, its equivalent is an Exchange organization. So the X.400 address shown above implies that I named my Exchange organization PoseyEnterprises. However, just because the private management domain often matches the Exchange organization name, it isn’t required to. You can actually use any value in the private management domain address component that you want.

The next component, O, represents the X.400 organization. Don’t confuse the X.400 organization with the Exchange organization, because they are completely different. The Exchange organization is reflected as the private management domain. The X.400 organization actually corresponds to the Exchange administrative group.

The last two components of the X.400 address are the S and the G. The S stands for surname and should contain the user’s last name. The G stands for given name, or the user’s first name.

Connecting to a foreign mail system
Now that you understand the anatomy of an X.400 address, it’s time to take a look at the actual process of connecting the Exchange organization to the foreign mail system. Unfortunately, I can’t give you a procedure for configuring the foreign mail system because we are dealing with a theoretical mail system rather than with a specific product. There are so many different e-mail systems that support X.400, there’s no way to easily come up with a generic set of procedures.

What I can tell you though is that an X.400 connector must be configured manually on both sides of the link, so check your target e-mail system to see how to configure X.400 for it. By understanding the Exchange configuration process and the anatomy of an X.400 address, you may be able to figure out how to configure the connector on the foreign mail system with minimal difficulty.

There are several steps you must go through to configure Exchange 2000 to support X.400. These steps include:

  • Selecting the bridgehead server
  • Creating an MTA transport stack
  • Creating the X.400 connector
  • Fine-tuning X.400

For the purposes of this Daily Drill Down, I’ll briefly discuss the required steps. In an upcoming article, I’ll go into the details about how to configure the MTA Transport stack and the connector. With the following information, you’ll be able to plan your X.400 connection.

Selecting the bridgehead server
The first step in setting up an X.400 connector in an Exchange 2000 environment is to select a server on which to place the connector. Remember that Exchange uses the concept of bridgehead servers to facilitate communications between sites and between e-mail systems. When using an X.400 connector, the bridgehead server is usually the only server in the Exchange organization that contains a link to the foreign mail system, although it’s possible to have multiple bridgeheads to create resilience.

So if users with mailboxes on other Exchange servers needed to send a message to someone with a mailbox on the foreign mail system, the message would travel through the Exchange organization to the bridgehead server and then to the foreign mail system. Likewise, any messages that are sent from the foreign mail system to Exchange mailboxes are initially sent to the bridgehead server and are then distributed to their final destination within the Exchange organization.

But how do you know which server to designate as the X.400 bridgehead? First, look at the physical connection between the Exchange organization and the foreign mail system. If one of the Exchange servers happens to be on the same LAN as the foreign mail system, that server is the obvious choice.

Most of the time, though, you won’t be lucky enough to have such a clear choice. Instead, you’ll have to consider other factors. For example, some administrators prefer to use a single server to handle all of the bridgehead functions, which means a single Exchange server could potentially act as a bridgehead server for communication between the Internet, and a foreign messaging system.

Unless you happen to have a dedicated bridgehead server with no mailboxes or public folders, the only real advantage to using this technique is that it makes things more organized. Of course the flip side is that if you assign all bridgehead functions to a single server and something goes wrong with that server, each site is cut off from the rest of the organization and from the world.

Another common approach is to select the Exchange server with the lightest workload. Remember that the bridgehead server has a big job to do and requires a substantial amount of power to perform all the necessary translations and routing. If you’re interested in using this method, but aren’t sure which Exchange Server has the lightest workload, I recommend using the Performance Monitor. Specifically, you should be testing the server’s processor, hard disk, and memory utilization. There are countless other factors that you can test, but my experience has shown that testing these three components will give you a fairly accurate picture of overall system performance.

Creating the MTA stack
Once you’ve selected a bridgehead server, you should next create an MTA transport stack, which is the component that tells Exchange how the connector should interact with the physical network. The MTA transport stack is created at the server level and should be built on the server you’ve selected to be your bridgehead server.

If you’ve ever used Exchange 5.5 or 5.0, you may recall that you could create a connector without having to create a separate underlying MTA transport stack beyond the default MTA. However, Exchange 2000 requires that you separately create the connector and the MTA transport stack.

So why the additional level of complexity? Remember that Exchange 2000 contains an organizational component that didn’t exist in previous versions of Exchange: routing groups. The MTA transport stack exists at the server level, but the actual X.400 connector resides in the routing-group level. So if necessary, you can use multiple MTA transport stacks and/or multiple X.400 connectors to implement fault tolerance and load balancing. What this all boils down to is that it’s possible for you to create multiple routes to the foreign mail system. By doing so, you can ensure that data still flows between the two systems, even if your primary bridgehead server fails.

Creating and fine-tuning the connector
Once you’ve created the MTA transport stack, you’re free to create the actual X.400 connector. In Exchange, a connector performs the same basic task that gateways typically perform in other mail systems. The connector routes traffic to and from the Exchange environment and translates the mail traffic.

There are actually two different uses for X.400 connectors. First, obviously, you can use an X.400 connector to link Exchange 2000 to a foreign mail system. But you can also use X.400 connectors as a communications mechanism between two Exchange 2000 routing groups. However, Microsoft recommends in both the Exchange 2000 help files and in the Exchange 2000 Server Resource Kit that you refrain from using X.400 connectors between routing groups unless you have an extreme lack of bandwidth. Several Exchange-related Web sites suggest that you should only consider using an X.400 connector if your available bandwidth between the routing groups is below 16 Kbps.

Conclusion
Although SMTP is the preferred connector for linking Exchange 2000 to foreign mail systems that it doesn’t directly support, not every foreign mail system supports SMTP. In such cases, knowing how to set up Exchange to connect to the foreign system via X.400 will come in handy.