MTA Transport Stacks and X.400 Connectors

 

The X.400 standard is based on the Open Systems Interconnection (OSI) reference model as defined in the X.200 recommendation. The Exchange MTA contains code for the top four layers of the OSI stack (that is, application, presentation, session, and transport). Below the OSI transport layer, the MTA relies on drivers installed in the operating system.

The OSI reference model is made up of seven layers, as illustrated in the following figure.

ITU standards in the OSI reference model

As indicated in this figure, the TCP/IP protocol does not fit exactly into the OSI stack. This is because the TCP/IP protocol, although a layered protocol stack, is not OSI- compliant (although most elements of TCP/IP can be mapped to OSI). TCP/IP was originally developed by the Advanced Research Projects Agency (ARPA), based on a four-layer model, called the TCP/IP model (sometimes called the Internet model). To support X.400 communication over TCP/IP according to the OSI standard, the Exchange MTA implements a Transport Protocol Class 0 (TP0) interface on top of TCP/IP, as defined in RFC 1006.

The Exchange MTA can also use RPCs as a transport mechanism to communicate with LAN-MTAs and XAPI gateways. RPCs represent a communication mechanism at the application layer, because the RPC runtime library includes presentation and session services. However, in the context of the MTA stack, RPCs implement an interface under the session layer. The internal services of the RPC runtime are transparent to the MTA.

The X.25 protocol is an OSI-compliant protocol designed specifically for wide area network (WAN) connections on packet-switching networks (such as a public X.400 provider). The MTA transport interfaces directly with the X.25 protocol, because X.25 has a Transport Class 0 (TP0) protocol interface to the transport layer. On the OSI side of the data link layer, X.25 relies on the High-level Data Link Control - Link Access Procedure Balanced (HDLC - LAPB) protocol. HDLC - LAPB is the protocol that the EICON X.25 card uses to communicate with the synchronous modem that connects the server to the public X.25 network. X.25 is the network protocol that operates on top of HDLC so that the local system can communicate with the next node in the X.25 network. Exchange supports EICON X.25 cards only.

Message Transfer Service

The XFER IN and XFER OUT threads in the MTA process, depicted earlier in this section, initiate the message transfer service of the MTA. The Message Transfer Service Element (MTSE) uses the Reliable Transfer Service Element (RTSE) to send messages across a connection to a remote MTA and the Association Control Service Elements (ACSE) to establish and disconnect connections.

The messages that MTSEs exchange with each other are named P1 messages to indicate their format. The P1 protocol defines the format of a message transfer envelope. The envelope contains the actual message, plus routing and control fields, so that the MTSEs can route and trace a message, and track message contents. The following figure illustrates an example of a P1 message transfer envelope in the Aspirin tool. Aspirin is an ASN.1 parser that you can find in the Exchange 2000 Server Resource Kit (available in bookstores). In X.400, data is formatted using ASN.1 syntax.

A P1 message transfer envelope

The actual message is in the X400COM_Content part of the P1 envelope. The message is usually formatted according to the P2/P22 protocol, which describes the format for interpersonal messages. Exchange MTAs support other message formats, such as P772 and P42 for military messages. The following table lists the message formats that the Exchange MTA supports. However, it should be noted that not all of these formats conform to the X.400 standard. Some message formats are Exchange Server-specific.

Supported message formats in Exchange Server 2003

Format	Content Type	Object Identifier
MDBEF	Microsoft Database Encoding Format (MDBEF). Microsoft-defined and registered content type. Also referred to as "MS Exchange Contents." Does not conform to X.400. Can only be used between Exchange MTAs in the same organization.	2A864886F7140501
Public Folder MDBEF	Microsoft-defined content type for public folder replication messages. Does not conform to X.400. Can only be used between Exchange MTAs in the same organization.	2A864886F7140502
P2	Defined in X.400 of the 1984 conformance year. Defines the format of an interpersonal message (IPM).	56010A00
P22	Defined in X.400 of the 1988 conformance year. Extends the format of an interpersonal message (IPM), as defined in X.400-84.	56010A01
P772	Military message. Extends the P22 protocol with extensions defined for Defense Message System (DMS) in "Allied Communication Publication (ACP) 123." These extensions (additional properties) are allowed by the X.400 standard and are typically only exposed by DMS-capable clients, and STANAG 4406 v1.7 and v3 clients.	2B1A00A236000401
P42	Secure military message. Military message that has been digitally signed, encrypted, or signed and encrypted using Message Security Protocol version 3 (MSP3) (encryption only is not allowed within DMS). Certificates are X.509 and analogous to an S/MIME V1. Also referred to as "MSP3."	60864801650201022A
CSP	Common security protocol. Used within DMS to define a secure military message. Military message that has been digitally signed, or signed and encrypted using Message Security Protocol version 4 (MSP4). Certificates are X.509 and analogous to an S/MIME V3. Within the DMS Program this is referred to as "ACP120" or "MSP4."	608648016502010203
TNEF	Transport Neutral Encoding Format (TNEF). Microsoft-defined and registered content type. Also referred to as "MAPI." Conforms to X.400 because the message and all its attachments are encapsulated and attached to the message itself as a binary attachment. The receiving client must be able to decode TNEF, otherwise the client displays a useless attachment called Winmail.dat. For a detailed discussion of TNEF, see SMTP Transport Architecture.	2A864886F7140502

