MIXER: X.400 and Internet Mail Conversion

Article by Steve Kille

Published in Messaging Magazine, November/December 1998

1998 has been an important year for MIXER (MIME Internet X.400 Enhanced Relay), as the MIXER RFCs have been published adding new features and operational updates. Both Internet Mail and X.400 are widely used, and as many Internet Mail users will not have direct access to X.400 and vice versa, gateway services supporting MIXER are essential for effective message transfer and conversion.

What is MIXER

MIXER specifies how messages should be transferred between Internet messaging and X.400, to ensure that there is no loss of functionality. It has been developed under the aegis of the Internet Engineering Task Force (IETF), and the most recent version was published in January 1998. MIXER is an Internet standards track specification. It has been approved as a Proposed Internet Standard, and it is anticipated that it will progress to a Full standard within normal timescales

While MIXER is a detailed and complex specification, the goals and top level model of MIXER are straightforward. MIXER specifies a conversion between Internet Mail, including the MIME specifications, and X.400 InterPersonal Messaging. Both Internet Mail and X.400 have significant user bases. Many Internet Mail users will not have direct access to X.400 and vice versa, and therefore conversion between X.400 and Internet Mail is of substantial use. It is important to note that X.400 Mail may be used over the Internet, and therefore the term 'Internet Mail' is used to signify SMTP/RFC 822/MIME, and not just the term 'Internet'.

The reason for MIXER is to define a standardized mechanism for conversion between the two technologies. There is substantial user benefit in having a standardized mapping (translation between addresses), as it leads to a uniform service from different providers of the mapping service, known as (mail) gateway service providers.

MIXER is clearly important for enterprises which base their corporate mail services on either Internet Mail or X.400, and which need to transfer and convert messages between these two open protocols. MIXER, however, can also be important for organizations whose mail service strategy involves products such as Microsoft Exchange or Lotus Notes. These proprietary products generally support interchange with Internet Mail and/or X.400, so for organizations who wish to access both X.400 and Internet messages, it may be adequate simply to ensure that the required protocol support is enabled by the workgroups. Deploying a MIXER gateway, however, enables the workgroup servers to be configured with a single open protocol, which is significantly less expensive and more manageable. Furthermore, MIXER ensures that messages are effectively and reliably transferred between Internet Mail and X.400 users, with no loss of functionality.

Chronology

This section gives a brief history of MIXER. The various versions of MIXER have been published as RFCs, which is the publication mechanism of the IETF.

September 1985 - Meeting held at IFIP WG 6.5 meeting in Washington DC agrees on the basic need for MIXER, and agrees on work which leads to a series of meetings in the US and UK.

June 1986 - First version of MIXER published as RFC 987, which defined mappings between Internet Mail and X.400(1984).

September 1987 - RFC 1026 published, which updates RFC 987 based on initial operational experience.

March 1990 - RFC 1148 published, which defines a mapping for X.400(1988).

May 1992 - RFC 1327 published, which updates RFC 1148 based on operational experience.

August 1993 - RFC 1495 published, which supplements RFC 1327 to use the MIME specifications.

March 1994 - EEMA (European Electronic Messaging Association) work on X.400 and Internet leads to a recommendation to adopt RFC 1327, and a white paper 'X.400 and Internet Mail Interworking: towards a commercial solution'.

May 1994 - IETF establishes RFC 1327 review team, to consider updates needed to MIXER.

January 1998 - MIXER published as a proposed standard. The core document is RFC 2156, with supporting specifications in RFC 2157, RFC 2158, RFC 2160, RFC 2163 and RFC 2164.

Basic Mappings

X.400 specifies a Message Transfer service supplied by a set of co-operating MTAs (Message Transfer Agents). This basic service allows provision of a number of end to end services, of which InterPersonal Messaging is the most common. X.400 InterPersonal Messaging gives a framework for user to user communication, with User Agents acting on behalf of the user to interact with the message transfer service.

