summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1506.txt
diff options
context:
space:
mode:
authorThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
committerThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
commit4bfd864f10b68b71482b35c818559068ef8d5797 (patch)
treee3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc1506.txt
parentea76e11061bda059ae9f9ad130a9895cc85607db (diff)
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc1506.txt')
-rw-r--r--doc/rfc/rfc1506.txt2187
1 files changed, 2187 insertions, 0 deletions
diff --git a/doc/rfc/rfc1506.txt b/doc/rfc/rfc1506.txt
new file mode 100644
index 0000000..f0515eb
--- /dev/null
+++ b/doc/rfc/rfc1506.txt
@@ -0,0 +1,2187 @@
+
+
+
+
+
+
+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 | / |heading | |
+ | | | body ---------- / ---------- |
+ | | | - ----------/ ---------- |
+ | | | | |bodypart| |bodypart| |
+ | | | | ----------\ ---------- |
+ | | | | ---------- \ ---------- |
+ | | | | |bodypart| \ |bodypart| |
+ | | | | ---------- \ ---------- |
+ | | | | . \ |
+ | | | | . \ |
+ | | | | ---------- \ ---------- |
+ | | | | |bodypart| \ |bodypart| |
+ - - - - ---------- - ---------- -
+ (PDI = Previous Delivery Info.)
+ Fig. 1.3. X.400 message structure
+
+ An IPM heading contains information that is specific for an
+ interpersonal message like 'originator', 'subject', etc. Each
+ bodypart can contain one information type, text, voice or as a
+
+
+
+RARE Working Group on Mail and Messaging (WG-MSG) [Page 7]
+
+RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993
+
+
+ special case, a forwarded message. A forwarded message consists of
+ the original message together with Previous Delivery Information
+ (PDI), which is drawn from the original delivery envelope.
+
+ Early experience with X.400(84) showed that the standard had various
+ shortcomings. Therefore CCITT, in parallel with ISO, corrected and
+ extended the specification during its 1984 to 1988 study period and
+ produced a revised standard [17], which was accepted at the 1988
+ CCITT Plenary Meeting [10]. Amongst others, X.400(88) differs from
+ X.400(84) in that it defines a Message Store (MS), which can be seen
+ as a kind of database for messages. An MS enables the end-user to run
+ a UA locally, e.g., on a PC, whilst the messages are stored in the
+ MS, which is co-located with the MTA. The MTA can thus always deliver
+ incoming messages to the MS instead of to the UA. The MS can even
+ automatically file incoming messages according to certain criteria.
+ Other enhancements in the 88 version concern security and
+ distribution lists.
+
+1.2. What is an RFC ?
+
+ The Internet, a loosely-organised international collaboration of
+ autonomous, interconnected networks, supports host-to-host
+ communication through voluntary adherence to open protocols and
+ procedures defined by Internet Standards. There are also many
+ isolated internets, i.e., sets of interconnected networks, that are
+ not connected to the Internet but use the Internet Standards. The
+ architecture and technical specifications of the Internet are the
+ result of numerous research and development activities conducted over
+ a period of two decades, performed by the network R&D community, by
+ service and equipment vendors, and by government agencies around the
+ world.
+
+ In general, an Internet Standard is a specification that is stable
+ and well-understood, is technically competent, has multiple,
+ independent, and interoperable implementations with operational
+ experience, enjoys significant public support, and is recognisably
+ useful in some or all parts of the Internet.
+
+ The principal set of Internet Standards is commonly known as the
+ "TCP/IP protocol suite". As the Internet evolves, new protocols and
+ services, in particular those for Open Systems Interconnection (OSI),
+ have been and will be deployed in traditional TCP/IP environments,
+ leading to an Internet that supports multiple protocol suites.
+
+ The following organisations are involved in setting Internet
+ standards.
+
+ Internet standardisation is an organised activity of the Internet
+
+
+
+RARE Working Group on Mail and Messaging (WG-MSG) [Page 8]
+
+RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993
+
+
+ Society (ISOC). The ISOC is a professional society that is concerned
+ with the growth and evolution of the world-wide Internet, with the
+ way in which the Internet is and can be used, and with the social,
+ political, and technical issues that arise as a result.
+
+ The Internet Engineering Task Force (IETF) is the primary body
+ developing new Internet Standard specifications. The IETF is composed
+ of many Working Groups, which are organised into areas, each of which
+ is co-ordinated by one or more Area Directors.
+
+ The Internet Engineering Steering Group (IESG) is responsible for
+ technical management of IETF activities and the approval of Internet
+ standards specifications, using well-defined rules. The IESG is
+ composed of the IETF Area Directors, some at-large members, and the
+ chairperson of the IESG/IETF.
+
+ The Internet Architecture Board (IAB) has been chartered by the
+ Internet Society Board of Trustees to provide quality control and
+ process appeals for the standards process, as well as external
+ technical liaison, organizational oversight, and long-term
+ architectural planning and research.
+
+ Any individual or group (e.g., an IETF or RARE working group) can
+ submit a document as a so-called Internet Draft. After the document
+ is proven stable, the IESG may turn the Internet-Draft into a
+ "Requests For Comments" (RFC). RFCs cover a wide range of topics,
+ from early discussion of new research concepts to status memos about
+ the Internet. All Internet Standards (STDs) are published as RFCs,
+ but not all RFCs specify standards. Another sub-series of the RFCs
+ are the RARE Technical Reports (RTRs).
+
+ As an example, this tutorial also started out as an Internet-Draft.
+ After almost one year of discussions and revisions it was approved by
+ the IESG as an Informational RFC.
+
+ Once a document is assigned an RFC number and published, that RFC is
+ never revised or re-issued with the same number. Instead, a revision
+ will lead to the document being re-issued with a higher number
+ indicating that an older one is obsoleted.
+
+1.3. What is RFC 822 ?
+
+ STD 11, RFC 822 defines a standard for the format of Internet text
+ messages. Messages consist of lines of text. No special provisions
+ are made for encoding drawings, facsimile, speech, or structured
+ text. No significant consideration has been given to questions of
+ data compression or to transmission and storage efficiency, and the
+ standard tends to be free with the number of bits consumed. For
+
+
+
+RARE Working Group on Mail and Messaging (WG-MSG) [Page 9]
+
+RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993
+
+
+ example, field names are specified as free text, rather than special
+ terse codes.
+
+ A general "memo" framework is used. That is, a message consists of
+ some information in a rigid format (the 'headers'), followed by the
+ main part of the message (the 'body'), with a format that is not
+ specified in STD 11, RFC 822. It does define the syntax of several
+ fields of the headers section; some of these fields must be included
+ in all messages.
+
+ STD 11, RFC 822 is used in conjunction with a number of different
+ message transfer protocol environments (822-MTSs).
+
+ - SMTP Networks: On the Internet and other TCP/IP networks,
+ STD 11, RFC 822 is used in conjunction with two other
+ standards: STD 10, RFC 821, also known as Simple Mail
+ Transfer Protocol (SMTP) [1], and RFCs 1034 and 1035
+ which specify the Domain Name System [3].
+
+ - UUCP Networks: UUCP is the UNIX to UNIX CoPy protocol, which
+ is usually used over dialup telephone networks to provide a
+ simple message transfer mechanism.
+
+ - BITNET: Some parts of Bitnet and related networks use STD
+ 11, RFC 822 related protocols, with EBCDIC encoding.
+
+ - 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.
+
+ STD 11, RFC 822 is based on the assumption that there is an
+ underlying service, which in RFC 1327 is called the 822-MTS service.
+ The 822-MTS 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.
+
+ It is possible to achieve 2) within the RFC 822 header. Some 822-
+ MTS protocols, in particular SMTP, can provide additional
+ functionality, but as these are neither mandatory in SMTP, nor
+ available in other 822-MTS protocols, they are not considered here.
+ Details of aspects specific to two 822-MTS protocols are given in
+ Appendices B and C of RFC 1327. 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 heading fields, although some are
+ analogous to MTS Service Elements.
+
+
+
+RARE Working Group on Mail and Messaging (WG-MSG) [Page 10]
+
+RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993
+
+
+1.4. What is RFC 1327 ?
+
+ There is a large community using STD 11, RFC 822 based protocols for
+ mail services, who will wish to communicate with users of the
+ InterPersonal Messaging Service (IPMS) provided by X.400 systems, and
+ the other way around. This will also be a requirement in cases where
+ RFC 822 communities intend to make a transition to use X.400 (or the
+ other way around, which also happens), as conversion will be needed
+ to ensure a smooth service transition.
+
+ The basic function of a mail gateway can be described as follows:
+ receive a mail from one mail world, translate it into the formats of
+ the other mail world and send it out again using the routing rules
+ and protocols of that other world.
+
+ Especially if a message crosses more than one gateway, it is
+ important that all gateways have the same understanding of how things
+ should be mapped. A simple example of what could go wrong otherwise
+ is the following: A sends a message to B through a gateway and B's
+ reply to A is being routed through another gateway.
+
+ If the two gateways don't use the same mappings, it can be expected
+ that the From and To addresses in the original mail and in the answer
+ don't match, which is, to say the least, very confusing for the end-
+ users (consider what happens if automated processes communicate via
+ mail). More serious things can happen to addresses if a message
+ crosses more than one gateway on its way from the originator to the
+ recipient. As a real-life example, consider receiving a message from:
+
+ Mary Plork <MMP_+a_ARG_+lMary_Plork+r%MHS+d_A0CD8A2B01F54FDC-
+ A0CB9A2B03F53FDC%ARG_Incorporated@argmail.com>
+
+ This is not what you would call user-friendly addressing.... RFC 1327
+ describes a set of mappings that will enable a more transparent
+ interworking between systems operating X.400 (both 84 and 88) and
+ systems using RFC 822, or protocols derived from STD 11, RFC 822.
+
+ RFC 1327 describes all mappings in term of X.400(88). It defines how
+ these mappings should be applied to X.400(84) systems in its Appendix
+ G.
+
+ Some words about the history of RFC 1327: It started out in June
+ 1986, when RFC 987 defined for X.400(84) what RFC 1327 defines for
+ X.400(84 and 88). RFC 1026 specified a number of additions and
+ corrections to RFC 987. In December 1989, RFC 1138, which had a very
+ short lifetime, was the first one to deal with X.400(88). It was
+ obsoleted by RFC 1148 in March 1990. Finally, in May 1992, RFC 1327
+ obsoleted all of its ancestors.
+
+
+
+RARE Working Group on Mail and Messaging (WG-MSG) [Page 11]
+
+RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993
+
+
+2. Service Elements
+
+ Both RFC 822 and X.400 messages consist of certain service elements
+ (such as 'originator' and 'subject'). As long as a message stays
+ within its own world, the behaviour of such service elements is well
+ defined. An important goal for a gateway is to maintain the highest
+ possible service level when a message crosses the boundary between
+ the two mail worlds.
+
+ When a user originates a message, a number of services are available.
+ RFC 1327 describes, for each service elements, to what extent it is
+ supported for a recipient accessed through a gateway. There are
+ three levels of support:
+
+ - Supported: Some of the mappings are quite straight-forward,
+ such as '822.Subject:' <-> 'IPMS.Subject'.
+
+ - Not supported: There may be a complete mismatch: certain
+ service elements exist only in one of the two worlds (e.g.,
+ interpersonal notifications).
+
+ - Partially supported: When similar service elements exist in
+ both worlds, but with slightly different interpretations,
+ some tricks may be needed to provide the service over the
+ gateway border.
+
+ Apart from mapping between the service elements, a gateway must also
+ map the types and values assigned to these service elements. Again,
+ this may in certain cases be very simple, e.g., 'IA5 -> ASCII'. The
+ most complicated example is mapping address spaces. The problem is
+ that address spaces are not something static that can be defined
+ within RFC 1327. Address spaces change continuously, and they are
+ defined by certain addressing authorities, which are not always
+ parallel in the RFC 822 and the X.400 world. A valid mapping between
+ two addresses assumes however that there is 'administrative
+ equivalence' between the two domains in which the addresses exist
+ (see also [13]).
+
+ The following basic mappings are defined in RFC 1327. When going from
+ RFC 822 to X.400, an RFC 822 message and the associated 822- MTS
+ information is always mapped into an IPM (MTA, MTS, and IPMS
+ Services). Going from X.400 to RFC 822, an RFC 822 message and the
+ associated 822-MTS information may be derived from:
+
+ - A Report (MTA, and MTS Services)
+
+ - An InterPersonal Notification (IPN) (MTA, MTS, and IPMS
+ services)
+
+
+
+RARE Working Group on Mail and Messaging (WG-MSG) [Page 12]
+
+RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993
+
+
+
+ - An InterPersonal Message (IPM) (MTA, MTS, and IPMS services)
+
+ Probes (MTA Service) have no equivalent in STD 10, RFC 821 or STD 11,
+ RFC 822 and are thus handled by the gateway. The gateway's Probe
+ confirmation should be interpreted as if the gateway were the final
+ MTA to which the Probe was sent. Optionally, if the gateway uses RFC
+ 821 as an 822-MTS, it may use the results of the 'VRFY' command to
+ test whether it would be able to deliver (or forward) mail to the
+ mailbox under probe.
+
+ MTS Messages containing Content Types other than those defined by the
+ IPMS are not mapped by the gateway, and should be rejected at the
+ gateway.
+
+ Some basic examples of mappings between service elements are listed
+ below.
+
+ Service elements:
+
+ RFC 822 X.400
+ ------------------------------------------------
+ Reply-To: IPMS.Heading.reply-recipients
+ Subject: IPMS.Heading.subject
+ In-Reply-To: IPMS.Heading.replied-to-ipm
+ References: IPMS.Heading.related-IPMs
+ To: IPMS.Heading.primary-recipients
+ Cc: IPMS.Heading.copy-recipients
+
+ Service element types:
+
+ RFC 822 X.400
+ ------------------------------------------------
+ ASCII PrintableString
+ Boolean Boolean
+
+ Service element values:
+
+ RFC 822 X.400
+ ------------------------------------------------
+ oh_dear oh(u)dear
+ False 00000000
+
+ There are some mappings between service elements that are rather
+ tricky and important enough to mention in this tutorial. These are
+ the mappings of origination-related headers and some envelope fields:
+
+
+
+
+
+RARE Working Group on Mail and Messaging (WG-MSG) [Page 13]
+
+RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993
+
+
+ RFC 822 -> X.400:
+
+ - If Sender: is present, Sender: is mapped to
+ IPMS.Heading.originator, and From: is mapped to
+ IPMS.Heading.authorizing-users. If not, From: is mapped to
+ IPMS.Heading.originator.
+
+ X.400 -> RFC 822
+
+ - If IPMS.Heading.authorizing-users is present,
+ IPMS.Heading.originator is mapped to Sender:, and
+ IPMS.Heading.authorizing-users is mapped to From: . If not,
+ IPMS.Heading.originator is mapped to From:.
+
+ Envelope attributes
+
+ - RFC 1327 doesn't define how to map the MTS.OriginatorName and
+ the MTS.RecipientName (often referred to as the P1.originator
+ and P1.recipient), since this depends on which underlying 822-
+ MTS is used. In the very common case that RFC 821 (SMTP) is
+ used for this purpose, the mapping is normally as follows:
+
+ MTS.Originator-name <-> MAIL FROM:
+ MTS.Recipient-name <-> RCPT TO:
+
+ For more details, refer to RFC 1327, chapters 2.2 and 2.3.
+
+3. Address mapping
+
+ As address mapping is often considered the most complicated part of
+ mapping between service element values, this subject is given a
+ separate chapter in this tutorial.
+
+ Both RFC 822 and X.400 have their own specific address formats. RFC
+ 822 addresses are text strings (e.g., "plork@tlec.nl"), whereas X.400
+ addresses are binary encoded sets of attributes with values. Such
+ binary addresses can be made readable for a human user by a number of
+ notations; for instance:
+
+ C=zz
+ ADMD=ade
+ PRMD=fhbo
+ O=a bank
+ S=plork
+ G=mary
+
+ The rest of this chapter deals with addressing issues and mappings
+ between the two address forms in more detail.
+
+
+
+RARE Working Group on Mail and Messaging (WG-MSG) [Page 14]
+
+RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993
+
+
+3.1. X.400 addresses
+
+ As already stated above, an X.400 address is modelled as a set of
+ attributes. Some of these attributes are mandatory, others are
+ optional. Each attribute has a type and a value, e.g., the Surname
+ attribute has type IA5text, and an instance of this attribute could
+ have the value 'Kille'. Attributes are divided into Standard
+ Attributes (SAs) and Domain Defined Attributes (DDAs).
+
+ X.400 defines four basic forms of addresses ([17], 18.5), of which
+ the 'Mnemonic O/R Address' is the form that is most used, and is the
+ only form that is dealt with in this tutorial. This is roughly the
+ same address format as what in the 84 version was known as 'O/R
+ names: form 1, variant 1' ([16] 3.3.2).
+
+3.1.1. Standard Attributes
+
+ Standard Attributes (SAs) are attributes that all X.400 installations
+ are supposed to 'understand' (i.e., use for routing), for example:
+ 'country name', 'given name' or 'organizational unit'. The most
+ commonly used SAs in X.400(84) are:
+
+ surName (S)
+ givenName (G)
+ initials (I*) (Zero or more)
+ generationQualifier (GQ)
+ OrganizationalUnits (OU1 OU2 OU3 OU4)
+ OrganizationName (O)
+ PrivateDomainName (PRMD)
+ AdministrationDomainName (ADMD)
+ CountryName (C)
+
+ The combination of S, G, I* and GQ is often referred to as the
+ PersonalName (PN).
+
+ Although there is no hierarchy (of addressing authorities) defined by
+ the standards, the following hierarchy is considered natural:
+
+ PersonalName < OU4 < OU3 < OU2 < OU1 < O < P < A < C
+
+ In addition to the SAs listed above, X.400(88) defines some extra
+ attributes, the most important of which is
+
+ Common Name (CN)
+
+ CN can be used instead of or even together with PN. The problem in
+ X.400(84) was that PN (S G I* GQ) was well suited to represent
+ persons, but not roles and abstract objects, such as distribution
+
+
+
+RARE Working Group on Mail and Messaging (WG-MSG) [Page 15]
+
+RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993
+
+
+ lists. Even though postmaster clearly is a role, not someone's real
+ surname, it is quite usual in X.400(84) to address a postmaster with
+ S=postmaster. In X.400(88), the same postmaster would be addressed
+ with CN=postmaster .
+
+ The attributes C and ADMD are mandatory (i.e., they must be present),
+ and may not be empty. At least one of the attributes PRMD, O, OU, PN
+ and CN must be present.
+
+ PRMD and ADMD are often felt to be routing attributes that don't
+ really belong in addresses. As an example of how such address
+ attributes can be used for the purpose of routing, consider two
+ special values for ADMD:
+
+ - ADMD=0; (zero) should be interpreted as 'the PRMD in this
+ address is not connected to any ADMD'
+
+ - ADMD= ; (single SPACE) should be interpreted as 'the PRMD in
+ this address is reachable via any ADMD in this country'. It
+ is expected that ISO will express this 'any' value by means
+ of a missing ADMD attribute in future versions of MOTIS.
+ This representation can uniquely identify the meaning 'any',
+ as a missing or empty ADMD field as such is not allowed.
+
+ Addresses are defined in X.400 using the Abstract Syntax Notation One
+ (ASN.1). X.409 defines how definitions in ASN.1 should be encoded
+ into binary format. Note that the meaning, and thus the ASN.1
+ encoding, of a missing attribute is not the same as that of an empty
+ attribute. In addressing, this difference is often represented as
+ follows:
+
+ - PRMD=; means that this attribute is present in the address,
+ but its value is empty. Since this is not very useful, it's
+ hardly ever used. The only examples the author knows of
+ were caused by mail managers who should have had this
+ tutorial before they started defining their addresses :-)
+
+ - PRMD=@; means that this attribute is not present in the
+ address. {NB. This is only necessary if an address notation
+ (see 3.1.3) requires that every single attribute in the
+ hierarchy is somehow listed. Otherwise, a missing attribute
+ can of course be represented by simply not mentioning it.
+ This means that this syntax is mostly used in mapping rules,
+ not by end users.}
+
+ Addresses that only contain SAs are often referred to as Standard
+ Attribute Addresses (SAAs).
+
+
+
+
+RARE Working Group on Mail and Messaging (WG-MSG) [Page 16]
+
+RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993
+
+
+3.1.2. Domain Defined Attributes
+
+ Domain Defined Attributes (DDAs) can be used in addition to Standard
+ Attributes. An instance of a DDA consists of a type and a value. DDAs
+ are meant to have a meaning only within a certain context (originally
+ this was supposed to be the context of a certain management domain,
+ hence the name DDA), such as a company context.
+
+ As an example, a company might want to define a DDA for describing
+ internal telephone numbers: DDA type=phone value=9571.
+
+ A bit tricky is the use of DDAs to encode service element types or
+ values that are only available on one side of a service gateway. The
+ most important examples of such usage are defined in:
+
+ RFC 1327 (e.g., DDA type=RFC-822 value=u(u)ser(a)isode.com)
+
+ RFC 1328 (e.g., DDA type=CommonName value=mhs-discussion-list)
+
+ Addresses that contain both SAs and DDAs are often referred to as DDA
+ addresses.
+
+3.1.3. X.400 address notation
+
+ X.400 only prescribes the binary encoding of addresses, it doesn't
+ standardise how such addresses should be written on paper or what
+ they should look like in a user interface on a computer screen.
+ There exist a number of recommendations for X.400 address
+ representation though.
+
+ - JTC proposed an annex to CCITT Rec. F.401 and ISO/IEC 10021-2,
+ called 'Representation of O/R addresses for human usage'. According
+ to this proposal, an X.400 address would look as follows:
+
+ G=jo; S=plork; O=a bank; OU1=owe; OU2=you; P=fhbo; A=ade; C=zz
+
+ Note that in this format, the order of O and the OUs is exactly
+ the opposite of what one would expect intuitively (the attribute
+ hierarchy is increasing from left to right, except for the O and
+ OUs, where it's right to left. The reasoning behind this is that
+ this sequence is following the example of a postal address). This
+ proposal has been added (as a recommendation) to the 1992 version
+ of the standards.
+
+ - Following what was originally used in the DFN-EAN software, most
+ EAN versions today use an address representation similar to the JTC
+ proposal, with a few differences:
+
+
+
+
+RARE Working Group on Mail and Messaging (WG-MSG) [Page 17]
+
+RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993
+
+
+ - natural ordering for O and OUs
+ - no numbering of OUs.
+ - allows writing ADMD and PRMD instead of A and P
+
+ The address in the example above could, in EAN, be represented as:
+
+ G=jo; S=plork; OU=you; OU=owe; O=a bank; PRMD=fhbo; ADMD=ade; C=zz
+
+ This DFN-EAN format is still often referred to as _the_ 'readable
+ format'.
+
+ - The RARE Working Group on Mail and Messaging, WG-MSG, has made a
+ recommendation that is very similar to the DFN-EAN format, but with
+ the hierarchy reversed. Further, ADMD and PRMD are used instead of
+ A and P. This results in the address above being represented as:
+
+ C=zz; ADMD=ade; PRMD=fhbo; O=a bank; OU=owe; OU=you; S=plork; G=jo
+
+ This format is recognised by most versions of the EAN software. In
+ the R&D community, this is one of the most popular address
+ representations for business cards, letter heads, etc. It is also
+ the format that will be used for the examples in this tutorial.
+ (NB. The syntax used here for describing DDAs is as follows:
+ DD.'type'='value', e.g., DD.phone=9571)
+
+ - RFC 1327 defines a slash separated address representation:
+
+ /G=jo/S=plork/OU=you/OU=owe/O=a bank/P=fhbo/A=ade/C=zz/
+
+ Not only is this format used by the PP software, it is also
+ widespread for business cards and letter heads in the R&D
+ community.
+
+ - RFC 1327 finally defines yet another format for X.400 _domains_
+ (not for human users):
+
+ OU$you.OU$owe.O$a bank.P$fhbo.A$ade.C$zz
+
+ The main advantage of this format is that it is better machine-
+ parseble than the others, which also immediately implies its main
+ disadvantage: it is barely readable for humans. Every attribute
+ within the hierarchy should be listed, thus a missing attribute
+ must be represented by the '@' sign
+ (e.g., $a bank.P$@.A$ade.C$zz).
+
+ - Paul-Andre Pays (INRIA) has proposed a format that combines the
+ readability of the JTC format with the parsebility of the RFC 1327
+ domain format. Although a number of operational tools within the GO-
+
+
+
+RARE Working Group on Mail and Messaging (WG-MSG) [Page 18]
+
+RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993
+
+
+ MHS community are already based on (variants of) this proposal, its
+ future is still uncertain.
+
+3.2. RFC 822 addresses
+
+ An RFC 822 address is an ASCII string of the following form:
+
+ localpart@domainpart
+
+ "domainpart" is sub-divided into
+
+ domainpart = sdom(n).sdom(n-1)....sdom(2).sdom(1).dom
+
+ "sdom" stands for "subdomain", "dom" stands for "top-level-domain".
+
+ "localpart" ;is normally a login name, and thus typically is a
+ surname or an abbreviation for this. It can also designate a local
+ distribution list.
+
+ The hierarchy (of addressing authorities) in an RFC 822 address is
+ as follows:
+
+ localpart < sdom(n) < sdom(n-1) <...< dom
+
+ Some virtual real-life examples:
+
+ joemp@tlec.nl
+ tsjaka.kahn@walhalla.diku.dk
+ a13_vk@cs.rochester.edu
+
+ In the above examples, 'nl', 'dk', and 'edu' are valid,
+ registered, top level domains. Note that some networks that have
+ their own addressing schemes are also reachable by way of 'RFC
+ 822-like' addressing. Consider the following addresses:
+
+ oops!user (a UUCP address)
+ V13ENZACC@CZKETH5A (a BITNET address)
+
+ These addresses can be expressed in RFC 822 format:
+
+ user@oops.uucp
+ V13ENZACC@CZKETH5A.BITNET
+
+ Note that the domains '.uucp' and '.bitnet' have no registered
+ Internet routing. Such addresses must always be routed to a gateway
+ (how this is done is outside the scope of this tutorial).
+
+ As for mapping such addresses to X.400, there is no direct mapping
+
+
+
+RARE Working Group on Mail and Messaging (WG-MSG) [Page 19]
+
+RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993
+
+
+ defined between X.400 on the one hand and UUCP and BITNET on the
+ other, so they are normally mapped to RFC 822 style first, and then
+ to X.400 if needed.
+
+3.3. RFC 1327 address mapping
+
+ Despite the difference in address formats, the address spaces defined
+ by RFC 822 and X.400 are quite similar. The most important parallels
+ are:
+
+ - both address spaces are hierarchical
+ - top level domains and country codes are often the same
+ - localparts and surnames are often the same
+
+ This similarity can of course be exploited in address mapping
+ algorithms. This is also done in RFC 1327 (NB only in the exception
+ mapping algorithm. See chapter 3.3.2).
+
+ Note that the actual mapping algorithm is much more complicated than
+ shown below. For details, see RFC 1327, chapter 4.
+
+3.3.1. Default mapping
+
+ The default RFC 1327 address mapping can be visualised as a function
+ with input and output parameters:
+
+ address information of the gateway performing the mapping
+ |
+ v
+ +-----------------+
+ RFC 822 address <--->| address mapping | <---> X.400 address
+ +-----------------+
+
+ I.e., to map an address from X.400 to RFC 822 or vice versa, the only
+ extra input needed is the address information of the local gateway.
+
+3.3.1.1. X.400 -> RFC 822
+
+ There are two kinds of default address mapping from X.400 to RFC 822:
+ one to map a real X.400 address to RFC 822, and another to decode an
+ RFC 822 address that was mapped to X.400 (i.e., to reverse the
+ default RFC 822 -> X.400 mapping).
+
+ To map a real X.400 address to RFC 822, the slash separated notation
+ of the X.400 address (see chapter 3.1.) is mapped to 'localpart', and
+ the local RFC 822 domain of the gateway that performs the mapping is
+ used as the domain part. As an example, the gateway 'gw.switch.ch'
+ would perform the following mappings:
+
+
+
+RARE Working Group on Mail and Messaging (WG-MSG) [Page 20]
+
+RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993
+
+
+ C=zz; ADMD=ade; PRMD=fhbo; O=tlec; S=plork; ->
+ /C=zz/ADMD=ade/PRMD=fhbo/O=tlec/S=plork/@gw.switch.ch
+
+ C=zz; ADMD=ade; PRMD=fhbo; O=a bank; S=plork->
+ "/C=zz/ADMD=ade/PRMD=fhbo/O=a bank/S=plork/"@gw.switch.ch
+
+ The quotes in the second example are mandatory if the X.400 address
+ contains spaces, otherwise the syntax rules for the RFC 822 localpart
+ would be violated.
+
+ This default mapping algorithm is generally referred to as 'left-
+ hand-side encoding'.
+
+ To reverse the default RFC 822 -> X.400 mapping (see chapter
+ 3.3.1.2): if the X.400 address contains a DDA of the type RFC-822,
+ the SAs can be discarded, and the value of this DDA is the desired
+ RFC 822 address (NB. Some characters in the DDA value must be decoded
+ first. See chapter 3.3.1.2.). For example, the gateway
+
+ DD.RFC-822=bush(a)dole.us; C=nl; ADMD=tlec; PRMD=GW
+ ->
+ bush@dole.us
+
+3.3.1.2. RFC 822 -> X.400
+
+ There are also two kinds of default address mapping from RFC 822 to
+ X.400: one to map a real RFC 822 address to X.400, and another to
+ decode an X.400 address that was mapped to RFC 822 (i.e., to reverse
+ the default X.400 -> RFC 822 mapping).
+
+ To map a real RFC 822 address to X.400, the RFC 822 address is
+ encoded in a DDA of type RFC-822 , and the SAs of the local gateway
+ performing the mapping are added to form the complete X.400 address.
+ This mapping is generally referred to as 'DDA mapping'. As an
+ example, the gateway 'C=nl; ADMD=tlec; PRMD=GW' would perform the
+ following mapping:
+
+ bush@dole.us ->
+ DD.RFC-822=bush(a)dole.us; C=nl; ADMD=tlec; PRMD=GW
+
+ As for the encoding/decoding of RFC 822 addresses in DDAs, it is
+ noted that RFC 822 addresses may contain characters (@ ! % etc.) that
+ cannot directly be represented in a DDA. DDAs are of the restricted
+ character set type 'PrintableString', which is a subset of IA5
+ (=ASCII). Characters not in this set need a special encoding. Some
+ examples (For details, refer to RFC 1327, chapter 3.4.):
+
+
+
+
+
+RARE Working Group on Mail and Messaging (WG-MSG) [Page 21]
+
+RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993
+
+
+ 100%name@address -> DD.RFC-822;=100(p)name(a)address
+ u_ser!name@address -> DD.RFC-822;=u(u)ser(b)name(a)address
+
+ To decode an X.400 address that was mapped to RFC 822: if the RFC 822
+ address has a slash separated representation of a complete X.400
+ mnemonic O/R address in its localpart, that address is the result of
+ the mapping. As an example, the gateway 'gw.switch.ch' would perform
+ the following mapping:
+
+ /C=zz/ADMD=ade/PRMD=fhbo/O=tlec/S=plork/G=mary/@gw.switch.ch
+ ->
+ C=zz; ADMD=ade; PRMD=fhbo; O=tlec; S=plork; G=mary
+
+3.3.2. Exception mapping according to mapping tables
+
+ Chapter 3.3.1. showed that it is theoretically possible to use RFC
+ 1327 with default mapping only. Although this provides a very simple,
+ straightforward way to map addresses, there are some very good
+ reasons not to use RFC 1327 this way:
+
+ - RFC 822 users are used to writing simple addresses of the
+ form 'localpart@domainpart'. They often consider X.400
+ addresses, and thus also the left-hand-side encoded
+ equivalents, as unnecessarily long and complicated. They
+ would rather be able to address an X.400 user as if she had a
+ 'normal' RFC 822 address. For example, take the mapping
+
+ C=zz; ADMD=ade; PRMD=fhbo; O=tlec; S=plork; ->
+ /C=zz/ADMD=ade/PRMD=fhbo/O=tlec/S=plork/@gw.switch.ch
+
+ from chapter 3.3.1.1. RFC 822 users would find it much more
+ 'natural' if this address could be expressed in RFC 822 as:
+
+ plork@tlec.fhbo.ade.nl
+
+ - X.400 users are used to using X.400 addresses with SAs only.
+ They often consider DDA addresses as complicated, especially
+ if they have to encode the special characters, @ % ! etc,
+ manually. They would rather be able to address an RFC 822
+ user as if he had a 'normal' X.400 address. For example, take
+ the mapping
+
+ bush@dole.us
+ ->
+ DD.RFC-822=bush(a)dole.us;
+ C=nl; ADMD= ; PRMD=tlec; O=gateway
+
+ from chapter 3.3.1.2. X.400 users would find it much more
+
+
+
+RARE Working Group on Mail and Messaging (WG-MSG) [Page 22]
+
+RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993
+
+
+ 'natural' if this address could be expressed in X.400 as:
+
+ C=us; ADMD=dole; S=bush
+
+ - Many organisations are using both RFC 822 and X.400
+ internally, and still want all their users to have a simple,
+ unique address in both mail worlds. Note that in the default
+ mapping, the mapped form of an address completely depends on
+ which gateway performed the mapping. This also results in a
+ complication of a more technical nature:
+
+ - The tricky 'third party problem'. This problem need not
+ necessarily be understood to read the rest of this chapter.
+ If it looks too complicated, please feel free to skip it
+ until you are more familiar with the basics.
+
+ The third party problem is a routing problem caused by
+ mapping. As an example for DDA mappings (the example holds
+ just as well for left-hand-side encoding), consider the
+ following situation (see Fig. 3.1.): RFC 822 user X in
+ country A sends a message to two recipients: RFC 822 user Y,
+ and X.400 user Z, both in country B:
+
+ From: X@A
+ To: Y@B ,
+ /C=B/.../S=Z/@GW.A
+
+ Since the gateway in country A maps all addresses in the
+ message, Z will see both X's and Y's address as DDA-encoded
+ RFC 822 addresses, with the SAs of the gateway in country A:
+
+ From: DD.RFC-822=X(a)A; C=A;....;O=GW
+ To: DD.RFC-822=Y(a)B; C=A;....;O=GW ,
+ C=B;...;S=Z
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+RARE Working Group on Mail and Messaging (WG-MSG) [Page 23]
+
+RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993
+
+
+
+ | ------------ ---------
+ | |X: RFC 822|<------->|gateway|
+ | ------------ ---------
+ | A | ^
+ \ | |
+ \---------------------------------------------
+ | |
+ /---------------------------------------------
+ / | |
+ | B | v
+ | | -----------
+ | | |Z: X.400 |
+ | | -----------
+ | | .
+ | | .
+ | | .
+ | | .
+ | | .
+ | v v
+ | ------------ ---------
+ | |Y: RFC 822|<........|gateway|
+ | ------------ ---------
+
+ Fig. 3.1 The third party problem
+
+
+ Now if Z wants to 'group reply' to both X and Y, his reply to Y
+ will be routed over the gateway in country A, even though Y is
+ located in the same country:
+
+ From: C=B;...;S=Z
+ To: DD.RFC-822=Y(a)B; C=A;....;O=GW ,
+ DD.RFC-822=X(a)A; C=A;....;O=GW
+
+ The best way to travel for a message from Z to Y would of
+ course have been over the gateway in country B:
+
+ From: C=B;...;S=Z
+ To: DD.RFC-822=Y(a)B; C=B;....;O=GW ,
+ DD.RFC-822=X(a)A; C=A;....;O=GW
+
+ The third party problem is caused by the fact that routing
+ information is mapped into addresses.
+
+ Ideally, the third party problem shouldn't exist. After all,
+ address mapping affects addresses, and an address is not a
+ route.... The reality is different however. For instance, very
+
+
+
+RARE Working Group on Mail and Messaging (WG-MSG) [Page 24]
+
+RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993
+
+
+ few X.400 products are capable to route messages on the
+ contents of a DDA (actually, only RFC 1327 gateways will be
+ able to interpret this type of DDA, and who says that the reply
+ will pass a local gateway on its route back?). Similar
+ limitations hold for the other direction: an RFC 822 based
+ mailer is not even allowed (see [5]) to make routing decisions
+ of the content of a left-hand-side encoded X.400 address if the
+ domain part is not its own. So in practice, addressing and
+ (thus also mapping) will very well affect routing.
+
+ To make mapping between addresses more user friendly, and to avoid
+ the problems shown above, RFC 1327 allows for overruling the default
+ left-hand-side encoding and DDA mapping algorithms. This is done by
+ specifying associations (mapping rules) between certain domainparts
+ and X.400 domains. An X.400 domain (for our purposes; CCITT has a
+ narrower definition...) consists of the domain-related SAs of a
+ Mnemonic O/R address (i.e., all SAs except PN and CN). The idea is to
+ use the similarities between both address spaces, and directly map
+ similar address parts onto each other. If, for the domain in the
+ address to be mapped, an explicit mapping rule can be found, the
+ mapping is performed between:
+
+ localpart <-> PersonalName
+ domainpart <-> X.400 domain
+
+ The address information of the gateway is only used as an input
+ parameter if no mapping rule can be found, i.e., if the address
+ mapping must fall back to its default algorithm.
+
+ The complete mapping function can thus be visualised as follows:
+
+
+ address information of the gateway performing the mapping
+ |
+ v
+ +-----------------+
+ RFC 822 address <--->| address mapping | <---> X.400 address
+ +-----------------+
+ ^
+ |
+ domain associations (mapping rules)
+
+3.3.2.1. PersonalName and localpart mapping
+
+ Since the mapping between these address parts is independent of the
+ mapping rules that are used, and because it follows a simple, two-
+ way algorithmic approach, this subject is discussed in a separate
+ sub-chapter first.
+
+
+
+RARE Working Group on Mail and Messaging (WG-MSG) [Page 25]
+
+RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993
+
+
+ The X.400 PersonalName consists of givenName, initials, and surName.
+ RFC 1327 assumes that generationQualifier is not used.
+
+ To map a localpart to an X.400 PN, the localpart is scanned for dots,
+ which are considered delimiters between the components of PN, and
+ also between single initials. In order not to put too much detail in
+ this tutorial, only a few examples are shown here. For the detailed
+ algorithm, see RFC 1327, chapter 4.2.1.
+
+ Marshall.Rose <-> G=Marshall;S=Rose
+ M.T.Rose <-> I=MT;S=Rose
+ Marshall.M.T.Rose <-> G=Marshall;I=MT;S=Rose
+
+ To map an X.400 PN to an RFC 822 localpart, take the non-empty PN
+ attributes, put them into their hierarchical order (G I* S), and
+ connect them with periods.
+
+ Some exceptions are caused by the fact that left-hand-side encoding
+ can also be mixed with exception mapping. This is shown in more
+ detail in the following sub-chapters.
+
+3.3.2.2. X.400 domain and domainpart mapping
+
+ A mapping rule associates two domains: an X.400 domain and an RFC 822
+ domain. The X.400 domain is written in the RFC 1327 domain notation
+ (See 3.1.3.), so that both domains have the same hierarchical order.
+ The domains are written on one line, separated by a '#' sign. For
+ instance:
+
+ arcom.ch#ADMD$arcom.C$ch#
+ PRMD$tlec.ADMD$ade.C$nl#tlec.nl#
+
+ A mapping rule must at least contain a top level domain and a country
+ code. If an address must be mapped, a mapping rule with the longest
+ domain match is sought. The associated domain in the mapping rule is
+ used as the domain of the mapped address. The remaining domains are
+ mapped one by one following the natural hierarchy. Concrete examples
+ are shown in the following subchapters.
+
+3.3.2.2.1. X.400 -> RFC 822
+
+ As an example, assume the following mapping rule is defined:
+
+ PRMD$tlec.ADMD$ade.C$nl#tlec.nl#
+
+
+
+
+
+
+
+RARE Working Group on Mail and Messaging (WG-MSG) [Page 26]
+
+RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993
+
+
+ Then the address C=nl; ADMD=ade; PRMD=tlec; O=you; OU=owe; S=plork
+
+ S OU O PRMD ADMD Country
+ | | | | | |
+ plork owe you tlec ade nl
+
+ would be mapped as follows. The Surname 'plork' is mapped to the
+ localpart 'plork', see chapter 3.3.2.1. The domain
+
+ localpart
+ | sdom3
+ | | sdom2
+ | | | sdom1
+ | | | | top-level-domain
+ | | | | |
+ plork@ tlec.nl
+
+ The remaining SAs (O and one OU) are mapped one by one following the
+ natural hierarchy: O is mapped to sdom2, OU is mapped to sdom3:
+
+ localpart
+ | sdom3
+ | | sdom2
+ | | | sdom1
+ | | | | top-level-domain
+ | | | | |
+ plork@owe.you.tlec.nl
+
+ Thus the mapped address is:
+
+ plork@owe.you.tlec.nl
+
+ The table containing the listing of all such mapping rules, which is
+ distributed to all gateways world-wide, is normally referred to as
+ 'mapping table 1'. Other commonly used filenames (also depending on
+ which software your are using) are:
+
+ 'or2rfc'
+ 'mapping 1'
+ 'map1'
+ 'table 1'
+ 'X2R'
+
+ As already announced, there is an exceptional case were localpart and
+ PN are not directly mapped onto each other: sometimes it is necessary
+ to use the localpart for other purposes. If the X.400 address
+ contains attributes that would not allow for the simple mapping:
+
+
+
+
+RARE Working Group on Mail and Messaging (WG-MSG) [Page 27]
+
+RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993
+
+
+ localpart <-> PersonalName
+ domainpart <-> X.400 domain
+
+ (e.g., spaces are not allowed in an RFC 822 domain, GQ and CN cannot
+ be directly mapped into localpart, DDAs of another type than RFC-
+ 822), such attributes, together with the PN, are left-hand-side
+ encoded. The domainpart must still be mapped according to the mapping
+ rule as far as possible. This probably needs some examples:
+
+ C=nl; ADMD=ade; PRMD=tlec; O=owe; OU=you; S=plork; GQ=jr
+ ->
+ /S=plork/GQ=jr/@you.owe.tlec.nl
+
+ C=nl; ADMD=ade; PRMD=tlec; O=owe; OU=spc ctr; OU=u; S=plork
+ ->
+ "/S=plork/OU=u/OU=spc ctr/"@owe.tlec.nl
+
+ Note that in the second example, 'O=owe' is still mapped to a
+ subdomain following the natural hierarchy. The problems start with
+ the space in 'OU=spc ctr'.
+
+3.3.2.2.2. RFC 822 -> X.400
+
+ As an example, assume the following mapping rule is defined:
+
+ tlec.nl#PRMD$tlec.ADMD$ade.C$nl#
+
+ Then the address 'plork@owe.you.tlec.nl' :
+
+ localpart
+ | sdom3
+ | | sdom2
+ | | | sdom1
+ | | | | top-level-domain
+ | | | | |
+ plork@owe.you.tlec.nl
+
+ would be mapped as follows.
+
+ The localpart 'plork' is mapped to 'S=plork', see chapter 3.3.2.1.
+
+ The domain 'tlec.nl' is mapped according to the mapping rule:
+
+ S OU OU O PRMD ADMD Country
+ | | | |
+ plork tlec ade nl
+
+ The remaining domains (owe.you) are mapped one by one following the
+
+
+
+RARE Working Group on Mail and Messaging (WG-MSG) [Page 28]
+
+RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993
+
+
+ natural hierarchy: sdom2 is mapped to O, sdom3 is mapped to OU:
+
+ S OU OU O PRMD ADMD Country
+ | | | | | |
+ plork | | tlec ade nl
+ owe you
+
+ Thus the mapped address is (in a readable notation):
+
+ C=nl; ADMD=ade; PRMD=tlec; O=you; OU=owe; S=plork
+
+ Had there been any left-hand-side encoded SAs in the localpart that
+ didn't represent a complete mnemonic O/R address, the localpart would
+ be mapped to those SAs. E.g.,
+
+ "/S=plork/GQ=jr/OU=u/OU=spc ctr/"@owe.tlec.nl
+ ->
+ C=nl; ADMD=ade; PRMD=tlec; O=owe; OU=space ctr;
+ OU=u; S=plork; GQ=jr
+
+ This is necessary to reverse the special use of localpart to left-
+ hand-side encode certain attributes. See 3.3.2.2.1.
+
+ You might ask yourself by now why such rules are needed at all. Why
+ don't we just use map1 in the other direction? The problem is that a
+ symmetric mapping function (a bijection) would indeed be ideal, but
+ it's not feasible. Asymmetric mappings exist for a number of reasons:
+
+ - To make sure that uucp addresses etc. get routed over local
+ gateways.
+
+ - Preferring certain address forms, while still not forbidding
+ others to use another form. Examples of such reasons are:
+
+ - Phasing out old address forms.
+
+ - If an RFC 822 address is mapped to ADMD= ; it means that
+ the X.400 mail can be routed over any ADMD in that
+ country. One single ADMD may of course send out an
+ address containing: ADMD=ade; . It must also be possible
+ to map such an address back.
+
+ So we do need mapping rules from RFC 822 to X.400 too. The table
+ containing the listing of all such mapping rules, which is
+ distributed to all gateways world-wide, is normally referred to as on
+ which software your are using) are:
+
+
+
+
+
+RARE Working Group on Mail and Messaging (WG-MSG) [Page 29]
+
+RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993
+
+
+ 'rfc2or'
+ 'mapping 2'
+ 'map2'
+ 'table 2'
+ 'R2X'
+
+ If the RFC 822 localpart and/or domainpart contain characters that
+ would not immediately fit in the value of a PN attribute (! % _), the
+ mapping algorithm falls back to DDA mapping. In this case, the SAs
+ that will be used are still determined by mapping the domainpart
+ according to the mapping rule. In our case:
+
+ 100%user@work.tlec.nl
+ ->
+ DD.RFC-822=100(p)user(a)work.tlec.nl;
+ C=nl; ADMD=ade; PRMD=tlec; O=work
+
+ If no map2 rule can be found, a third table of rules is scanned: the
+ gateway table. This table has the same syntax as mapping table 2, but
+ its semantics are different. First of all, a domain that only has an
+ entry in the gateway table is always mapped into an RFC 822 DDA. For
+ a domain that is purely RFC 822 based, but whose mail may be relayed
+ over an X.400 network, the gateway table associates with such a
+ domain the SAs of the gateway to which the X.400 message should be
+ routed. That gateway will then be responsible for gatewaying the
+ message back into the RFC 822 world. E.g., if we have the gateway
+ table entry:
+
+ gov#PRMD$gateway.ADMD$Internet.C$us#
+
+ (and we assume that no overruling map2 rule for the top level domain
+ 'gov' exists), this would force all gateways to perform the following
+ mapping:
+
+ bush@dole.gov
+ ->
+ DD.RFC-822=bush(a)dole.gov;
+ C=us; ADMD=Internet; PRMD=gateway
+
+ This is very similar to the default DDA mapping, except the SAs are
+ those of a gateway that has declared to be responsible for a certain
+ RFC 822 domain, not those of the local gateway. And thus, this
+ mechanism helps avoid the third party problem discussed in chapter
+ 3.2.2.
+
+ The table containing the listing of all such gateway rules, which is
+ distributed to all gateways world-wide, is normally referred to as
+ the 'gateway table'. Other commonly used filenames (also depending on
+
+
+
+RARE Working Group on Mail and Messaging (WG-MSG) [Page 30]
+
+RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993
+
+
+ which software your are using) are:
+
+ 'rfc1148gate' {From the predecessor of RFC 1327, RFC 1148}
+ 'gate table'
+ 'GW'
+
+ Only when no rule at all (map2 or gateway rule) is defined for a
+ domain, the algorithm falls back to the default DDA mapping as
+ described in 3.3.1.2.
+
+3.4. Table co-ordination
+
+ As already stated, the use of mapping tables will only function
+ smoothly if all gateways in the world use the same tables. On the
+ global level, the collection and distribution of RFC 1327 address
+ mapping tables is co-ordinated by the MHS Co-ordination Service:
+
+ SWITCH Head Office
+ MHS Co-ordination Service
+ Limmatquai 138
+ CH-8001 Zurich, Europe
+ Tel. +41 1 268 1550
+ Fax. +41 1 268 1568
+
+ RFC 822: project-team@switch.ch
+ X.400: C=ch;ADMD=arcom;PRMD=switch;O=switch;S=project-team;
+
+ The procedures for collection and distribution of mapping rules can
+ be found on the MHS Co-ordination Server, in the directory
+ "/procedures". Appendix D describes how this server can be accessed.
+
+ If you want to define mapping rules for your own local domain, you
+ can find the right contact person in your country or network (the
+ gateway manager) on the same server, in the directory "/mhs-
+ services".
+
+3.5. Local additions
+
+ Since certain networks want to define rules that should only be used
+ within their networks, such rules should not be distributed world-
+ wide. Consider two networks that both want to reach the old top-
+ level-domain 'arpa' over their local gateway. They would both like to
+ use a mapping 2 rule for this purpose:
+
+ TLec in NL: arpa#PRMD$gateway.ADMD$tlec.C$nl#
+
+ SWITCH in CH: arpa#PRMD$gateway.ADMD$switch.C$ch#
+
+
+
+
+RARE Working Group on Mail and Messaging (WG-MSG) [Page 31]
+
+RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993
+
+
+ (You may have noticed correctly that they should have defined such
+ rules in the gateway table, but for the sake of the example, we
+ assume they defined it in mapping table 2. This was the way things
+ were done in the days of RFC 987, and many networks are still doing
+ it this way these days.)
+
+ Since a mapping table cannot contain two mapping rules with the same
+ domain on the left hand side, such 'local mappings' are not
+ distributed globally. There exists a RARE draft proposal [13] which
+ defines a mechanism for allowing and automatically dealing with
+ conflicting mapping rules, but this mechanism has not been
+ implemented as to date. After having received the global mapping
+ tables from the MHS Co-ordination Service, many networks add 'local'
+ rules to map2 and the gateway table before installing them on their
+ gateways. Note that the reverse mapping 2 rules for such local
+ mappings _are_ globally unique, and can thus be distributed world-
+ wide. This is even necessary, because addresses that were mapped with
+ a local mapping rule may leak out to other networks (here comes the
+ third party problem again...). Such other networks should at least be
+ given the possibility to map the addresses back. So the global
+ mapping table 1 would in this case contain the two rules:
+
+ PRMD$gateway.ADMD$tlec.C$nl#arpa#
+ PRMD$gateway.ADMD$switch.C$ch#arpa#
+
+ Note that if such rules would have been defined as local gate table
+ entries instead of map2 entries, there would have been no need to
+ distribute the reverse mappings world-wide (the reverse mapping of a
+ DDA encoded RFC 822 address is simply done by stripping the SAs, see
+ 3.3.1.1.).
+
+3.6. Product specific formats
+
+ Not all software uses the RFC 1327 format of the mapping tables
+ internally. Almost all formats allow comments on a line starting with
+ a # sign. Some examples of different formats:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+RARE Working Group on Mail and Messaging (WG-MSG) [Page 32]
+
+RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993
+
+
+ RFC 1327
+
+ # This is pure RFC 1327 format
+ # table 1: X.400 -> RFC 822
+ #
+ PRMD$tlec.ADMD$ade.C$nl#tlec.nl#
+ # etc.
+
+ # table 2: RFC 822 -> X.400
+ #
+ arcom.ch#ADMD$arcom.C$ch#
+ # etc.
+
+ EAN
+
+ # This is EAN format
+ # It uses the readable format for X.400 domains and TABs
+ # to make a 'readable mapping table format'.
+ # table 1: X.400 -> RFC 822
+ #
+ P=tlec; A=ade; C=nl; # tlec.nl
+ # etc.
+
+ # table 2: RFC 822 -> X.400
+ #
+ arcom.ch # A=arcom; C=ch;
+ # etc.
+
+ PP
+
+ # This is PP format
+ # table 1: X.400 -> RFC 822
+ #
+ PRMD$tlec.ADMD$ade.C$nl:tlec.nl
+ # etc.
+
+ # table 2: RFC 822 -> X.400
+ #
+ arcom.ch:ADMD$arcom.C$ch
+ # etc.
+
+ Most R&D networks have tools to automatically generate these formats
+ from the original RFC 1327 tables;, some even distribute the tables
+ within their networks in several formats. If you need mapping tables
+ in a specific format, please contact your national or R&D network's
+ gateway manager. See chapter 3.4.
+
+
+
+
+
+RARE Working Group on Mail and Messaging (WG-MSG) [Page 33]
+
+RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993
+
+
+3.7. Guidelines for mapping rule definition
+
+ Beware that defining mapping rules without knowing what you are doing
+ can be disastrous not only for your network, but also for others. You
+ should be rather safe if you follow at least these rules:
+
+ - First of all, read this tutorial;.
+
+ - Avoid local mappings; prefer gate table entries. (See chapter
+ 3.5)
+
+ - Make sure any domain you map to can also be mapped back;.
+
+ - Aim for symmetry.
+
+ - Don't define a gateway table entry if the same domain already
+ has a map2 entry. Such a rule would be redundant.
+
+ - Map to "ADMD=0;" if you will not be connected to any ADMD for
+ the time being.
+
+ - Only map to "ADMD= ;" if you are indeed reachable through
+ _any_ ADMD in your country.
+
+ - Mind the difference between "PRMD=;" and "PRMD=@;" and make
+ sure which one you need. (Try to avoid empty or unused
+ attributes in the O/R address hierarchy from the beginning!)
+
+ - Don't define mappings for domains over which you have no
+ naming authority.
+
+ - Before defining a mapping rule, make sure you have the
+ permission from the naming authority of the domain you want
+ to map to. Normally, this should be the same organisation as
+ the mapping authority of the domain in the left hand side of
+ the mapping rule. This principle is called 'administrative
+ equivalence'.
+
+ - Avoid redundant mappings. E.g., if all domains under 'tlec.nl'
+ are in your control, don't define:
+
+ first.tlec.nl#O$first.PRMD$tlec.ADMD$ade.C$nl#
+ last.tlec.nl#O$last.PRMD$tlec.ADMD$ade.C$nl#
+ always.tlec.nl#O$always.PRMD$tlec.ADMD$ade.C$nl#
+
+ but rather have only one mapping rule:
+
+ tlec.nl#PRMD$tlec.ADMD$ade.C$nl#
+
+
+
+RARE Working Group on Mail and Messaging (WG-MSG) [Page 34]
+
+RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993
+
+
+
+ - Before introducing a new mapped version of a domain, make
+ sure the world can route to that mapped domain;.
+
+ E.g., If you are operating a PRMD: C=zz; ADMD=ade; PRMD=ergo;
+ and you want to define the mapping rules:
+
+ map1: PRMD$ergo.ADMD$ade.C$zz#ergo.zz#
+ map2: ergo.zz#PRMD$ergo.ADMD$ade.C$zz#
+
+ Make sure that ergo.zz (or at least all of its subdomains) is
+ DNS routeable (register an MX or A record) and will be routed
+ to a gateway that agreed to route the messages from the
+ Internet to you over X.400.
+
+ In the other direction, if you are operating the Internet
+ domain cs.woodstock.edu, and you want to define a mapping for
+ that domain:
+
+ map2: cs.woodstock.edu#O$cs.PRMD$woodstock.ADMD$ .C$us#
+ map1: O$cs.PRMD$woodstock.ADMD$ .C$us#cs.woodstock.edu#
+
+ Make sure that C=us; ADMD= ; PRMD=woodstock; O=cs; (or at
+ least all of its subdomains) is routeable in the X.400 world,
+ and will be routed to a gateway that agreed to route the
+ messages from X.400 to your RFC 822 domain over SMTP. Within
+ the GO-MHS community, this would be done by registering a
+ line in a so-called domain document, which will state to
+ which mail relay this domain should be routed.
+
+ Co-ordinate any such actions with your national or MHS'
+ gateway manager. See chapter 3.4.
+
+4. Conclusion
+
+ Mail gatewaying remains a complicated subject. If after reading this
+ tutorial, you feel you understand the basics, try solving some real-
+ life problems. This is indeed a very rewarding area to work in: even
+ after having worked with it for many years, you can make amazing
+ discoveries every other week........
+
+
+
+
+
+
+
+
+
+
+
+RARE Working Group on Mail and Messaging (WG-MSG) [Page 35]
+
+RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993
+
+
+Appendix A. References
+
+ [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
+ USC/Information Sciences Institute, August 1982.
+
+ [2] Crocker, D., "Standard for the Format of ARPA Internet Text
+ Messages", STD 11, RFC 822, University of Delaware, August 1982.
+
+ [3] Mockapetris, P., "Domain Names - Concepts and Facilities", and
+ "Domain Names - Implementation and Specification", STD 13, RFCs
+ 1034 and 1035, USC/Information Sciences Institute, November
+ 1987.
+
+ [4] Kille, S., "Mapping Between X.400 and RFC 822", RFC 987, UK
+ Academic Community Report (MG.19), UCL, June 1986.
+
+ [5] Braden, R., Editor, "Requirements for Internet Hosts --
+ Application and Support", STD 3, RFC 1123, USC/Information
+ Sciences Institute, October 1989.
+
+ [6] Postel, J., Editor, "Internet Official Protocol Standards", STD
+ 1, RFC 1500, USC/Information Sciences Institute, August 1993.
+
+ [7] Chapin, L., Chair, "The Internet Standards Process", RFC 1310,
+ Internet Activities Board, March 1992.
+
+ [8] Kille, S., "Mapping between X.400(1988) / ISO 10021 and RFC
+ 822", RFC 1327 / RARE RTR 2, University College London, May
+ 1992.
+
+ [9] Kille, S., "X.400 1988 to 1984 downgrading", RFC 1328 / RARE RTR
+ 3, University College London, May 1992.
+
+ [10] Plattner, B., and H. Lubich, "Electronic Mail Systems and
+ Protocols Overview and Case Study", Proceedings of the IFIP WG
+ 6.5 International working conference on message handling systems
+ and distributed applications; Costa Mesa 1988; North-Holland,
+ 1989.
+
+ [11] Houttuin, J., "@route:100%name@address, a practical guide to MHS
+ configuration", Top-Level EC, 1993, (not yet published).
+
+ [12] Alvestrand, H., "Frequently asked questions on X.400", regularly
+ posted on USEnet in newsgroup comp.protocols.iso.x400.
+
+ [13] Houttuin, J., Hansen, K., and S. Aumont, "RFC 1327 Address
+ Mapping Authorities", RARE WG-MSG Working Draft, Work in
+ Progress, May 1993.
+
+
+
+RARE Working Group on Mail and Messaging (WG-MSG) [Page 36]
+
+RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993
+
+
+ [14] "COSINE MHS Pocket User Guide", COSINE MHS Project Team 1992.
+ Also available in several languages from the MHS Co-ordination
+ Server:/user-guides. See Appendix D.
+
+ [15] Grimm, R., and S. Haug, "A Minimum Profile for RFC 987", GMD,
+ November 1987; RARE MHS Project Team; July 1990. Also available
+ from the MHS Co-ordination Server:/procedures/min-rfc987-
+ profile. See Appendix D.
+
+ [16] CCITT Recommendations X.400 - X.430. Data Communication
+ Networks: Message Handling Systems. CCITT Red Book, Vol. VIII -
+ Fasc. VIII.7, Malaga-Torremolinos 1984.
+
+ [17] CCITT Recommendations X.400 - X.420. Data Communication
+ Networks: Message Handling Systems. CCITT Blue Book, Vol. VIII
+ - Fasc. VIII.7, Melbourne 1988.
+
+Appendix B. Index
+
+ <<Only available in the Postscript version>>
+
+Appendix C. Abbreviations
+
+
+ ADMD Administration Management Domain
+ ARPA Advanced Research Projects Agency
+ ASCII American Standard Code for Information Exchange
+ ASN.1 Abstract Syntax Notation One
+ BCD Binary-Coded Decimal
+ BITNET Because It's Time NETwork
+ CCITT Comite Consultatif International de Telegraphique et
+ Telephonique
+ COSINE Co-operation for OSI networking in Europe
+ DFN Deutsches Forschungsnetz
+ DL Distribution List
+ DNS Domain Name System
+ DoD Department of Defense
+ EBCDIC Extended BCD Interchange Code
+ IAB Internet Architecture Board
+ IEC International Electrotechnical Commission
+ IESG Internet Engineering Steering Group
+ IETF Internet Engineering Task Force
+ IP Internet Protocol
+ IPM Inter-Personal Message
+ IPMS Inter-Personal Messaging Service
+ IPN Inter-Personal Notification
+ ISO International Organisation for Standardisation
+ ISOC Internet Society
+
+
+
+RARE Working Group on Mail and Messaging (WG-MSG) [Page 37]
+
+RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993
+
+
+ ISODE ISO Development Environment
+ JNT Joint Network Team (UK)
+ JTC Joint Technical Committee (ISO/IEC)
+ MHS Message Handling System
+ MOTIS Message-Oriented Text Interchange Systems
+ MTA Message Transfer Agent
+ MTL Message Transfer Layer
+ MTS Message Transfer System
+ MX Mail eXchanger
+ OSI Open Systems Interconnection
+ OU(s) Organizational Unit(s)
+ PP Mail gatewaying software (not an abbreviation)
+ PRMD Private Management Domain
+ RARE Reseaux Associes pour la Recherche Europeenne
+ RFC Request for comments
+ RTC RARE Technical Committee
+ RTR RARE Technical Report
+ SMTP simple mail transfer protocol
+ STD Internet Standard
+ TCP Transmission Control Protocol
+ UUCP Unix to Unix CoPy
+
+Appendix D. How to access the MHS Co-ordination Server
+
+ Here is an at-a-glance sheet on the access possibilities of the MHS
+ Co-ordination server:
+
+ E-mail
+
+ address:
+
+ RFC822: mhs-server@nic.switch.ch
+ X.400: S=mhs-server; OU1=nic; O=switch; P=switch; A=arcom;
+ C=CH
+
+ body
+
+ help # you receive this document
+ index ['directory'] # you receive a directory listing
+ send 'directory''filename' # you receive the specified file
+
+ FTP
+
+ address: Internet: nic.switch.ch
+ account: cosine
+ password: 'your email address'
+
+
+
+
+
+RARE Working Group on Mail and Messaging (WG-MSG) [Page 38]
+
+RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993
+
+
+ Interactive
+
+ address: Internet: nic.switch.ch
+ address: PSPDN: +22847971014540
+ address: EMPB/IXI: 20432840100540
+ account: info
+ directory: e-mail/COSINE-MHS/
+
+ FTAM
+
+ address: Internet: nic.switch.ch
+ address: PSPDN : +22847971014540
+ address: EMPB/IXI: 20432840100540
+ address: ISO CLNS: NSAP=39756f11112222223333aa0004000ae100,
+ TSEL=0103Hex
+ account: ANON
+
+ gopher
+
+ address: Internet: nic.switch.ch
+
+Security Considerations
+
+ Security issues are not discussed in this memo.
+
+Author's Address
+
+ Jeroen Houttuin
+ RARE Secretariat
+ Singel 466-468
+ NL-1017 AW Amsterdam
+ Europe
+
+ Tel. +31 20 6391131
+ Fax. +31 20 6393289
+ RFC 822: houttuin@rare.nl
+ X.400: C=nl;ADMD=400net;PRMD=surf;O=rare;S=houttuin
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+RARE Working Group on Mail and Messaging (WG-MSG) [Page 39]
+ \ No newline at end of file