9.10 Creating an X.400 connector

 < Day Day Up > 



With all the focus on SMTP, you might assume that an Exchange administrator would never have to create an X.400 connector again. This may well be the case in many companies, especially those in the United States, where SMTP links have always been more popular. The largest constituency for X.400 connectivity remains companies that operate X.400-based backbones that integrate many different messaging systems. In addition, some companies use the X.400 connector to link multiple Exchange organizations together, especially when the organizations are of different vintage.

Many administrators regarded the X.400 connector as one of the more complex components in previous versions of Exchange. This is an unfair label, and it is largely because the X.400 connector had more property pages than either the Site or the SMTP connectors. The truth is that you can safely ignore the majority of the pages if you want to set up a connection between Exchange sites or organizations or link to an X.400 backbone (including the X.400 service offered by large service providers such as AT&T). The X.400 connector offers more opportunity to tune the way that connections are established and operated, but that is no reason to consider it complex.

To illustrate how easy it is to create an X.400 connector, let us look at the steps required to set up an X.400 connector to link Exchange to an Exchange 5.5 organization. While SMTP is the easiest way to link Exchange 2000/2003 to Exchange 5.5, it may be the case that you want to operate a scheduled connection (on both sides), and X.400 is able to offer this facility.

Figure 9.37 illustrates the general properties of the X.400 connector. The important items here are:

  • The name of the remote MTA: This is usually the name of the remote bridgehead server that you want to connect to. Unlike the RGC or SMTP connectors, you can only define a single bridgehead server for each side of an X.400 connection. However, you can install multiple X.400 connections within a routing group to provide fault tolerance if the server that hosts the primary connection fails.

  • A password for the remote MTA: Usually blank, unless you wish to secure the connection by forcing each MTA to authenticate itself to its partner by exchanging passwords each time the MTA attempts to make a connection. Note that the password is sent in plain text.

  • Message text word wrap: Since this connection is going to another Exchange organization, it is safe to send messages without forcing lines to wrap at a set position. Older X.400 systems (usually those that support the 1984 X.400 recommendations) may insist that each line is wrapped at column 75 or 78, or another value.

  • Remote clients support MAPI: Again, since the connection is going to an Exchange 5.5 organization, we can expect that any client that connects to the servers will understand MAPI, or the server will provide the client with a translated version of the messages (as in the case of POP3, IMAP, or OWA).

  • Do not allow public folder referrals: If the X.400 connector is used to link routing groups together in the same Exchange organization (including a mixed-mode organization), it is safe to allow public folder referrals to flow across the connector. However, in this case we are using the X.400 connector to link two different Exchange organizations, one of which is running Exchange 5.5. You cannot share public folders between two different organizations, so the checkbox is completed.

click to expand
Figure 9.37: General properties of an X.400 connector.

The X.400 transport stack defines the method used to establish the X.400 link and the server that will act as the bridgehead. Most X.400 connections within the Exchange community flow across a TCP/IP link, although we could equally use an X.25 dial-up link. The details of how X.400 works across a TCP/IP link can be found in RFC 2126 (an update to RFC 1006), which defines how OSI software can connect over IP (messages are routed through port 102). X.25 dial-up links are usually confined to situations where a telephone connection is the only possible link. In these circumstances a dial-up SMTP connection, either direct to a central hub or via a connection managed by an ISP, is now a better option. SMTP supports authentication and encryption, whereas X.400 only supports basic authentication (MTA passwords), and, as we have seen, SMTP is the way of the future, so it's best to move if at all possible.