The following figure illustrates how the P1 and P2 protocols map to the architecture of Exchange Server 2003.

Envelope and message protocols

Reliable Transfer Service

When the MTSE wants to send a message to another MTA, it uses the Reliable Transfer Service Interface (RTSI) to call the RTSE. The MTA contains a state machine that decides which data packets to send through the RTSE. The RTSE then sends the packets. For example, the MTA issues an RT_TRANSFER_REQUEST to the RTSE and the RTSE then attempts to transfer the given message to the other MTA. After the message is sent, the RTSE returns an RT_TRANSFER_CONFIRMED to the MTSE, so that the MTA can mark the message as transferred. Details of the state machines are given in X.228.

The RTSE provides reliable data transfer by transforming the data into a string of octets. It then breaks the string into segments named application protocol data units (APDUs), and then hands each APDU to the presentation layer for delivery. The RTSE ensures that APDUs arrive intact, without duplication, when they are transferred between MTAs. When a connection is interrupted for any reason, the RTSE is responsible for retrying data transfer. The RTSE supports smart recovery between APDUs by establishing checkpoints. Checkpoints enable the RTSE to resume the APDU transfer at the point where the disruption occurred, rather than retransmitting the entire APDU. Activity and minor synchronization facilities of the session layer support interruption and possible resumption of data transfer, if the underlying network connection is lost.

The services offered by RTSE fall into the following three categories:

• Association establishment   An association is a logical connection between two MTAs that is used for the purpose of message transfer over a physical connection. MTAs can establish multiple associations over a single physical connection to send multiple messages concurrently. The RTSE uses an RT-OPEN REQUEST (RTORQ) APDU to establish an association. An RT-OPEN-ACCEPT (RTOAC) APDU is used in a positive response to the request to establish an association between two MTAs. On the other hand, an RT-OPEN-REJECT (RTORJ) APDU is used in a negative response to the request to establish an association.

• Data transfer   The RTSE uses RT-TRANSFER APDUs for data transfer. The dialog may be one-way or two-way alternate, depending on whether data is transferred only from one MTA or in both directions by turns. Each association, over a two-way alternate link, has a turn token that only one MTA can possess at a time. When an MTA must send a message, but does not have the turn on an open association, it must determine how many open associations are on the link. If there are fewer than eight associations, the MTA attempts to open a new association on which it has the turn. If there are already eight associations open, the MTA sends an RT_TURN_PLEASE request over one of the associations. If the receiving MTA can release the turn, it sends back an RT_TURN_GIVE response and the requesting MTA is allowed to transfer the message. If the receiving MTA cannot release the turn, it simply does not respond until it is ready to release the turn. In a two-way alternate communication, the RTSE can use RT-TURN-PLEASE and RT-TURN-GIVE APDUs to switch data transfer directions, as follows:

  • RT-TURN-PLEASE   If an MTA has the turn and receives an RT-TURN-PLEASE request from the other MTA, the MTA issues a P-TOKEN-PLEASE request primitive, so that the requesting MTA can become the sending MTA. RT_TURN_PLEASE requests can have different priorities, which relate to the priority of the message. Priority 0 is reserved for when an MTA wants to shut down an association or when an MTA wants to send routing information.

  • RT-TURN-GIVE   If an MTA has the turn and receives an RT-TURN-GIVE request primitive from a requesting MTA, it issues a P-CONTROL-GIVE request primitive and becomes the receiving MTA.

• Association termination   The RTSE uses RT-CLOSE, RT-U-ABORT, and RT-P-ABORT APDUs for ending of an association, as follows:

  • RT-CLOSE   An RTSE may issue an RT-CLOSE request when it has the turn and if there are no outstanding RT-TRANSFER confirmations. When the RTSE receives an RT-CLOSE response, the RTSE issues an A-RELEASE packet to end the association.

  • RT-U-ABORT   This is an MTA-initiated cancellation, which is triggered when the MTA wishes to cancel an association. For example, an MTA of the 1984 conformance year can cancel an association if the other MTA overtaxes the MTA by using X.400 features of the 1988 conformance year.

  • RT-P-ABORT   This is a provider-initiated cancellation of an association, which is triggered when recovery from a communication failure is not possible. For example, receiving data packets in invalid states (such as sending an APDU without first establishing an association) leads to an RT-P-ABORT.

The Exchange MTA uses an RTS thread pool to handle the RTSE level of the OSI stack. You can control the number of RTS threads using the following registry parameter.

Location	HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\ MSExchangeMTA\Parameters
Value	RTS threads
Type	REG_DWORD
Value Data	0x1
Description	Determines the number of RTS threads. The default value is 0x1. The recommended value is 0x3 if this MTA communicates with multiple MTAs, either within a routing group or between routing groups. Note If the RTS threads setting is too high, RTS threads might overload other threads in the OSI stack, thus causing a message transfer slowdown.

Association Control Service

The Association Control Service Element (ACSE) is a component of every connection-oriented application entity in the OSI model (such as an X.400 MTA) that must establish an application-to-application (MTA to MTA) association for data transfer over a connection. An association establishes a context for the communication between the MTAs. For example, if one MTA process sends data to the other MTA, the other MTA must be able to interpret the data and respond correctly. MTAs can establish multiple associations over a single physical connection to transfer multiple messages concurrently.

