RFC 2164

Use of an X.500/LDAP directory to support MIXER address mapping 🦋

okay bestie, this is RFC 2164 💖 It's from the Network Working Group, written by S. Kille at Isode Ltd., and it's on the Standards Track 📜. It's dated January 1998, and it obsoletes RFC 1838 ✨ so that's the older version it's replacing.

Status of This Memo 🌸

okay so this is an Internet standards track protocol for the whole Internet community 🌈 and they're literally asking for discussion and suggestions for improvements 🫶 If you want the official standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚 And distribution of this memo is unlimited 💅

Copyright Notice 🎀

Copyright (C) The Internet Society (1998). All Rights Reserved.

1. MIXER X.400/RFC 822 Mappings ✨

okay so MIXER (RFC 2156) is an algorithm that uses a set of global mappings between X.400 and RFC 822 addresses [4] 💅 This spec is about how to represent and maintain those mappings (MIXER Conformant Global Address Mappings, aka MCGAMs 🫶) inside an X.500 or LDAP directory. The way to represent OR Address and Domain hierarchies in the DIT is defined in [5, 2] 🌸 and the whole design uses two independent subtrees in the DIT to hold the mapping info 🦋 The benefits are literally iconic:

1. The mapping info lives in a clearly defined area that can be widely replicated efficiently 😭 The tree only holds what's needed to support the mapping, and that matters because gateways need good access to the entire mapping.
2. It makes migration from a table-based approach easier 🧚
3. It handles the "missing components" issue in a natural way 🙈

An alternative approach which is not taken is to put the info in the routing subtrees instead. The benefits of that would be: - It's the "natural" location, and it'll also help make sure the administrative authority for a mapping definition is correct. - The tree is usually accessed for routing, so it'd be efficient for the addresses being routed. This isn't done, because the benefits of the approach proposed are greater 💅

MCGAMs are global, and a MIXER gateway can use any set of MCGAMs 🌍 A key use of the directory is letting MIXER gateways share MCGAMs and share the effort of maintaining and publishing them 🤝 This spec and MIXER also recognise that there isn't a single unique location for publishing all MCGAMs, so this spec lets you publish multiple sets of MCGAMs. Each set is published under a single part of the directory. There are four mappings, and they're represented by two subtrees located under any part of the DIT. For the examples, we're using this location:

OU=MIXER MCGAMs, O=Zydeco Plc,  C=GB

These subtree roots are of object class subtree, and they use the mechanism for representing subtrees defined in [1] ✨

X.400 to RFC 822 is the table that gives the equivalence mapping from X.400 to RFC 822 💜 There's an OR Address tree under this. An example entry looks like:

PRMD=Isode, ADMD=Mailnet, C=FI, CN=X.400 to RFC 822,
OU=MIXER MCGAMs, O=Zydeco Plc,  C=GB

RFC 822 to X.400 has a domain tree under it. This table holds the equivalence mapping from RFC 822 to X.400, plus the gateway mapping defined in RFC 1327 🍓 An example entry is:

DomainComponent=ISODE, DomainComponent=COM,
CN=RFC 822 to X.400,
OU=MIXER MCGAMs, O=Zydeco Plc,  C=GB

The values of the table mapping are defined by using two new object classes, as specified in Figure 1 🎀 The objects give pointers to the mapped components 💖

2. Omitted Components 🙈

okay so in MIXER, it's possible to have omitted components in OR Addresses on either side of the mapping 😭 A mechanism to represent those omitted components is defined in Figure 2 ✨ The attribute at-or-address-component-type is set to the X.500 attribute type associated with the omitted component (e.g.,

rFC822ToX400Mapping OBJECT-CLASS ::= {
    SUBCLASS OF {domain-component}
    MAY CONTAIN {
        associatedORAddress|
        associatedX400Gateway}
    ID oc-rfc822-to-x400-mapping}

x400ToRFC822Mapping OBJECT-CLASS ::= {
    SUBCLASS OF {top}
    MAY CONTAIN {                                                   10
        associatedDomain|
        associatedInternetGateway}
    ID oc-x400-to-rfc822-mapping}

associatedORAddress ATTRIBUTE ::= {
    SUBTYPE OF distinguishedName
    SINGLE VALUE
    ID at-associated-or-address}

                                                                    20
associatedX400Gateway ATTRIBUTE ::= {
    SUBTYPE OF mhs-or-addresses
    MULTI VALUE
    ID at-associated-x400-gateway}