You must configure a suitable transport stack on a server before it can support an X.400 connector. Figure 9.38 shows how to begin the process of configuring a new stack. The properties of the stack are very simple and merely require you to provide a name for the new object plus values for the TSAP, SSAP, and PSAP used in OSI address information. TSAP, SSAP, and PSAP stand for Transport, Session, and Presentation access points and represent the different points within the OSI model used by the X.400 connector. This is a real opportunity to make things complex. You can keep things simple by specifying blank values, which means that incoming MTAs can also specify blank values when they make a connection, or you can complicate matters by playing around with different hex and text values in each access point. Of course, you are much more secure now, because you have created a situation where incoming MTAs absolutely must be able to pass the required access point information before a connection is established. This is sometimes required, especially when communicating with X.400 backbones, but if you're only going to communicate with other Exchange servers you should use blank values. Over the years, there has been more frustration and bad words spoken during attempts to make Exchange servers talk to each other across X.400 connections. Normally, the reason is that the MTAs have mismatching access points. Life is too short to get involved in such situations.

click to expand
Figure 9.38: Installing a new X.400 transport stack.

Figure 9.39 illustrates the properties defined in the Stack page. We define two major pieces of data here. First, you need to specify either the name of the host server you want to connect to or its IP address. It is best practice to use the fully qualified domain name of the host server, since this allows the IP address to be changed if necessary. Just to prove that I do not always follow best practices, I have used the IP address here. This is safe to do if you are sure that the address is unlikely to change. Using the IP address offers a major advantage in that connectivity can still be established if DNS is unavailable to resolve the host name. However, if DNS is unavailable, your Windows 2000 infrastructure will be experiencing some major problems of its own, and sending email across an X.400 connector is likely to be one of the lower-priority items on an administrator's to-do list.

click to expand
Figure 9.39: Setting stack properties for an X.400 connector.

The OSI address information can be entered in hex or text format. Computers and some people understand hex well enough to be able to accurately interpret data entered in hex, but I don't and can't be bothered to work it out, so I take the easy option and go for text and then leave the values blank whenever possible. You can enter outgoing and incoming OSI information for the TSAP, SSAP, and PSAP selectors. Exchange sends the outgoing information to the remote MTA when it establishes the connection, while the local MTA expects the remote MTA to provide the specified OSI data when an incoming connection is initiated. If the information does not match expectations, the connection will be determined. Between Exchange servers there is no real need to specify OSI selector information, so it's best to leave these fields blank. Connecting to other X.400 systems may require you to know the OSI selectors the remote MTA will broadcast, so be sure to find out this information before you set up the connector.

All Exchange connectors specify an address space. The address space determines how messages are routed to the connector. In the case of the X.400 connector, we need to define what X.400 addresses can be handled by the connector. The routing core will then send any message it finds that matches the address space to the connector. Figure 9.40 shows two screens. The left-hand screen lists all of the address spaces defined for the connector, while the right-hand screen shows how an address space is defined. In this case, the definition means that any message with an X.400 address starting with:

C=IE;A=;P=compaq;O=Dublin

click to expand
Figure 9.40: Defining an address space for an X.400 connector.

will be routed through the connector. Most users do not know (and do not want to) how to generate X.400 addresses, but it is useful to know how so that you can send a test message to an address on the other side of the connection to make sure that everything works. Using a MAPI client, you can enter an X.400 address by enclosing it in square brackets and prefixing the address with X400, as follows:

[X400: C=IE;A=;P=Compaq;O=Dublin;S=Redmond;G=Tony]

Be careful with blank values. In the previous example, the A (administrative domain) part of the address is blank, meaning that no value is passed at all. In some situations, a single space character may represent a "blank," and you might have to test several variations of address formats before you determine the correct format.

Figure 9.41 shows the advanced properties of our X.400 connector. These properties are easy to determine when you connect to another Exchange server, since you can accept the default values. However, when you connect to a foreign X.400 system, you will have to know what the other system supports.

click to expand
Figure 9.41: Advanced properties of an X.400 connector.