ACSE offers two types of services to the RTSE:

• Association establishment   Association establishment is provided by the A-ASSOCIATE service.

• Association termination   Association termination is provided by three services:

  • A-RELEASE   This is the normal release mechanism used to end an association.

  • A-ABORT   This is an unconfirmed (abrupt) cancellation of an association.

  • A-P-ABORT   This is an unconfirmed (abrupt) cancellation of an association similar to A-ABORT. The difference is that A-P-ABORT indicates to the remote MTA that the association has been broken by service providers at lower OSI layers.

Each connection between two MTAs can have up to ten associations, and because each association is effectively a conversation, up to ten messages can be sent simultaneously over a single X.400 connector. Two of the ten associations are reserved for sending urgent messages. Each MTA holds the turn on one of the two associations and never releases the turn. If a remote MTA attempts to establish more than eight concurrent associations for messages with normal priority, the Exchange MTA refuses the additional associations and logs an event with the event ID 58 in the application event log. The following is an example of this event:

Event Type: Warning

Event Source: MSExchangeMTA

Event Category: X.400 Service

Event ID: 58

Date: 04/01/2004

Time: 4:27:34 AM

User: N/A

Computer: SERVER01

Description:

The /O=TAILSPIN TOYS/OU=FIRST ADMINISTRATIVE GROUP/CN=CONFIGURATION/CN=SERVERS/CN=

SERVER01/CN=MICROSOFT MTA entity has reached the per-entity receive association limit of 8, equal to 80 percent of the total 10. [MTA XFER-IN 36 34] (12)

Presentation and Session Services

The presentation service provider provides the RTSE with a basic data transfer service to deliver RT-TRANSFER APDUs to remote MTAs. The presentation service provider packs the APDUs from the higher level to presentation protocol data units (PPDUs), and the service provider at the session layer adds further information to the data packets to create valid session protocol data units (SPDUs).

The first information sent over the presentation layer is a P-ACTIVITY-START indication. If the message is large, the MTA might have to send more than one P-DATA packet. P-DATA packets are not confirmed by the receiving MTA, so the sending MTA also sends P-MINOR-SYNCHRONIZE indications between the P-DATA packets. The receiving MTA confirms the minor sync points using P-MINOR-SYNCHRONIZE confirm primitives. However, minor sync points do not have to be confirmed immediately. There is a window size that sets how many minor sync points can be outstanding at any time. After the entire message has been transferred, a P-ACTIVITY-END request is sent. When the receiving MTA confirms the P-ACTIVITY-END, the RTSE passes a RT_TRANSFER_CONFIRMED primitive back to the MTA, and the MTA marks the recipients as processed.

This transfer procedure is driven by the following events in the presentation layer:

1. RT-TRANSFER request.

2. P-ACTIVITY-START indication, followed by one or more P-DATA packets each, except for the last, which is followed by a P-MINOR-SYNCHRONIZE indication.

3. P-MINOR-SYNCHRONIZE confirmation.

4. P-ACTIVITY-END indication.

5. P-ACTIVITY-END confirmation.

The RTSE also requires synchronization services provided by the session layer for protection against data loss. Specifically, the RTSE must distinguish between data that was delivered successfully to the receiving MTA and data that failed to reach its intended destination, in which case the RTSE might request the retransmission of the data.

To handle the presentation and session services in the OSI stack, the Exchange MTA uses a pool of kernel threads. You can control the number of kernel threads through the following registry parameter:

Location	HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\ MSExchangeMTA\Parameters
Value	Kernel threads
Type	REG_DWORD
Value Data	0x1
Description	Determines the number of MTA kernel threads that handle the presentation and session level of the OSI stack. The default value is 0x1. Adjust if this MTA communicates with LAN-MTAs using RPC over slow or highly latent network connections. Recommended setting: 0x3   The standard recommendation. 0x8   If the Exchange Server 2003 MTA belongs to a routing group containing more than 15 Exchange 5.5 servers. 0xC (12)   If the Exchange Server 2003 MTA belongs to a routing group containing more than 30 Exchange 5.5 servers.

MTA Transport Stacks

To enable the Exchange MTA to communicate with remote X.400 MTAs, using the OSI transport stack, you must define several OSI addresses at the network, transport, session, and presentation layers. This is accomplished through MTA transport stacks. You can install transport stacks in Exchange System Manager when you right-click the X.400 configuration object, point to New, and then click TCP/IP X.400 Service Transport Stack or X.25 X.400 Service Transport Stack. A dialog box appears, in which you specify a network address (that is, a host name, IP address, or X.121 address), Transport Service Access Point (TSAP), Session Service Access Point (SSAP), and Presentation Service Access Point (PSAP). Enter the TSAP, SSAP, and PSAP in the T Selector, S Selector, and P Selector boxes, respectively.

TSAP, SSAP, and PSAP are optional parameters on an Exchange server, because the Microsoft Exchange MTA Stacks service does not share the OSI stack with other MTAs. If, however, the remote MTA uses OSI address information to connect to the local MTA, you must define these parameters for the local MTA. Otherwise, communication cannot take place. It is possible to overwrite the OSI address information per X.400 connector. X.400 connector configuration parameters are discussed later in this section.

To support X.400 connectors, you must install one of the following two MTA transport stacks:

