Network Working Group J. Houttuin Request for Comments: 1506 RARE Secretariat RARE Technical Report: 6 August 1993 A Tutorial on Gatewaying between X.400 and Internet Mail Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard. Distribution of this memo is unlimited. Introduction There are many ways in which X.400 and Internet (STD 11, RFC 822) mail systems can be interconnected. Addresses and service elements can be mapped onto each other in different ways. From the early available gateway implementations, one was not necessarily better than another, but the sole fact that each handled the mappings in a different way led to major interworking problems, especially when a message (or address) crossed more than one gateway. The need for one global standard on how to implement X.400 - Internet mail gatewaying was satisfied by the Internet Request For Comments 1327, titled "Mapping between X.400(1988)/ISO 10021 and RFC 822." This tutorial was produced especially to help new gateway managers find their way into the complicated subject of mail gatewaying according to RFC 1327. The need for such a tutorial can be illustrated by quoting the following discouraging paragraph from RFC 1327, chapter 1: "Warning: the remainder of this specification is technically detailed. It will not make sense, except in the context of RFC 822 and X.400 (1988). Do not attempt to read this document unless you are familiar with these specifications." The introduction of this tutorial is general enough to be read not only by gateway managers, but also by e-mail managers who are new to gatewaying or to one of the two e-mail worlds in general. Parts of this introduction can be skipped as needed. For novice end-users, even this tutorial will be difficult to read. They are encouraged to use the COSINE MHS pocket user guide [14] instead. To a certain extent, this document can also be used as a reference guide to X.400 <-> RFC 822 gatewaying. Wherever there is a lack of detail in the tutorial, it will at least point to the corresponding chapters in other documents. As such, it shields the RFC 1327 novice RARE Working Group on Mail and Messaging (WG-MSG) [Page 1] RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993 from too much detail. Acknowledgements This tutorial is heavily based on other documents, such as [2], [6], [7], [8], and [11], from which large parts of text were reproduced (slightly edited) by kind permission from the authors. The author would like to thank the following persons for their thorough reviews: Peter Cowen (Nexor), Urs Eppenberger (SWITCH), Erik Huizer (SURFnet), Steve Kille (ISODE Consortium), Paul Klarenberg (NetConsult), Felix Kugler (SWITCH), Sabine Luethi. Disclaimer This document is not everywhere exact and/or complete in describing the involved standards. Irrelevant details are left out and some concepts are simplified for the ease of understanding. For reference purposes, always use the original documents. RARE Working Group on Mail and Messaging (WG-MSG) [Page 2] RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993 Table of Contents 1. An overview of relevant standards ........................ 4 1.1. What is X.400 ? ...................................... 5 1.2. What is an RFC ? ..................................... 8 1.3. What is RFC 822 ? .................................... 9 1.4. What is RFC 1327 ? ................................... 11 2. Service Elements ......................................... 12 3. Address mapping .......................................... 14 3.1. X.400 addresses ...................................... 15 3.1.1. Standard Attributes .............................. 15 3.1.2. Domain Defined Attributes ........................ 17 3.1.3. X.400 address notation ........................... 17 3.2. RFC 822 addresses .................................... 19 3.3. RFC 1327 address mapping ............................. 20 3.3.1. Default mapping .................................. 20 3.3.1.1. X.400 -> RFC 822 ............................. 20 3.3.1.2. RFC 822 -> X.400 ............................. 22 3.3.2. Exception mapping ................................ 23 3.3.2.1. PersonalName and localpart mapping ........... 25 3.3.2.2. X.400 domain and domainpart mapping .......... 26 3.3.2.2.1. X.400 -> RFC 822 ......................... 27 3.3.2.2.2. RFC 822 -> X.400 ......................... 28 3.4. Table co-ordination .................................. 31 3.5. Local additions ...................................... 31 3.6. Product specific formats ............................. 32 3.7. Guidelines for mapping rule definition ............... 34 4. Conclusion ............................................... 35 Appendix A. References ...................................... 36 Appendix B. Index (Only available in the Postscript version) 37 Appendix C. Abbreviations ................................... 37 Appendix D. How to access the MHS Co-ordination Server ...... 38 Security Considerations ..................................... 39 Author's Address ............................................ 39 RARE Working Group on Mail and Messaging (WG-MSG) [Page 3] RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993 1. An overview of relevant standards This chapter describes the history, status, future, and contents of the involved standards. There is a major difference between mail systems used in the USA and Europe. Mail systems originated mainly in the USA, where their explosive growth started as early as in the seventies. Different company-specific mail systems were developed simultaneously, which, of course, led to a high degree of incompatibility. The Advanced Research Projects Agency (ARPA), which had to use machines of many different manufacturers, triggered the development of the Internet and the TCP/IP protocol suite, which was later accepted as a standard by the US Department of Defense (DoD). The Internet mail format is defined in STD 11, RFC 822 and the protocol used for exchanging mail is known as the simple mail transfer protocol (SMTP) [1]. Together with UUCP and the BITNET protocol NJE, SMTP has become one of the main de facto mail standards in the US. Unfortunately, all these protocols were incompatible, which explains the need to come to an acceptable global mail standard. CCITT and ISO began working on a norm and their work converged in what is now known as the X.400 Series Recommendations. One of the objectives was to define a superset of the existing systems, allowing for easier integration later on. Some typical positive features of X.400 are the store-and-forward mechanism, the hierarchical address space and the possibility of combining different types of body parts into one message body. In Europe, the mail system boom came later. Since there was not much equipment in place yet, it made sense to use X.400 as much as possible right from the beginning. A strong X.400 lobby existed, especially in West-Germany (DFN). In the R&D world, mostly EAN was used because it was the only affordable X.400 product at that time (Source-code licenses were free for academic institutions). At the moment, the two worlds of X.400 and SMTP are moving closer together. For instance, the United States Department of Defense, one of the early forces behind the Internet, has decided that future DoD networking should be based on ISO standards, implying a migration from SMTP to X.400. As an important example of harmonisation in the other direction, X.400 users in Europe have a need to communicate with the Internet. Due to the large traffic volume between the two nets it is not enough interconnecting them with a single international gateway. The load on such a gateway would be too heavy. Direct access using local gateways is more feasible. Although the expected success of X.400 has been a bit disappointing RARE Working Group on Mail and Messaging (WG-MSG) [Page 4] RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993 (mainly because no good products were available), many still see the future of e-mail systems in the context of this standard. And regardless if in the long run X.400 will or will not take over the world of e-mail systems, SMTP cannot be neglected over the next ten years. Especially the simple installation procedures and the high degree of connectivity will contribute to a growing number of RFC 822 installations in Europe and world-wide in the near future. 1.1. What is X.400 ? In October 1984, the Plenary Assembly of the CCITT accepted a standard to facilitate international message exchange between subscribers to computer based store-and-forward message services. This standard is known as the CCITT X.400 series recommendations ([16], from now on called X.400(84)) and happens to be the first CCITT recommendation for a network application. It should be noted that X.400(84) is based on work done in the IFIP Working Group 6.5, and that ISO at the same time was proceeding towards a compatible document. However, the standardisation efforts of CCITT and ISO did not converge in time (not until the 1988 version), to allow the publication of a common text. X.400(84) triggered the development of software implementing (parts of) the standard in the laboratories of almost all major computer vendors and many software houses. Similarly, public carriers in many countries started to plan X.400(84) based message systems that would be offered to the users as value added services. Early implementations appeared shortly after first drafts of the standard were published and a considerable number of commercial systems are available nowadays. X.400(84) describes a functional model for a Message Handling System (MHS) and associates services and protocols. The model illustrated in Figure 1.1. defines the components of a distributed messaging system. Users in the MHS environment are provided with the capability of sending and receiving messages. Users in the context of an MHS may be humans or application processes. The User Agent (UA) is a process that makes the services of the MTS available to the user. A UA may be implemented as a computer program that provides utilities to create, send, receive and perhaps archive messages. Each UA, and thus each user, is identified by a name (each user has its own UA). RARE Working Group on Mail and Messaging (WG-MSG) [Page 5] RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993 ----------------------------------------------------------------- | user user Message Handling Environment| | | | | | ----------------------------------------------------------| | | | | Message Handling System || | | ---- ---- || | | |UA| |UA| || | | ---- ---- || | | | | || | | -------------------------------------------------|| | | | | | Message Transfer System ||| | | ---- | ----- ----- ||| |user-|-|UA|--|--|MTA| |MTA| ||| | | ---- | ----- ----- ||| | | | \ / ||| | | | \ / ||| | | | \ / ||| | | | \ / ||| | | | \ / ||| | | ---- | ----- ||| |user-|-|UA|--|---------|MTA| ||| | | ---- | ----- ||| | | -------------------------------------------------|| | ----------------------------------------------------------| ----------------------------------------------------------------- Fig. 1.1. X.400 functional model The Message Transfer system (MTS) transfers messages from an originating UA to a recipient UA. As implied by the Figure 1.1, data sent from UA to UA may be stored temporarily in several intermediate Message Transfer Agents (MTA), i.e., a store-and- forward mechanism is being used. An MTA forwards received messages to a next MTA or to the recipient UA. X.400(84) divides layer 7 of the OSI Reference Model into 2 sublayers, the User Agent Layer (UAL) and the Message Transfer Layer (MTL) as shown in the Figure 1.2. The MTL is involved in the transport of messages from UA to UA, using one or several MTAs as intermediaries. By consequence, routing issues are entirely dealt with in the MTL. The MTL in fact corresponds to the postal service that forwards letters consisting of an envelope and a content. Two protocols, P1 and P3, are used between the MTL entities (MTA Entity (MTAE), and Submission and Delivery Entity (SDE)) to reliably transport messages. The UAL embodies peer UA Entities (UAE), which interpret the content of a message and offer specific services to the application process. Depending on the application to be supported on top of the MTL, one of several end- RARE Working Group on Mail and Messaging (WG-MSG) [Page 6] RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993 to-end protocols (Pc) is used between UAEs. For electronic mail, X.400(84) defines the protocol P2 as part of the InterPersonal Messaging Service (IPMS). Conceivably other UAL protocols may be defined, e.g., a protocol to support the exchange of electronic business documents. -------------------------------------------------------------- ----- ----- UA layer |UAE|<----- P2, Pc ----------->|UAE| ----- ----- -------------------------------------------------------------- ------ ------ ----- MTA layer |MTAE|<-- P1 -->|MTAE|<-- P3-->|SDE| ------ ------ ----- -------------------------------------------------------------- xxxE = xxx Entity ; SDE = Submission & Delivery Entity -------------------------------------------------------------- Fig. 1.2. X.400 Protocols The structure of an InterPersonal Message (IPM) can be visualised as in Figure 1.3. (Note that the envelope is not a part of the IPM; it is generated by the MTL). Forwarded Message IP-message - ---------- --- ---------- - | message- |envelope| / | PDI | | | content IPM ---------- / ---------- | | - - ---------- / ---------- | | | | IPM- |heading | / |hea