7 Network Working Group S. Kille
8 Request for Comments: 2164 Isode Ltd.
9 Obsoletes: 1838 January 1998
10 Category: Standards Track
14 Use of an X.500/LDAP directory to support MIXER address mapping
18 This document specifies an Internet standards track protocol for the
19 Internet community, and requests discussion and suggestions for
20 improvements. Please refer to the current edition of the "Internet
21 Official Protocol Standards" (STD 1) for the standardization state
22 and status of this protocol. Distribution of this memo is unlimited.
26 Copyright (C) The Internet Society (1998). All Rights Reserved.
28 1 MIXER X.400/RFC 822 Mappings
30 MIXER (RFC 2156) defines an algorithm for use of a set of global
31 mapping between X.400 and RFC 822 addresses [4]. This specification
32 defines how to represent and maintain these mappings (MIXER
33 Conformant Global Address Mappings of MCGAMs) in an X.500 or LDAP
34 directory. Mechanisms for representing OR Address and Domain
35 hierarchies within the DIT are defined in [5, 2]. These techniques
36 are used to define two independent subtrees in the DIT, which contain
37 the mapping information. The benefits of this approach are:
39 1. The mapping information is kept in a clearly defined area which
40 can be widely replicated in an efficient manner. The tree is
41 constrained to hold only information needed to support the
42 mapping. This is important as gateways need good access to the
45 2. It facilitates migration from a table-based approach.
47 3. It handles the issues of "missing components" in a natural
50 An alternative approach which is not taken is to locate the
51 information in the routing subtrees. The benefits of this
58 Kille Standards Track [Page 1]
60 RFC 2164 X.500/LDAP Directory to Support MIXER January 1998
63 o It is the "natural" location, and will also help to
64 ensure correct administrative authority for a mapping
67 o The tree will usually be accessed for routing, and so it
68 will be efficient for addresses which are being routed.
70 This is not done, as the benefits of the approach proposed are
73 MCGAMs are global. A MIXER gateway may use any set of MCGAMs. A key
74 use of the directory is to enable MIXER gateways to share MCGAMs and
75 to share the effort of maintaining and publishing MCGAMs. This
76 specification and MIXER also recognise that there is not a single
77 unique location for publication of all MCGAMs. This specification
78 allows for multiple sets of MCGAMs to be published. Each set of
79 MCGAMs is published under a single part of the directory. There are
80 four mappings, which are represented by two subtrees located under
81 any part of the DIT. For the examples the location defined below is
85 OU=MIXER MCGAMs, O=Zydeco Plc, C=GB
87 These subtree roots are of object class subtree, and use the
88 mechanism for representing subtrees defined in [1].
91 X.400 to RFC 822 This table gives the equivalence mapping from X.400
92 to RFC 822. There is an OR Address tree under this. An example
95 PRMD=Isode, ADMD=Mailnet, C=FI, CN=X.400 to RFC 822,
96 OU=MIXER MCGAMs, O=Zydeco Plc, C=GB
98 RFC 822 to X.400 There is a domain tree under this. This table holds
99 the equivalence mapping from RFC 822 to X.400, and the gateway
100 mapping defined in RFC 1327. An example entry is:
102 DomainComponent=ISODE, DomainComponent=COM,
104 OU=MIXER MCGAMs, O=Zydeco Plc, C=GB
106 The values of the table mapping are defined by use of two new object
107 classes, as specified in Figure 1. The objects give pointers to the
114 Kille Standards Track [Page 2]
116 RFC 2164 X.500/LDAP Directory to Support MIXER January 1998
121 In MIXER, it is possible to have omitted components in OR Addresses
122 on either side of the mapping. A mechanism to represent such omitted
123 components is defined in Figure 2. The attribute at-or-address-
124 component-type is set to the X.500 attribute type associated with the
125 omitted component (e.g.,
128 rFC822ToX400Mapping OBJECT-CLASS ::= {
129 SUBCLASS OF {domain-component}
132 associatedX400Gateway}
133 ID oc-rfc822-to-x400-mapping}
135 x400ToRFC822Mapping OBJECT-CLASS ::= {
139 associatedInternetGateway}
140 ID oc-x400-to-rfc822-mapping}
142 associatedORAddress ATTRIBUTE ::= {
143 SUBTYPE OF distinguishedName
145 ID at-associated-or-address}
148 associatedX400Gateway ATTRIBUTE ::= {
149 SUBTYPE OF mhs-or-addresses
151 ID at-associated-x400-gateway}
153 associatedDomain ATTRIBUTE ::= {
155 WITH SYNTAX caseIgnoreIA5String
157 ID at-associated-domain} 30
159 associatedInternetGateway ATTRIBUTE ::= {
161 WITH SYNTAX caseIgnoreIA5String
163 ID at-associated-internet-gateway}
166 Figure 1: Object Classes for MIXER mappings
170 Kille Standards Track [Page 3]
172 RFC 2164 X.500/LDAP Directory to Support MIXER January 1998
175 omittedORAddressComponent OBJECT-CLASS ::=
178 oRAddressComponentType
180 ID oc-omitted-or-address-component}
183 oRAddressComponentType ATTRIBUTE ::= {
184 SUBTYPE OF objectIdentifier 10
186 ID at-or-address-component-type}
188 Figure 2: Omitted OR Address Component
191 at-prmd-name). This mechanism is for use only within the X.400 to
192 RFC 822 subtree and for the at-associated-or-address attribute.
194 3 Mapping from X.400 to RFC 822
196 As an example, consider the mapping from the OR Address:
199 P=Isode; A=Mailnet; C=FI
201 This would be keyed by the directory entry:
203 PRMD=Isode, ADMD=Mailnet, C=FI, CN=X.400 to RFC 822,
204 OU=MIXER MCGAMs, O=Zydeco Plc, C=GB
206 and return the mapping from the associatedDomain attribute, which
207 gives the domain which this OR address maps to. This attribute is
208 used to define authoritative mappings, which are placed in the open
209 community tree. The manager of an MCGAM shall make the appropriate
212 The Internet gateway mapping defined in MIXER[4] is provided by the
213 associatedInternetGateway attribute. This value may identify
214 multiple possible associated gateways. This information is looked up
215 at the same time as mapped OR addresses. In effect, this provides a
216 fallback mapping, which is found if there is no equivalence mapping.
217 Because of the nature of the mapping an OR Address will map to either
218 a gateway or a domain, but not both. Thus, there shall never be both
226 Kille Standards Track [Page 4]
228 RFC 2164 X.500/LDAP Directory to Support MIXER January 1998
231 an associatedDomain and associatedInternetGateway attribute present
232 in the same entry. Functionally, mapping takes place exactly
233 according to MIXER. The longest match is found by the following
236 1. Take the OR Address, and derive a directory name. This will be
237 the OR Address as far as the lowest OU.
239 2. Look up the entire name derived from the MIXER key in the in the
240 X.400 to RFC 822 subtree. This lookup will either succeed, or it
241 will fail and indicate the longest possible match, which can then
244 3. Check for an associatedDomain or associatedInternetGateway
245 attribute in the matched entry.
247 The mapping can always be achieved with two lookups. Because of the
248 availability of aliases, some of the table mappings may be
249 simplified. In addition, the directory can support mapping from
250 addresses using the numeric country codes.
252 4 Mapping from RFC 822 to X.400
254 There is an analogous structure for mappings in the reverse
255 direction. The domain hierarchy is represented in the DIT according
256 to RFC 1279. The domain:
260 Is represented in the DIT as:
262 DomainComponent=ISODE, DomainComponent=COM, CN=RFC 822 to X.400,
263 OU=MIXER MCGAMs, O=Zydeco Plc, C=GB
265 This has associated with it the attribute associatedORAddress encoded
266 as a distinguished name with a value: PRMD=Isode, ADMD=Mailnet, C=FI
268 The X.400 gateway mapping defined in MIXER[4] is provided by the
269 associatedX400Gateway attribute. This value may identify multiple
270 possible associated gateways. This information is looked up at the
271 same time as mapped OR addresses. In effect, this provides a
272 fallback mapping, which is found if there is no equivalence mapping.
273 Because of the nature of the mapping a domain will map to either a
274 gateway or a domain, but not both. Thus, there shall never be both
275 an associatedX400Gateway and associatedORAddress attribute present in
276 the same entry. Functionally, mapping takes place exactly according
277 to MIXER. The longest match is found by the following algorithm.
282 Kille Standards Track [Page 5]
284 RFC 2164 X.500/LDAP Directory to Support MIXER January 1998
287 1. Derive a directory name from the domain part of the RFC 822
290 2. Look up this name in the RFC 822 to X.400 subtree to find the
291 mapped value (either associatedORAddress or
292 associatedX400Gateway.). If the lookup fails, the error will
293 indicate the longest match, which can then be looked up.
295 If associatedORAddress is found, this will define the mapped OR
296 Address. The mapping can always be achieved with two lookups. If an
297 associatedX400Gateway is present, the address in question will be
298 encoded as a domain defined attribute, relative to the OR Address
299 defined by this attribute. If multiple associatedX400Gateway
300 attributes are found, the MTA may select the one it chooses to use.
302 Because of the availability of aliases, some of the table mappings
303 may be simplified. In addition, the directory can support mapping
304 from addresses using the numeric country codes.
306 5 Gateway Selection of MCGAMs
308 The directory information to support identification of MCGAMs is
309 given in Figure 3. A MIXER gateway simply identifies the an ordered
310 lists of MCGAM collections that it will use for lookup. These are
311 referenced by name. A gateway is not required to use any MCGAMs.
312 Where MCGAMs are accessed from multiple sources, it is recommended
313 that all of the sources be accessed in order to determine the MCGAM
317 mixerGateway OBJECT-CLASS ::=
319 SUBCLASS OF {mhs-message-transfer-agent}
326 mcgamTables ATTRIBUTE ::= { 10
327 WITH SYNTAX SEQUENCE OF DistinguishedName
331 Figure 3: Object Classes for MCGAM selection
338 Kille Standards Track [Page 6]
340 RFC 2164 X.500/LDAP Directory to Support MIXER January 1998
345 Acknowledgements for work on this document are given in [3].
349 [1] Kille, S., "Representing tables and subtrees in the X.500
350 directory", RFC 1837, August 1995.
352 [2] Kille, S., "Representing the O/R Address hierarchy in the X.500
353 directory information tree," RFC 1836, August 1995.
355 [3] Kille, S., " X.400-MHS use of the X.500 directory to support
356 X.400-MHS routing," RFC 1801, June 1995.
358 [4] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay):
359 Mapping between X.400 and RFC 822/MIME," RFC 2156, January 1998.
361 [5] Kille, S., Wahl, M., Grimsatd, A., Huber, R., and S. Sataluri,
362 "Using Domains in LDAP/X.500 Distinguished Names", RFC 2247,
365 7 Security Considerations
367 This document specifies a means by which the X.500/LDAP directory
368 service can direct the translation between X.400 and Internet mail
369 addresses. This can indirectly affect the routing of messages across
370 a gateway between X.400 and Internet Mail. A succesful attack on
371 this service could cause incorrect translation of an originator
372 address (thus "forging" the originator address), or incorrect
373 translation of a recipient address (thus directing the mail to an
374 unauthorized recipient, or making it appear to an authorized
375 recipient, that the message was intended for recipients other than
376 those chosen by the originator). When cryptographic authentication
377 is available for directory responses, clients shall employ those
378 mechanisms to verify the authenticity and integrity of those
394 Kille Standards Track [Page 7]
396 RFC 2164 X.500/LDAP Directory to Support MIXER January 1998
409 Phone: +44-181-332-9091
410 Internet EMail: S.Kille@ISODE.COM
450 Kille Standards Track [Page 8]
452 RFC 2164 X.500/LDAP Directory to Support MIXER January 1998
455 A Object Identifier Assignment
458 mhs-ds OBJECT IDENTIFIER ::= {iso(1) org(3) dod(6) internet(1) private(4)
459 enterprises(1) isode-consortium (453) mhs-ds (7)}
461 mapping OBJECT IDENTIFIER ::= {mhs-ds 4}
463 oc OBJECT IDENTIFIER ::= {mapping 1}
464 at OBJECT IDENTIFIER ::= {mapping 2}
467 oc-rfc822-to-x400-mapping OBJECT IDENTIFIER ::= {oc 1} 10
468 oc-x400-to-rfc822-mapping OBJECT IDENTIFIER ::= {oc 2}
469 oc-omitted-or-address-component OBJECT IDENTIFIER ::= {oc 3}
470 oc-mixer-gateway ::= {oc 4}
472 at-associated-or-address OBJECT IDENTIFIER ::= {at 6}
473 at-associated-x400-gateway OBJECT IDENTIFIER ::= {at 3}
474 at-associated-domain OBJECT IDENTIFIER ::= {at 4}
475 at-or-address-component-type OBJECT IDENTIFIER ::= {at 7}
476 at-associated-internet-gateway OBJECT IDENTIFIER ::= {at 8}
477 at-mcgam-tables ::= {at 9} 20
480 Figure 4: Object Identifier Assignment
506 Kille Standards Track [Page 9]
508 RFC 2164 X.500/LDAP Directory to Support MIXER January 1998
511 Full Copyright Statement
513 Copyright (C) The Internet Society (1998). All Rights Reserved.
515 This document and translations of it may be copied and furnished to
516 others, and derivative works that comment on or otherwise explain it
517 or assist in its implementation may be prepared, copied, published
518 and distributed, in whole or in part, without restriction of any
519 kind, provided that the above copyright notice and this paragraph are
520 included on all such copies and derivative works. However, this
521 document itself may not be modified in any way, such as by removing
522 the copyright notice or references to the Internet Society or other
523 Internet organizations, except as needed for the purpose of
524 developing Internet standards in which case the procedures for
525 copyrights defined in the Internet Standards process must be
526 followed, or as required to translate it into languages other than
529 The limited permissions granted above are perpetual and will not be
530 revoked by the Internet Society or its successors or assigns.
532 This document and the information contained herein is provided on an
533 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
534 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
535 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
536 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
537 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
562 Kille Standards Track [Page 10]