associatedDomain ATTRIBUTE ::= {
    SUBTYPE OF name
    WITH SYNTAX caseIgnoreIA5String
    SINGLE VALUE
    ID at-associated-domain}                                        30

associatedInternetGateway ATTRIBUTE ::= {
    SUBTYPE OF name
    WITH SYNTAX caseIgnoreIA5String
    MULTI VALUE
    ID at-associated-internet-gateway}

Figure 1: Object Classes for MIXER mappings 🌈

omittedORAddressComponent OBJECT-CLASS ::=
        SUBCLASS OF {top}
        MUST Contain {
                oRAddressComponentType
        }
        ID oc-omitted-or-address-component}


oRAddressComponentType ATTRIBUTE ::= {
        SUBTYPE OF  objectIdentifier                                10
        SINGLE VALUE
        ID at-or-address-component-type}

Figure 2: Omitted OR Address Component 🧚

at-prmd-name). This mechanism is for use only within the X.400 to RFC 822 subtree and for the at-associated-or-address attribute 💅

---

okay that's the first half, bestie 💜 more of the spec is coming in part 2 🦋

7. Security Considerations 🔒

Okay bestie, this part is serious, so let's get into it 🫶 The whole spec is about how the X.500/LDAP directory service decides how translation between X.400 and Internet mail addresses goes 📇. That means it can indirectly change how messages get routed across a gateway between X.400 and Internet Mail 🚚. If someone successfully attacks this service, they could mess up the translation of an originator address (so the sender gets "forged" 🥸), or mess up the translation of a recipient address (so mail goes to an unauthorized person, or an authorized recipient thinks the message was meant for people other than the ones the originator picked 😬). The fix is that when cryptographic authentication is available for directory responses, clients shall employ those mechanisms to verify the authenticity and integrity of those responses 🔐 No cap, this is the main thing to remember, periodt 💅

8. Author's Address 💌

Here's where you can reach the author, Steve Kille 🧚

Steve Kille
Isode Ltd.
The Dome
The Square
Richmond
TW9 1DT
England

Phone:  +44-181-332-9091
Internet EMail:  S.Kille@ISODE.COM

A. Object Identifier Assignment 🆔

Okay, the OIDs are giving organized 🗂️✨ Everything hangs off one base arc, and then it branches into object classes and attributes 🌳

mhs-ds OBJECT IDENTIFIER ::= {iso(1) org(3) dod(6) internet(1) private(4)
          enterprises(1) isode-consortium (453) mhs-ds (7)}

mapping OBJECT IDENTIFIER ::= {mhs-ds 4}

oc OBJECT IDENTIFIER ::= {mapping 1}
at OBJECT IDENTIFIER ::= {mapping 2}


oc-rfc822-to-x400-mapping OBJECT IDENTIFIER ::= {oc 1}
oc-x400-to-rfc822-mapping OBJECT IDENTIFIER ::= {oc 2}
oc-omitted-or-address-component OBJECT IDENTIFIER ::= {oc 3}
oc-mixer-gateway ::= {oc 4}

at-associated-or-address OBJECT IDENTIFIER ::= {at 6}
at-associated-x400-gateway OBJECT IDENTIFIER ::= {at 3}
at-associated-domain OBJECT IDENTIFIER ::= {at 4}
at-or-address-component-type OBJECT IDENTIFIER ::= {at 7}
at-associated-internet-gateway OBJECT IDENTIFIER ::= {at 8}
at-mcgam-tables ::= {at 9}

Figure 4: Object Identifier Assignment 🎀

Full Copyright Statement 📜

Copyright (C) The Internet Society (1998). All Rights Reserved. 🦋

So this document, and translations of it, can be copied and shared with others, and derivative works that comment on it, explain it, or help implement it can be made, copied, published, and distributed, in whole or in part, with no restrictions of any kind 🌈 The only rule is that the above copyright notice and this paragraph have to be included on every copy and derivative work. The document itself may not be modified in any way, like removing the copyright notice or the references to the Internet Society or other Internet organizations. The exceptions are when it's needed for developing Internet standards (then the Internet Standards process copyright procedures must be followed), or when it's translated into languages other than English 🌸

The permissions above are perpetual and will not be revoked by the Internet Society or its successors or assigns 💜

This document and the information in it are provided on an "AS IS" basis, and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE 💀