WORKSHOPS

Making Good Connections With X.400 & SMTP

by Nancy Cox

In our example, an X.400 message mailed from London would be routed to New York, converted there to SMTP format and routed on to the recipient in Atlanta. SMTP and X.400 can be used to connect internal sites with each other and also to connect the company with the external Internet or global X.400 community. Organizations with only one protocol on their WANs may want to tunnel X.400 o r SMTP over the other protocol to achieve the connectivity required.

Know Thy Network To implement an SMTP or X.400 gateway or MTA, you must have knowledge of the network underpinnings, including the physical connections and the protocols supported. This information forms the foundation on which the gateway or MTA will function and may determine the naming and addressing information required to establish the connection. Network underpinnings also are important in establishing the right balance between cost and speed of delivery. The protocol stack on which the gateway rests requires that you enter address information, not only of your own site, but that of any remote site or foreign site to which you will connect. The addresses, names, passwords and other information must match on both sides for the connection to work.

Although the protocol for SMTP gateway s is TCP/IP, the Exchange X.400 connector supports three network protocol stacks: TP4/CLNP, TCP/IP and TP0/X.25. You must select and in stall one of these for your own site and identify the stack for the remote site. TP4 is a Connectionless Protocol to provide Open Systems Interconnection (OSI) communications over LANs. TCP/IP connectivity for the X.400 connector is made possible by using RFC 1006, enabling the use of X.400 over a TCP/IP network. TP0/X.25 is the OSI standard protocol for connection-oriented dial-up and direct communications.

Conformance to the international standards is a requirement for either X.400 or SMTP systems to establish and maintain working connections with remote or foreign sites. The SMTP gateway or MTA should adhere, at a minimum, to the following RFCs: 821 and 822 (SMTP), 974 (Mail Routing and the Domain System), 1034 and 1035 (Domain Name Service), 1123 (Internet Hosts) and 1521 and 1522 (MIME). The X.400 gateway or MTA should provide conformance to the X.400 1984, 1988 or 1993 standard. In addition, when connecting to Hewlett-Packard's HP OpenMail, the conformance level required is that of 1988 X.410 mode.

For SMTP connectivity for internal sites, a decision needs to be made as to whether to use Domain Name Service (DNS) or just create the appropriate entries in the host file. You'll have to use DNS if you're connecting to the Internet for external use. DNS performs the domain name to IP address mapping for the exchange of SMTP messages. Entries must be made in address records, mail exchanger and alias records prior to configuring the SMTP gateway.

Every network path through your enterprise can be assigned a cost factor in most of the gateways or connectors. This lets you determine the most cost-effective route for a message and then place most of the traffic over that route.

Optimizing Options Most of the SMTP and X.400 gateways available, including Notes, Exchange and GroupWise, support a variety of content types and character sets. X.400 content types include P2 (1984 standard), P22 (1988 standard), Body Part 15 for unstructured binary data and File Transfer Body Part (FTBP). On the In ternet side, the choice is generally between supporting MIME or UUENCODE. A message received by any Internet connector will be uudecoded or treated as MIME as appropriate. Also, support of rich text formatting is available in the Exchange connectors if the receiving site is MAPI-compliant.

Scheduling the sending and receiving of messages and various retry intervals enables the system to function more in line with the company's goals in providing reliable message services. Most SMTP and X.400 systems let you select whether the system will always connect whenever messages are in queue to be sent, at specified times on certain days or only when the remote site initiates the connection. In addition, you can determine whether the default times the gateway will attempt to send an urgent message before sending a nondelivery notice should be reduced, based on the company's negotiated service-level requirements.

Deciding whether to inflict a message size limitation or not is a balancing act. You may want to cu rtail the exchange of massively large attachments to improve performance and reduce storage space in the message store. But, this constraint can negatively affect availability of the system if too many messages are rejected due to size. Over time, directories may become so large that they will exceed the message size constraint, and you'll have to reconfigure the option.

If your network connection is reliable, then the checkpoint size could be reduced or eliminated to improve delivery times. The checkpoint size is the number of kilobytes that the system will transmit before inserting a checkpoint.

If the site is active with high traffic volumes, you should consider configuring two gateways, one to send and one to receive. This setup will reduce the likelihood of a bottleneck. Both the Exchange connectors and the Notes SMTP MTA support assigning a cost to the route that promotes scalability and enables load-balancing between multiple gateways.

Nancy Cox can be reached at ncox@nwc.com.