Internet Mail uses a message format known as RFC 822, and a message transfer protocol called Simple Mail Transfer Protocol. SMTP is usually used to provide direct end to end communication between a pair of Internet MTAs. The MIME specification (Multipurpose Internet Mail Extensions) give a framework for supporting structured messaging over RFC 822.

X.400 and Internet Mail have broadly equivalent functionality, and so it is possible to achieve a mapping which retains most of the core service elements of both protocols. The basic mappings between Internet Mail and X.400 are straightforward, and illustrated in Figure 1.

Figure 1. Functional mapping between X.400 and Internet Mail

MIXER defines the following mappings:

X.400 InterPersonal Messages are mapped with Internet Messages. This is the core MIXER mapping.
X.400 Delivery Reports are mapped with Internet Delivery Status Notifications (NOTARY). Some types of Delivery Status Notification, particularly those indicating message delay, cannot be mapped to X.400 Delivery Reports, and so are mapped to X.400 InterPersonal Messages.
X.400 InterPersonal Notifications are mapped onto Internet Messages, and Internet Mail Message Disposition Notifications (as defined in RFC 2298) are mapped onto X.400 InterPersonal Messages. The RFC 2298 work was done too late to be reviewed as a part of this version of MIXER. It is likely that the next version of MIXER will define a mapping between Message Disposition Notifications and InterPersonal Notifications.

There are a large number of service elements to consider, so MIXER contains much detail about which elements are mapped, and how this shall be done. This includes mapping protocol elements and character set conversion. In some cases, mapping can be done without loss of information. In other cases, the extensibility mechanisms of both protocols are used to ensure that information is not lost. An example mapping is the IPM Subject of X.400 mapped with the RFC 822 Subject: heading. The example in Figure 2, which is a message mapped from X.400 to Internet according to MIXER, illustrates the sort of transformations performed.

Return-Path: </G=Telemedia/S=Asiakaspalvelu/OU=Tele/O=TELEBOX/@mailnet.fi>
Delivery-Date: Wed, 21 Sep 1994 10:10:19 +0100
X400-Received: by mta glengoyne.isode.com in /PRMD=ISODE/ADMD=MAILNET/C=FI/;
Relayed; Wed, 21 Sep 1994 10:09:57 +0100
X400-Received: by /PRMD=smtpgw/ADMD=mailnet/C=fi/; Relayed;
Wed, 21 Sep 1994 10:09:32 +0100
X400-Received: by /ADMD=MAILNET/C=FI/; Relayed; Wed, 21 Sep 1994 10:06:40 +0100
Date: Wed, 21 Sep 1994 10:06:40 +0100
X400-Originator: /G=Telemedia/S=Asiakaspalvelu/OU=Tele/O=TELEBOX/@mailnet.fi
X400-Recipients: non-disclosure:;
X400-MTS-Identifier: [/ADMD=MAILNET/C=FI/;12944....... 0Ul1lU00005Ce]
X400-Content-Type: P2-1984 (2)
Content-Identifier: H00000f204c0aab3
From: /G=Telemedia/S=Asiakaspalvelu/OU=Tele/O=TELEBOX/@mailnet.fi
Message-ID:
<H00000f204c0aab3*/G=Telemedia/S=Asiakaspalvelu

/OU=Tele/O=TELEBOX/ADMD=MAILNET/C=FI/@MHS>
To: /G=Telemedia/S=Asiakaspalvelu/OU=Tele/O=TELEBOX/@mailnet.fi
Bcc: s.kille@isode.com
Subject: Mailnet-tiedote
TELE MailNet-tiedote
Telemedia 20.9.1994
.........
Terveisin
Telemedia Asiakaspalvelu

Figure 2. Example X.400 Message mapped to Internet Mail according to MIXER

Attachments