• TCP/IP Transport Stack   TCP/IP is a good choice for X.400 message transfer over the Internet and over intranets. The TCP/IP transport stack implements ISO transport services on top of TCP/IP, as defined in Request for Comments (RFC) 1006. When you install and configure a TCP/IP transport stack, you create a configuration object in Active Directory that defines the service access points and other settings that the MTA uses. Transport stack objects are located in the configuration directory partition under the MTA directory object. You can use the following LDIFDE command to export all TCP/IP transport stacks configured on all servers in an Exchange organization to a file named Stacklist.ldf: ldifde -f c:\Stacklist.ldf -s localhost -d "CN=First Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=contoso,DC=com" -p subtree -r "(objectClass= rFC1006Stack)"

  The following table describes the important attributes of the TCP/IP transport stack.

  Important attributes of the TCP/IP transport stack object

  Attribute	Description
  objectClass	Indicates the class of the directory object as rFC1006Stack.
  nAddressType	Indicates the type of information in the nAddress attribute. The address information can be a host name or an IP address.
  nAddress	Specifies the host name or IP address of the local Exchange MTA.
  tSelector	Specifies the TSAP in the stack's OSI address information.
  sSelector	Specifies the SSAP in the stack's OSI address information.
  pSelector	Specifies the PSAP in the stack's OSI address information.
  supportingStackBL	Lists the distinguished names of X.400 connectors that use this transport stack.
  x400SelectorSyntax	Indicates the type of information in the tSelector, sSelector, and pSelector attributes. The OSI address information can be a hex value or a decimal value.
  name	Specifies the name of the transport stack object as displayed in Exchange System Manager.

• X.25 Transport Stack   You must install an EICON X.25 card on the server running Exchange Server 2003 and the EICON WAN drivers in Windows Server 2003 to support X.400 connectors over X.25. The X.25 configuration is very complex and can be completed only by using the configuration utilities that come with the EICON X.25 card. The X.121 address (comparable to a telephone number) is the most important information that must be configured. X.121 address data, call user data, and facilities data that you specify in the X.25 transport stack must match the EICON card configuration, as specified by your X.25 provider.

  You can use the following LDIFDE command to export all X.25 transport stack objects configured on all servers in an Exchange organization from Active Directory to a file called Stacklist.ldf: ldifde -f c:\Stacklist.ldf -s localhost -d "CN=First Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=contoso,DC=com" -p subtree -r "(objectClass= x25Stack)"

  The following table describes the important attributes of the X.25 transport stack.

  Important attributes of the X.25 transport stack object

  Attribute	Description
  objectClass	Indicates the class of the directory object as x25Stack.
  nAddress	Specifies the local X.121 address.
  x25CallUserDataIncoming	Specifies the call user data for the X.25 adapter.
  x25FacilitiesDataIncoming	Specifies the facilities user data for the X.25 adapter.
  x25LeasedLinePort	Specifies the X.25 adapted port number.
  tSelector	Specifies the TSAP in the stack's OSI address information.
  sSelector	Specifies the SSAP in the stack's OSI address information.
  pSelector	Specifies the PSAP in the stack's OSI address information.
  supportingStackBL	Lists the distinguished names of X.400 connectors that use this transport stack.
  x400SelectorSyntax	Indicates the type of information in the tSelector, sSelector, and pSelector attributes. The OSI address information can be a hex value or a decimal value.
  name	Specifies the name of the transport stack object as displayed in Exchange System Manager.

MTA Communication Example

The following figure illustrates how an MTA opens a connection through RTSI and the OSI stack. Each transfer of data between MTAs must travel down one side of the OSI stack through the session and transport layers and back up the stack on the other MTA. When an MTA sends a message through the OSI stack, the MTA either sends a request or a response. A request arrives at the other MTA as an indication, and a response appears as a confirmation.

Establishing a connection between two MTAs

To handle the communication at the transport layer in the OSI stack, the Exchange MTA uses transport threads. You can configure the number of transport threads that the MTA uses through the following registry parameter.

Location	HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\ MSExchangeMTA\Parameters
Value	Transport threads
Type	REG_DWORD
Value Data	0x1
Description	Determines the number of transport threads. The default value is 0x1. The recommended value is 0x3 if this MTA communicates with remote MTAs over multiple X.400 connectors.

X.400 Connectors

In a distributed environment, communication conflicts can occur if the communicating MTA processes are not carefully coordinated. For example, the Exchange MTA is a 1988 X.400 MTA, and must scale back its features when communicating with a 1984 MTA.

Configuring an X.400 Connector

To understand the features that a remote X.400 MTA supports, you must configure an X.400 connector to that remote MTA. First, ensure that you have configured an appropriate MTA transport stack, and then, in Exchange System Manager, expand the routing group in which you want to add the X.400 connector, right-click Connectors, point to New, and then click either TCP X.400 Connector or X.25 X.400 Connector, according to the configuration of your server.

The following figure shows the Properties dialog box for a sample X.400 connector.

Property tabs of an X.400 connector

You will see a dialog box, as shown in Figure 7.12, which has the following tabs:

• General   This tab is used to define a name, the remote X.400 MTA and password, and the transport stack. You can also use this tab to specify whether remote clients support MAPI and whether to allow public folder referrals.

• Schedule   This tab is used to set the communication schedule. Never, Always (communication occurs constantly), Selected Times (up to 15-minute intervals), and Remote Initiated may be configured.

