UCL Technical Report 120 Mailgroup Note 19 Network Working Group S.E. Kille Request for Comments: 987 University College London June 1986 Mapping between X.400 and RFC 822 Status of This Memo This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. This document describes a set of mappings which will enable interworking between systems operating the CCITT X.400 (1984) series of protocols [CCITT84a], and systems using the RFC 822 mail protocol [Crocker82a], or protocols derived from RFC 822. The approach aims to maximise the services offered across the boundary, whilst not requiring unduly complex mappings. The mappings should not require any changes to end systems. This specification should be used when this mapping is performed on the ARPA-Internet or in the UK Academic Community. This specification may be modified in the light of implementation experience, but no substantial changes are expected. Kille [Page 1] RFC 987 June 1986 Mapping between X.400 and RFC 822 Chapter 1 -- Overview 1.1. X.400 The X.400 series protocols have been defined by CCITT to provide an Interpersonal Messaging Service (IPMS), making use of a store and forward Message Transfer Service. It is expected that this standard will be implemented very widely. As well as the base standard (X.400), work is underway on various functional standards of profiles which specify how X.400 will be used in various communities. Many of the major functional standards (e.g. from CEPT, CEN/CENELEC, and NBS) are likely to be similar. Some of the decisions in this document are in the light of this work. No reference is given, as these documents are not currently stable. 1.2. RFC 822 RFC 822 evolved as a messaging standard on the DARPA (the US Defense Advanced Research Projects Agency) Internet. It is currently used on the ARPA-Internet in conjunction with two other standards: RFC 821, also known as Simple Mail Transfer Protocol (SMTP) [Postel82a], and RFC 920 which is a specification for a domain name system and a distributed name service [Postel84a]. RFC 822, or protocols derived from RFC 822 are used in a number of other networks. In particular: UUCP Networks UUCP is the UNIX to UNIX CoPy protocol <0>, which is usually used over dialup telephone networks to provide a simple message transfer mechanism. There are some extensions to RFC 822, particularly in the addressing. They are likely to use domains which conform to RFC 920, but not the corresponding domain nameservers [Horton86a]. CSNET Some portions of CSNET will follow the ARPA-Internet protocols. The dialup portion of CSNET uses the Phonenet protocols as a replacement for RFC 821. This portion is likely to use domains which conform to RFC 920, but not the corresponding domain nameservers. BITNET Some parts of BITNET use RFC 822 related protocols, with EBCDIC encoding. Kille [Page 2] RFC 987 June 1986 Mapping between X.400 and RFC 822 JNT Mail Networks A number of X.25 networks, particularly those associated with the UK Academic Community, use the JNT (Joint Network Team) Mail Protocol, also known as Greybook [Kille84a]. This is used with domains and name service specified by the JNT NRS (Name Registration Scheme) [Larmouth83a]. The mappings specified here are appropriate for all of these networks. 1.3. The Need for Conversion There is a large community using RFC 822 based protocols for mail services, who will wish to communicate with X.400 systems. This will be a requirement, even in cases where communities intend to make a transition to use of X.400, where conversion will be needed to ensure a smooth service transition. It is expected that there will be more than one gateway <1>, and this specification will enable them to behave in a consistent manner. These gateways are sometimes called mail relays. Consistency between gateways is desirable to provide: 1. Consistent service to users. 2. The best service in cases where a message passes through multiple gateways. 1.4. General Approach There are a number of basic principles underlying the details of the specification. 1. The specification should be pragmatic. There should not be a requirement for complex mappings for 'Academic' reasons. Complex mappings should not be required to support trivial additional functionality. 2. Subject to 1), functionality across a gateway should be as high as possible. 3. It is always a bad idea to lose information as a result of any transformation. Hence, it is a bad idea for a gateway to discard information in the objects it processes. This includes requested services which cannot be fully mapped. 4. All mail gateways actually operate at exactly one level Kille [Page 3] RFC 987 June 1986 Mapping between X.400 and RFC 822 above the layer on which they conceptually operate. This implies that the gateway must not only be cognisant of the semantics of objects at the gateway level, but also be cognisant of higher level semantics. If meaningful transformation of the objects that the gateway operates on is to occur, then the gateway needs to understand more than the objects themselves. 1.5. Gatewaying Model 1.5.1. X.400 The CCITT X.400 series recommendations specify a number of services and protocols. The services are specified in X.400. Two of these services are fundamental to this document: 1. The Message Transfer Service, which can be provided by either the P1 or P3 protocols, which are specified in X.411 [CCITT84b]. This document talks in terms of P1, but the mappings are equally applicable to P3. 2. The Interpersonal Messaging Service (IPMS), which is provided by the P2 protocol specified in X.420 [CCITT84c]. This document considers only IPMS, and not of any other usage of the Message Transfer Service. This is reasonable, as RFC 822, broadly speaking, provides a service corresponding to IPMS, and no services other than IPMS have been defined over the Message Transfer Service. As none of the RTS (Reliable Transfer Service) service elements is available to the IPMS user, this level and lower levels are of no concern in this gatewaying specification. Note that in this memo "IP" means "InterPersonal" (not Internet Protocol). The Message Transfer Service defines an end-to-end service over a series of Message Transfer Agents (MTA). It also defines a protocol, P1, which is used between a pair of MTAs. This protocol is simply a file format (Message Protocol Data Unit, or MPDU), transferred between two MTAs using the RTS. There are three types of MPDU: User MPDU This contains envelope information, and uninterpreted contents. The envelope includes an ID, an originator, a Kille [Page 4] RFC 987 June 1986 Mapping between X.400 and RFC 822 list of recipients, and trace information. It is used to carry data for higher level services. Probe This contains only envelope information. It is used to determine whether a User UMPDU could be delivered to a given O/R (originator/recipient) name. Delivery Report This contains envelope information, and specified contents. It is used to indicate delivery success or failure of a User or Probe MPDU over the Message Transfer Service. IPMS (P2) specifies two content types for the P1 User MPDU (User Agent Protocol Data Units or UAPDU): Interpersonal Message (IM-UAPDU) This has two components: a heading, and a body. The body is structured as a sequence of body parts, which may be basic components (e.g.IA5 text, or G3 fax), or IP Messages. The header contains end to end user information, such as subject, primary recipients (To:), and priority. The validity of these fields is not guaranteed by the Message Transfer Service. This provides the basic IPMS. Status Report (SR-UAPDU) This UAPDU has defined contents. It is used to indicate that a message has been received by a User Agent. It does not have to be implemented. 1.5.2. RFC 822 RFC 822 is based on the assumption that there is an underlying service, which is here called the 822-P1 service. The 822-P1 service provides three basic functions: 1. Identification of a list of recipients. 2. Identification of an error return address. 3. Transfer of an RFC 822 message. Kille [Page 5] RFC 987 June 1986 Mapping between X.400 and RFC 822 It is possible to achieve 2) within the RFC 822 header. Some 822-P1 protocols, in particular SMTP, can provide additional functionality, but as these are neither mandatory in SMTP, nor available in other 822-P1 protocols, they are not considered here. Details of aspects specific to a number of 822-P1 protocols are given in appendices B to E. An RFC 822 message consists of a header, and content which is uninterpreted ASCII text. The header is divided into fields, which are the protocol elements. Most of these fields are analogous to P2 header elements, although some are analogous to P1 envelope elements. 1.5.3. The Gateway Given this functional description of the two protocols, the functional nature of a gateway can now be considered. It would be elegant to consider the 822-P1 service mapping onto P1 and RFC 822 mapping onto P2, but reality just does not fit. Therefore one must consider that P1 or P1 + P2 on one side are mapped into RFC 822 + 822-P1 on the other in a slightly tangled manner. The details of the tangle will be made clear in chapter 5. The following basic mappings are thus proposed. When going from RFC 822 to X.400, an RFC 822 message and the associated 822-P1 information is always mapped into an IM-UAPDU and the associated P1 envelope. Going from X.400 to RFC 822, an RFC 822 message and the associated 822-P1 information may be derived from: 1. A Delivery Report MPDU 2. An SR-UAPDU and the associated P1 envelope. 3. An IM-UAPDU and the associated P1 envelope. Probe MPDUs must be processed by the gateway - this is discussed in chapter 5. Any other User MPDUs are not mapped by the gateway, and should be rejected at the gateway. Kille [Page 6] RFC 987 June 1986 Mapping between X.400 and RFC 822 1.6. Document Structure This document has five chapters: 1. Overview - this document. 2. Service Elements - This describes the (end user) services mapped by a gateway. 3. Basic mappings - This describes some basic notation used in chapters 3-5, the mappings between character sets, and some fundamental protocol elements. 4. Addressing - This considers the mapping between X.400 O/R names and RFC 822 addresses, which is a fundamental gateway component. 5. Protocol Elements - This describes the details of all other mappings. There are also six appendices: A. Quoted String Encodings. B. Mappings Specific to JNT Mail. C. Mappings Specific to Internet Mail. D. Mappings Specific to Phonenet Mail. E. Mappings Specific to UUCP Mail. F. Format of Address Tables. 1.7. Acknowledgements This document is eclectic, and credit should be given: - Study of the EAN X.400 system code which performs this function [Neufeld85a]. Some detailed clarification was made by the DFN report on EAN [Bonacker85a]. - An unpublished ICL report, which considered a subset of the problem [ICL84a]. - A document by Marshall Rose [Rose85a]. Kille [Page 7] RFC 987 June 1986 Mapping between X.400 and RFC 822 - A document by Mark Horton [Horton85a]. The string encodings of chapter 3 were derived directly from this work, as is much of chapter 4. - Discussion on a number of electronic mailing lists. - Meetings in the UK and the US. Kille [Page 8] RFC 987 June 1986 Mapping between X.400 and RFC 822 Chapter 2 -- Service Elements RFC 822 and X.400 provide a number of services to the end user. This document describes the extent to which each service can be supported across an X.400 <-> RFC 822 gateway. The cases considered are single transfers across such a gateway, although the problems of multiple crossings are noted where appropriate. When a service element is described as supported, this means that when this service element is specified by a message originator for a recipient behind a gateway, that it is mapped by the gateway to provide the service implied by the element. For example, if an RFC 822 originator specifies a Subject: field, this is considered to be supported, as an X.400 recipient will get a subject indication. Support implies: - Semantic correspondence. - No loss of information. - Any actions required by the service element. For some services, the corresponding protocol elements map well, and so the service can be fully provided. In other cases, the service cannot be provided, as there is a complete mismatch. In the remaining cases, the service can be partially fulfilled. The level of partial support is summarised. NOTE: It should be clear that support of service elements on reception is not a gatewaying issue. It is assumed that all outbound messag