MIXER defines how to map between the X.400 and Internet Messaging frameworks. This gives a translation of basic messaging features and a basis for communication. A key problem for all message conversion solutions is to deal with attachments, and in particular to support proprietary document formats. It is surprisingly hard to deal with attachments in an open manner, and it is only quite recently that X.400 and Internet Mail have addressed this.

MIME was added to the basic Internet Mail service in 1992 to give a framework to add attachments. Registration of attachment types is handled by the IANA (Internet Assigned Numbers Authority), run by the Information Sciences Institute in Los Angeles.

X.400 first added a user extensible mechanism for attachments in the 1988 version. Attachments for X.400(1984) have had to be handled in a vendor specific manner. In 1992, X.400 added a File Transfer Body Part (FTBP) mechanism, which gives a framework for providing generic parameterization with an attachment. The Message Attachment Work Group of EMA defined a profile and registration mechanism for use of the FTBP to transfer attachments. This approach has gained support from a wide range of vendors, and registrations have been made for a number of common commercial formats.

MIXER enables gateways to convert between these two mechanisms, and thus provides an open mechanism to support gatewayed attachments.

Addressing

A major component of the MIXER specification is about handling addresses. Most features of a message protocol can be hidden by a user interface. In a global environment it is not possible to hide is the address format, as they must be input directly by the user. X.400 and Internet Mail have very different addressing approaches, and converting between them is a key problem for MIXER. Internet Mail has a simple string based format of the style:

J.Bloggs@zydeco.com

X.400 has an extensible attribute addressing of the form:

I=J; S=Bloggs; O=Zydeco; P=ZYD; A=Telco; C=US;

There are various advantages and disadvantages of the two addressing approaches. It is unfortunate that these two protocols have such different approaches.

MIXER does not attempt to resolve differences, but provides two mechanisms which recognize the continued and separate existence of the two regimes and provides a framework for interworking:

Encapsulation. By encoding the address of one protocol family in the other, it will always be possible to translate addresses. The encapsulation mechanisms are described briefly here.
Mapping. This provides a mechanism to translate between addresses, which is of substantial benefit when extensive use is made of both protocols. This is discussed in the next section.

To encapsulate an X.400 address in Internet Mail, a string encoding is used to represent the X.400 address in the local part (to the left of the '@'). For example:

'/I=J/S=Bloggs/O=Zydeco/PRMD=ZYD/ADMD=Telco/C=US/'@gateway.net

To encapsulate an Internet Mail address in X.400, the Internet Mail address is encoded as a domain defined attribute (the address extension mechanism provided by X.400), which is used in an X.400 address that identifies the gateway. For example:

RFC-822=J.Bloggs(a)zydeco.com

Note that there is a character set transformation, which maps '@' to '(a)', because of differences between the protocols.

Both encapsulations are ugly and awkward, and not that easy to use directly. However, the encapsulations are necessary to make MIXER viable, and are as simple as can be achieved.

Address Mapping

The encapsulation approach gives severe problems for organizations that need to make extensive use of both X.400 and Internet Mail. Such an organization will register neat (i.e. not encapsulated) addresses for both protocols. A simple solution is to provide a local mapping, so that all messages are delivered correctly to local users. However, this may cause problems whenever a message referencing the organization passed through an external X.400/Internet Mail gateway. This gateway transforms the address into an encapsulated form (rather than the alternate form that the user actually uses) which is not easily recognized by recipients of the message. This problem of transformation into encapsulated form which is not recognized by the recipient is particularly severe when using distribution lists or forwarding messages.

MIXER provides a solution by allowing the organization to define simple global mappings, known as MIXER Conformant Global Address Mappings (MCGAMs). Typically, this will be a single mapping definition for the entire organization, which allows addresses to be mapped cleanly. This global mapping is supported by all conformant MIXER gateways. An example mapping is the equivalent of the domain 'zydeco.com', with the X.400 address space 'O=Zydeco; P=ZYD; A=Telco; C=US'. This mapping means that X.400 and Internet Mail addresses for the organization will always be correctly transformed by a MIXER gateway that supports this particular MCGAM.