• Stack   This tab is used to specify required address information, such as remote host name or IP Address (or X.121 address), and service access points for the remote system.

• Override   This tab is used to override default X.400 attributes of the local MTA.

• Address Space   This tab is used to define the type and format of routing addresses. Cost values are associated with address spaces to optimize routing. In addition, you can specify whether this connector is available to the entire organization or restricted to the local routing group.

• Advanced   This tab is used to specify X.400 message formats and transfer procedures when sending messages to a remote X.400 system or server running Exchange.

• Content Restrictions   This tab is used to specify which message types can traverse the connector according to priority (High, Normal, or Low), message type (System Messages or Non-System Messages), and message size (Allowed Sizes).

• Details   This tab is used to specify an administrative note for information purposes.

• Connected Routing Groups   This tab is used to specify the names of remote routing groups that can be reached through this X.400 connector.

• Delivery Restrictions   This tab is used to specify who can send messages over this connector. By default, messages are accepted from everyone.

Connect Request Information

Every X.400 connection is a secured connection. This means that one MTA attempting to contact another MTA must identify itself within the connect request. The identification information includes name and password for the local and remote MTA. If this information does not match the configuration of the remote X.400 system, the connection request is refused, and messages are not transferred.

You can specify the name and password of the local MTA, from the server's Protocols container, in the X.400 object's Properties. The administrator of the remote MTA must ensure that this information is also specified correctly on the remote MTA. Also, to configure your local MTA correctly, you must get the name and password of the remote MTA from the remote administrator. To specify the name and password of the remote MTA, from the General tab, click Modify.

Especially when connecting to a public X.400 network, you might be forced to override the name and password of the local MTA on a per-connector basis. Public X.400 carriers usually provide the required information that you must use. To adjust the configuration on a per-connector basis, use the Override tab. Also, you can adjust the various X.400 protocol parameters from this tab, such as Maximum Open Retries and Maximum Transfer Retries, which are discussed earlier in this section.

Outgoing and Incoming OSI Address Information

To specify how a remote MTA should be contacted, in the connector properties, on the Stack tab, configure the OSI address information. Most importantly, you must specify the network address of the remote MTA (IP address, host name, or X.121 address) and any TSAPs, SSAPs, or PSAPs, if they are defined on the remote MTA. The values on the Stack tab all refer to the remote system. The local OSI address information is specified in the MTA transport stack, as explained earlier. If you have not specified any OSI address information in the local MTA transport stack, the Exchange MTA expects the same TSAP, SSAP, or PSAP values as defined in the outgoing OSI address information for the remote MTA. For more information about OSI address configurations, see Microsoft Knowledge Base article 152934, "XCON: X.400 Connector Stack Property Page Behavior."

X.400 Addresses

X.400 systems use a complex addressing scheme for message routing and delivery. The most important X.400 address type is called a mnemonic originator/recipient (O/R) name or O/R address. A mnemonic O/R address identifies a recipient based on country, administration management domains (ADMD), and private management domain (PRMD). Further address information, such as surname and given name, is required to form a complete address.

Every X.400 address must contain management domain information. A management domain is basically a messaging network that is maintained by a single organization. This organization can be a public operating agency (such as a telecommunications company) or a private organization. As recommended by ITU-T, PRMDs handle internal messages, and external messages destined to other PRMDs are always handled by public ADMDs (telecom companies). In theory, PRMDs are supposed to communicate with each other through ADMDs. However, in practice, PRMDs often bypass telecom-ADMDs to communicate directly with each other (for example, using TCP/IP over the Internet), which lowers costs.

The following table lists the fields that can be used in an O/R name.

O/R attributes in an X.400 address

Label	Abbreviation	Attribute Type	Example
C	Country	Country	C=US;
A	ADMD	ADMD name	A=MCI;
P	PRMD	PRMD name	P=TAILSPINTOYS;
S	Surname	Surname	S=BREMER;
G	Given Name	Given name	G=TED;
I	Initials	Initials	I=TB;
Q	Generation	Generation qualifier	Q=SR;
CN	Common Name	Common name	CN=TED BREMBER;
X.121	X.121	X.121 address	X.121=493098722102
N-ID	N-ID	UA numeric ID	N-ID=208973240
T-TY	T-TY	Terminal type	T-TY=TTY;
T-ID	T-ID	Terminal identifier	T-ID=309;
O	Organization	Organization	O=EXCHANGE;
OU1	Org.Unit.1	Organizational unit 1	OU1=IT;
OU2	Org.Unit.2	Organizational unit 2	OU2=USA;
OU3	Org.Unit.3	Organizational unit 3	OU3=SEA;
OU4	Org.Unit.4	Organizational unit 4	OU4=DOWNTOWN;
DDA	DDA	Domain Defined Attribute (DDA:type=value attribute)	DDA:SMTP=Ted@tailspintoys.com

X.400 Address Spaces

Each X.400 connector must have at least one associated address space, which you can specify on the Address Space tab. The routing engine uses this information to determine possible connectors for a particular message, by comparing recipient addresses with available address space information. When connecting to a remote X.400 system, you typically configure X.400 address space. However, you can also associate an X.400 connector with other address types, for example, by specifying SMTP address information, as shown in the following figure. A message sent to a matching SMTP recipient (such as Ted@tailspintoys.com) is then routed through the X.400 connector. The Exchange MTA converts the address information to an X.400 address using domain defined attributes (DDA), as listed earlier in the table above.