"Allow BP-15" means that the remote MTA supports bodypart-15, which means that Exchange can send file names instead of an X.400 OID (object identifier) for each attachment. In other words, if you send a Word attachment, the message header includes file name information such as "document1.doc" instead of a binary value. Most modern X.400 systems support BP-15. Note that the responsibility for interpreting the file names and processing the attachment with the correct application lies with the client, not the MTA, so clients that attach to the receiving MTA must be able to understand the file names that Exchange will send.

"Allow Exchange contents" means that the message will contain MAPI content (header properties, message text, and attachments). If the clients attached to the remote MTA understand MAPI, you can check this box.

"Two-way alternate" means that the two MTAs can send and receive messages alternatively. Some older MTAs can only accept or send messages in a connection. IA5 is the most common encoding scheme used for text bodyparts. Older X.400 systems may support the 1984 recommendations. However, these systems are rare now, and you will normally find that the remote system supports 1988 mode.

The values used to configure X.400 connectors in first-generation Exchange are the same as those required now. If you already have X.400 connectors in use, they should continue to function perfectly after you upgrade.

9.10.1 Deciding when to use an X.400 connection

The X.400 connector is just one of the options that you can use to connect Exchange servers together, or to connect Exchange to another messaging system. The question is when should you use an X.400 connector? Here are a few scenarios that call for the X.400 connector:

  • An enterprise uses a well-established X.400 backbone to link diverse messaging systems together. The temptation may exist to move to an SMTP backbone, but the other messaging systems may not support the same level of rich SMTP extensions as Exchange. On the other hand, because X.400 has been in use since 1984, it is probable that systems now in use support a rich set of features, as defined in the 1988 or 1992 X.400 recommendations. In this case, it is best to operate on the basis that you should not fix something that is not broken and continue to use the existing backbone. As new versions of the other messaging systems become available that might support extended SMTP, you can test their interoperability with Exchange and decide whether the time has come to move to a new backbone. Similarly, you may want to connect to a public email service that uses X.400. Most public systems now offer SMTP, but there are a few (reducing all the time) that still rely on X.400.

  • The bandwidth available between routing groups is 16 Kbps or less. The Advanced properties page for an X.400 connector allows you to tune how messages are transmitted to achieve a finer degree of control than is possible with the SMTP or RG connectors. Fine control becomes very important when bandwidth is low.

  • No technical reason might exist, but your organization may decide that X.400 is the preferred protocol for connections. This might come about because system administrators are more familiar and comfortable with X.400 and still believe that SMTP is only for simple messaging, or a decision taken some time ago to use X.400 is still in place and you have not yet had the chance to review the role of SMTP in your messaging interoperability strategy.

It is possible that SMTP will experience problems for some reason, such as a smart host server failing. In this case, you can configure X.400 connectors to communicate stating IP addresses for servers (rather than FQDNs), disable the SMTP connectors, and force the Routing Engine to channel messages across the X.400 connectors. This can be a short-term workaround to avoid messages building on queues, which proves that it is always useful to have multiple ways to solve a problem or, in this case, to route messages.

One esoteric but important point is that Exchange does not support the X.400 MIXER (RFC 2156) functionality (Exchange 5.5 offers this support). MIXER allows full mapping of SMTP and X.400 for recipients and originator addresses in the envelope (P1) and content (P2) of a message. If you need this functionality to communicate with an X.400 email system, you will have to maintain an Exchange 5.5 SP3 (or later) server in the organization until the requirement disappears. Despite the charge toward Internet protocols, X.400 will be in use for some time yet. SMTP will eventually win in the battle of the messaging protocols, but achieving final victory for the SMTP camp will be a long, drawn-out affair.

Finally, the MTACHECK utility is still around and supported for Exchange 2000 and 2003. MTACHECK validates the MTA's internal database that it uses to track messages and ensures that all necessary files are available.



 < Day Day Up > 



Microsoft Exchange Server 2003
Microsoft Exchange Server 2003 Administrators Pocket Consultant
ISBN: 0735619786
EAN: 2147483647
Year: 2003
Pages: 188

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net