A key benefit of using an MCGAM is that the mapping will work for the domain hierarchy (Internet Mail)/ organizational hierarchy (X.400). For example 'sales.zydeco.com' will map with 'OU=Sales; O=Zydeco; P=ZYD; A=Telco; C=US'.

MCGAMs will often need to be shared between multiple MIXER gateways, and MIXER defines three mechanisms for MCGAM publication:

The global mapping is maintained by:

Use of four text tables, in a MIXER defined text format.
Use of the Domain Name Service. This is the name service used by Internet Mail, to support message routing. Mappings are registered in the DNS and naturally accessible to all MIXER gateways. This accessibility is a key advantage of this approach.
Use of LDAP or X.500. The LDAP/X.500 based MIXER mappings are available over the Internet. The major advantage of this approach is use of directory protocols that are being accepted as the industry standard.

The New MIXER Standards

MIXER was recently published, and this section summarizes the core MIXER documents.

RFC 2156 - 'MIXER (Mime Internet X.400 Enhanced Relay): Mapping Between X.400 and RFC 822/MIME.' S. Kille. January 1998. This document is the core MIXER specification.
RFC 2157. 'Mapping between X.400 and RFC-822/MIME Message Bodies. H. Alvestrand.' January 1998. This document defines the mapping of the content of messages.
RFC 2158. 'X/400 Image Body Parts.' H. Alvestrand. January 1998.
RFC 2159. 'A MIME Body Part for FAX.' H. Alvestrand. January 1998.
RFC 2160. 'Carrying Postscript in X.400 and MIME.' H. Alvestrand. January 1998.
RFC 2163. 'Using the Internet DNS to Distribute MIXER Conformant Global Address Mapping (MCGAM).' C. Allochio. January 1998.
RFC 2164. 'Use of an X.500/LDAP directory to support MIXER address mapping.' S. Kille. January 1998.

The following two specifications are needed to support RFC 2164, and were updated to enable this:

RFC 2293. 'Representing Tables and Subtrees in the X.500 Directory.' S. Kille. March 1998.
RFC 2294. 'Representing the O/R Address hierarchy in the X.500 Directory Information Tree.' S. Kille. March 1998.

The following two experimental RFCs are not currently part of the standard track MIXER specifications, but may be used with MIXER:

RFC 2161. 'A MIME Body Part of ODA.' H. Alvestrand. January 1998.
RFC 2162. 'MaXIM-11 - Mapping between X.400/Internet mail and Mail-11 mail.' C. Allochio. January 1998.

New MIXER Features

MIXER (RFC 2156 et al) have many changes relative to RFC 1327. The main ones are:

Operational Updates. The core features of MIXER have stabilized over almost ten years of experience. This document does not offer radical revision, but deals with changes in the Internet and X.400 Protocols.
Upgrade for X.400(92), including alignment to the standardized string representation of X.400 addresses. This is a small change.
Support for MIME. The changes for MIME were specified in RFC 1495, and these have been folded into the core MIXER specification.
Support for NOTARY. NOTARY is the new work on Delivery Status Notifications for Internet Mail.
Support for the File Transfer Body Part, in line with the EMA Profile.
Shift from a single centrally published global mapping, which proved unworkable in practice, to the distributed MIXER Conformant Global Address Mappings (MCGAMs).

Conclusion

With the wide adoption of both Internet Mail and X.400, MIXER is an important specification. It is highly desirable that all providers of Internet Mail to X.400 gateways conform to MIXER and track the changes in the recent specifications, and the work of EMA and EEMA to promote this is important. Most X.400/Internet Gateways now use a MIXER based specification (typically RFC 1327), which is a good measure of the success of this standard.

Isode Whitepapers

Stay Informed

From the Isode blog...

Creative Commons