Address spaces for an X.400 connector

When specifying non-X.400 address spaces, you must make sure that the receiving MTA can handle the non-X.400 address information. For example, if the target X.400 system cannot handle SMTP DDA information, assigning an SMTP address space to a X.400 connector that points to this system is not a good idea. Messages are not transferred successfully in the remote system. Some X.400 systems expect encapsulated SMTP address information, as defined in RFC 2156 "MIXER (Mime Internet X.400 Enhanced Relay)," which describes a method for mapping message formats and address information between RFC 822/MIME and X.400. A corresponding DDA address portion looks like this: DDA:rfc-822=Ted@tailspintoys.com. Exchange Server 2003 uses SMTP DDAs instead of RFC822 DDA and does not support MIXER.

Conformance Year and Body Parts

Using the Advanced tab, you can specify X.400 features that should be enabled when connecting the organization to a remote X.400 system. Important settings are the X.400 conformance year and X.400 bodypart. The MTA conformance year, for instance, must match the conformance year of the external system, because significant differences exist between 1984 and 1988 X.400 standards. Otherwise, the local MTA overtaxes the remote MTA, and communication problems occur.

The Advanced tab of an X.400 connector

Using the X.400 bodypart for message text list, you can also select a bodypart for the message text as it will appear in the message body. A message can consist of several bodyparts, which allows for e-mail attachments. The following table lists the bodyparts that Exchange Server 2003 supports.

X.400 bodyparts of interpersonal messages

Bodypart Number	Bodypart
0	IA5 text
1	Telex (ITA2 5-bit)
2	Voice
3	G3 facsimile
4	Text interchange format (TIFO)
5	Telex (T.61)
6	Videotex
7	Nationally defined
8	Encrypted
9	Forwarded IP message
10	Simple Formatable Document (SFD)
11	Text interchange format 1 (TIF1)
12	Octet string
13	ISO6937 text
14	Bilaterally-defined (binary)
15	Binary file transfer (first defined in 1988)

When connecting to a remote Exchange MTA in the same organization, you can select the Allow Exchange Contents check box. The native Exchange format is not X.400 conforming, but between Exchange MTAs this is not an issue. However, you must clear this check box when communicating with an Exchange MTA that is external to the local Exchange organization, because native Exchange content includes legacyExchangeDN address information, which is only valid in the local organization. The recipients specified through legacyExchangeDN addresses do not exist in the directory of the external Exchange MTA.

To send messages in Exchange format to Exchange users in external organizations, from the General tab of the connector, select the Remote Client Supports MAPI check box. When you select this check box, the Exchange MTA encapsulates the messages using Transport Neutral Encapsulation Format (TNEF). The MTA converts the message to a plain text part and an attachment in legacy TNEF. To learn more about TNEF, see SMTP Transport Architecture.

Message Loop Detection

X.400 defines a concept of organizational boundaries, which influence how MTAs handle trace information added to the P1 message transfer envelope for loop detection. Each MTA in an organization adds trace information to indicate that the MTA has already transferred the message. If a message reaches the same MTA twice, the MTA might determine that the message is looping and drop it with a non-delivery report (NDR).

Trace information in a P1 message transfer envelope

An MTA can add the following two types of trace information to the P1 message transfer envelope:

• External trace information   External trace information identifies each X.400 domain that transferred the message. The X.400 domain is defined by a global domain identifier is made up of the X.400 address fields country, ADMD, and PRMD.

  The MTA adds external trace information to a message when the message reaches the organization; for example, when the Exchange store submits a message to the MTA or when the MTA receives a message from an MTA in another organization. If an MTA receives a message from an external organization and encounters its own local global domain identifier in the external trace information, a message loop between the organizations is detected. The presence of the local global domain identifier indicates that the local X.400 domain already handled the message and routed it to the other domain. If the MTA accepts the message again, the message routes again to the other domain, where it is routed back again to the local domain. This represents a message loop, and the MTA must drop the message with an NDR.

  Note

  The Exchange MTA does not remove external trace information from messages.

• Internal trace information   Internal trace information identifies each MTA that transferred the message within an organizational boundary. Internal trace information is made up of the MTA name and information about routing actions (such as whether the message was relayed or rerouted, or caused a distribution list (DL) expansion by that MTA). If a message enters the same MTA twice, it might be dropped with an NDR.

  To detect message loops based on internal trace information, the MTA performs the following steps:

  1. The MTA reads the TraceInformation part of the P1 message transfer envelope to determine if the MTA previously handled the message.

  2. The MTA determines if the global domain identifier matches the local global domain identifier. If this is the case, the MTA compares the local MTA name with the names in the internal trace information.

  3. If the local MTA name is not present, no message loop is detected. The MTA stops checking at this point.

  4. If the local MTA name is present, the MTA checks the routing action information in the internal trace information. If no routing action is present, the message was not transferred across the local domain and no message loop is detected. The MTA stops checking at this point.

  5. If the routing action indicates that the message was relayed, a message loop is possible. The MTA then checks the other actions field to determine if the message was rerouted or the distribution-list was expanded. If either condition exists, the message might legitimately revisit an MTA, so it is not dropped with an NDR. The remote replay scenario is another scenario in which a message might legitimately revisit an MTA. This scenario is explained in the section "Replaying DAT Files" in Exchange MTA in Exchange Server 2003 Architecture.

  6. However, if the message was relayed and no other actions are specified, the MTA marks the message as looping and drops it with an NDR to inform the message sender that the message did not arrive at its final destination.

The MTA adds internal trace information to the P1 message transfer envelope of all messages it processes. However, when the MTA detects that the message is transferred to an external X.400 domain, it must remove all internal trace information from the message envelope, because between X.400 domains, only external trace information is used for loop detection. To determine when to remove the internal trace information, the MTA compares its local global domain identifier to the global domain identifier of the target MTA.

To determine its local global domain identifier, the Exchange MTA reads the default recipient policy. Specifically, the Exchange MTA reads the country, ADMD, and PRMD information from the primary X.400 address space defined in the default recipient policy to create the local global domain identifier. You can configure the default global domain identifier for the Exchange MTA in Exchange System Manager. Under Recipient Policies, display the properties of the Default Policy, and then edit the X.400 e-mail address entry. By default, the global domain identifier is c=US;a= ;p=<first 16 letters of the name of the Exchange organization>.

To determine the global domain identifier of the remote MTA, the local MTA reads the country, ADMD, and PRMD information from the address space assigned to the X.400 connector on the Address Space tab, but you can overwrite this information on the Advanced tab if you click Global Domain Identifier. Click Specified Global Domain Identifier, and then define the global domain identifier in terms of country, ADMD, and PRMD. Under ADMD (a), select Any, if you want to allow the X.400 connector to use any ADMD, which corresponds to a blank ADMD field. If you select Specific, you must type a value for the ADMD.

X.400 Connector Objects in Active Directory

When you install and configure an X.400 connector, you create a configuration object in Active Directory that defines the X.400 features and protocol parameters that the MTA must use. Connector objects are located in the configuration directory partition under the connector's routing group, in the Connections container. The routing engine reads this information to initialize the link state table, as discussed in Message Routing Architecture

You can use the following LDIFDE command to export all X.400 connectors in an Exchange organization named First Organization to a file called X400Connectors.ldf: ldifde -f c:\X400Connectors.ldf -s localhost -d "CN=First Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=contoso,DC=com" -p subtree -r "(objectClass=x400Link)"

The following table describes the important attributes of X.400 connector objects.

Important attributes of X.400 connector objects

Attribute	Description
activationSchedule	Specifies the activation schedule for this X.400 connector.
activationStyle	Specifies the activation style for this X.400 connector. (0=Never schedule, 1=Use schedule)
aDMD	Specifies the ADMD portion of a manually defined global domain identifier.
associationLifetime	Specifies the amount of time in seconds that the system keeps an association open to a remote X.400 MTA after a message is sent.
c	Specifies the country portion of a manually defined global domain identifier.
delivEITs	Specifies the deliverable message types in encoded format according to the content restrictions configured for this connector.
delivExtContTypes	Specifies the object IDs for content types supported by this connector.
gatewayLocalDesig	Specifies the name of the remote X.400 MTA that the local MTA uses when establishing a connection.
homeMTA	Specifies the distinguished name of the MTA that uses this X.400 connector.
lineWrap	Specifies the number of characters in the message text after which the MTA inserts a line break.
localInitialTurn	Specifies whether the local MTA or the remote MTA has the initial turn on new associations.
msExchConnectorType	Designates this connector object as an X.400 connector.
msExchEncryptedPassword	Specifies the override password for the local MTA. Note The password is protected in Active Directory, but X.400 MTAs transmit MTA names and passwords in clear text.
msExchEncryptedPassword2	Specifies the password, in encrypted form, that the local MTA must use when establishing a connection to the remote X.400 MTA. Note The password is protected in Active Directory, but X.400 MTAs transmit MTA names and passwords in clear text.
msExchNoPFConnection	Specifies whether public folder referrals are allowed over this X.400 connector. This setting is relevant only if this connector is used to connect to another routing group in the same Exchange organization.
mTALocalDesig	Specifies the override name for the local MTA.
nAddress	Specifies the host name or IP address of the local Exchange MTA.
nAddressType	Indicates the information type in the nAddress attribute. The address information can be a host name or an IP address.
name	Specifies the name of the transport stack object, as displayed in Exchange System Manager.
numOfOpenRetries	Specifies the maximum number of times that the Exchange MTA tries to open a connection before it sends a non-delivery report (NDR).
numOfTransferRetries	Specifies the maximum number of times that the Exchange MTA tries to transfer a message across an open connection.
objectClass	Indicates the class of the directory object as x400Link. The following object classes are derived from this class: rFC1006X400Link   TCP/IP X.400 connectors x25X400Link   X.25 X.400 connectors
openRetryInterval	Specifies the number of seconds that the system waits after an error, before attempting to reopen a connection.
pRMD	Specifies the PRMD portion of a manually defined global domain identifier.
pSelector	Specifies the PSAP in the stack's OSI address information.
routingList	Specifies the address spaces configured for this X.400 connector.
rTSCheckpointSize	Specifies the amount of data (in kilobytes) transferred before a checkpoint is inserted. If an error occurs and the message must be resent, the process restarts from the most recent checkpoint. A value of zero indicates that no checkpoints are inserted.
rTSRecoveryTimeout	Specifies the amount of time after a broken connection that the MTA waits for reconnection before deleting the information (with its checkpoints) and restarting the transfer from the beginning.
rTSWindowSize	Specifies the number of checkpoints that can go unacknowledged before data transfer is suspended. The window size has no meaning if the checkpoint size is zero.
sessionDisconnectTimer	Specifies the amount of time in seconds that the Exchange MTA waits before disconnecting a connection after all associations over this connection are cancelled.
sSelector	Specifies the SSAP in the stack's OSI address information.
supportedApplicationContext	Specifies the object identifiers of application contexts that an OSI application, such as the Exchange MTA, supports.
supportingStack	Specifies the distinguished name of the MTA transport stack that the MTA uses to communicate over this connector.
tempAssocThreshold	Specifies the maximum number of queued messages that the system can send to a remote system. When this is exceeded, the MTA opens another association.
transferRetryInterval	Specifies the number of seconds that the system waits after a message transfer fails before re-sending a message across an open connection.
transferTimeoutNonUrgent	Specifies the amount of time in seconds per kilobyte that the system waits before sending an a non-delivery report (NDR) for a non-urgent message.
transferTimeoutNormal	Specifies the amount of time in seconds per kilobyte that the system waits before sending a non-delivery report (NDR) for a normal message.
transferTimeoutUrgent	Specifies the amount of time in seconds per kilobyte that the system waits before sending a non-delivery report (NDR) for an urgent message.
translationTableUsed	Specifies the translation table that the MTA uses to encode the message text.
transportExpeditedData	Specifies whether expedited data is supported over the X.400 connector. Expedited data bypasses the flow control procedures and provides a means for expediting the delivery of urgent data, such as an abrupt disconnection request. When an MTA requests the expedited data service, the other MTA must agree to its use on the connection. Otherwise, the feature is not available.
tSelector	Specifies the TSAP in the stack's OSI address information.
twoWayAlternateFacility	Specifies whether the MTA association is one-way or two-way alternate.
x400SelectorSyntax	Specifies the syntax of the P, S, and T selectors. (0 or undefined=Hex, 1=Text)

Running Multiple X.400 Connectors

The maximum number of X.400 connectors that you can install on a single server running Exchange Server varies depending on practical limits for each server, such as hardware and network bandwidth. However, by default, Exchange 2003 is not optimized for numerous X.400 connectors, because the server supports a maximum of 20 concurrent connections per connector type (that is, TCP/IP and X.25). At ten associations per connector, this is two X.400 connectors over TCP/IP. If you configure 30 or more TCP/IP X.400 connectors on a central bridgehead server, and all the associations are in use, event ID 9156 might appear in the application event log:

Event ID: 9156

Source: MSExchangeMTA

Type: Warning

Category: Resource

Description: A resource limit has been reached while attempting to open an association. There are no free control blocks available for network type 1. The configured count is 70. [BASE IL MAIN BASE 1 282] (10)

To support more than two X.400 connectors on a bridgehead server, you should increase the number of control blocks by using the following registry parameter.

Location	HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\ MSExchangeMTA\Parameters
Values	TCP/IP control blocks TP4 control blocks Eicon X.25 connections
Type	REG_DWORD
Value Data	0x14 (20)
Description	Determines the maximum number of buffers available for X.400 connections. It is best to provide ten control blocks for each X.400 connector, plus one control block for an incoming connection, if the maximum number of associations is exceeded. For example, if you have 30 TCP/IP X.400 connectors, set TCP/IP control blocks to 0x12D (301) for maximum performance.

To handle the communication load at the TCP/IP layer, you might also have to increase the number of TCP/IP threads that the MTA uses, through the following registry parameter.

Location	HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\ MSExchangeMTA\Parameters
Value	TCP/IP threads
Type	REG_DWORD
Value Data	0x2
Description	Determines the number of MTA threads that handle RFC1006 connections. The default value is 0x2. This number is multiplied by two for the two subtypes of RFC1006 threads (driver and async notify).

The actual maximum number of control blocks that the Exchange MTA can use is 1,250, but this number is taken from a pool of control blocks for the TCP/IP, TP4, and X.25 transport stacks. The registry values indicated correspond to TCP/IP control blocks, TP4 control blocks, and X.25 control blocks, respectively. By default, all of these values are set to 20 decimal, so the TCP/IP control blocks value can be increased up to 1,210 decimal without creating a problem. This permits a maximum of 121 TCP/IP X.400 connectors on a single server, each using the maximum number of allowable associations. This number is theoretical. The capacities of the bridgehead server might limit the actual number of X.400 connectors.

It is unlikely that each X.400 connector will process enough mail to require the maximum number of associations for each connector. Furthermore, if the X.25 transport stack is not in use, you can reduce the Eicon X.25 connections parameter to a value of zero, thus increasing the available control blocks for the TCP/IP stack by 20. However, TP4-based X.400 connectors are not supported in Exchange Server 2003, and reducing the TP4 control blocks does not allocate additional control blocks for TCP/IP.

If you set the maximum number of pooled control blocks too high, the Microsoft Exchange MTA Stacks service cannot start, and the following event is logged in the application event log:

Event ID: 4300

Source: MSExchangeMTA

Type: ERROR

Category: Configuration

Unable to initialize due to a bad configuration. Contact Microsoft Technical Support. Error code=<variable> [1 POP4 MAIN BASE 1] (16)