RFC 1664
Using the Internet DNS to Distribute RFC1327 Mail Address Mapping Tables
RFC 1664: Using the Internet DNS to Distribute RFC1327 Mail Address Mapping Tables ✨
okay bestie, let's do the vibe check first 💅 This is RFC 1664, published in August 1994, and it's an Experimental doc 🧪 so it's an experiment, not an Internet standard.
The authors are C. Allocchio and A. Bonito (both from GARR-Italy), B. Cole (Cisco Systems Inc.), S. Giordano (Centro Svizzero Calcolo Scientifico), and R. Hagens (Advanced Network & Services) 🫶
There's no Obsoletes or Updates line in the header, so this one doesn't replace or update anything else 🙈
Status of this Memo 📋
This memo defines an Experimental Protocol for the Internet community 🧪. It does not specify an Internet standard of any kind, so please don't go calling it one 🙅. Distribution of this memo is unlimited 🌈
Abstract 🫶
Okay so this memo explains how to store, in the Internet Domain Name System, the mapping info that e-mail gateways and other tools need to turn RFC822 domain names into X.400 O/R names and back again 💖 The mapping info can be managed in a distributed way instead of a centralised one ✨ Gateways on Internet hosts can just ask the DNS for the mapping info, instead of relying on fixed tables that have to be updated and shipped out centrally 🚚 This memo is a joint effort of the X400 operation working group (x400ops) and the RARE Mail and Messaging working group (WG-MSG) 👑
1. Introduction ✨
okay so the connection between Internet SMTP mail and other mail services, including Internet X.400 mail and commercial X.400 service providers, is kept working by Mail eXchanger (MX) records that get distributed through the Internet Domain Name System (DNS) 🦋 A bunch of documents explain in detail how to convert or encode addresses from RFC822 style into the other mail system's syntax, and back. But only conversion methods that use some algorithm or a set of mapping rules give a smooth translation, one that produces addresses that look indistinguishable from native ones in both the RFC822 world and the foreign one 💅
RFC1327 describes a set of mappings that enable interworking between systems running the CCITT X.400 (1984/88) Recommendations and systems using the RFC822 mail protocol, or protocols derived from RFC822 🌸 That doc covers conversion of services, addresses, message envelopes, and message bodies between the two mail systems. This memo is only concerned with one piece of RFC1327: the mechanism for mapping between X.400 O/R addresses and RFC822 domain names 🎀 As described in Appendix F of RFC1327, implementing the mappings needs a database that maps between X.400 O/R addresses and domain names, and this database is statically defined 😭
Here's the problem, though. Keeping the mappings correct takes a LOT of effort 💀 All the gateways need coherent tables so they apply the same mappings, the conversion tables have to be distributed to every operational gateway, and every single update has to be distributed too. This static setup takes forever to modify and distribute, which puts heavy constraints on the timeline of every update. It doesn't look efficient compared to the Internet Domain Name Service (DNS). And it doesn't look feasible to distribute the database to a big number of other useful apps, like local address converters, e-mail User Agents, or any other tool that needs the mapping rules to produce correct results 🙈
A first proposal to use the Internet DNS to store, retrieve, and maintain those mappings came from two of the authors, B. Cole and R. Hagens 🧚 It used two new DNS resource record (RR) types: TO-X400 and TO-822. This new proposal goes for a more complete strategy and only needs one new RR 🔥 Distributing the RFC1327 mapping rules via DNS is an important service for the whole Internet community: it completes the info given by the MX resource record, and it lets you produce clean addresses when messages get exchanged between the Internet RFC822 world and the X.400 one (both Internet and Public X.400 service providers) 🌈
Some of the authors also ran a first experiment in using the DNS without expanding the current set of RRs, just using the ones that already exist 🧪 The existing PTR resource records were used to store the mapping rules, and a new DNS tree was created under the ".it" top level domain. The result was positive, and a few test applications ran under this provisional setup ✨ The test was also super useful for figuring out a possible migration strategy for when the new DNS with the new RR gets deployed. The Internet DNS nameservers that want to provide this mapping info need to be modified to support the new RR type, and on the real Internet, because there are so many different implementations, that takes some time ⏳
The basic idea is to adopt a new DNS RR to store the mapping info 💖 The RFC822 to X.400 mapping rules (including the so-called 'gate' rules) will be stored in the ordinary DNS tree. Meanwhile, a new branch of the name space under each national top level domain is envisaged to hold the X.400 to RFC822 mappings 🌸 That gives us a "two-way" mapping resolution schema, fully implemented 🦋
Creating the new domain name space that represents the X.400 O/R names structure also gives us the chance to use the DNS to dynamically distribute other X.400-related info too 👑 That would solve other efficiency problems that are currently affecting the X.400 MHS service 💅
In this paper we'll adopt the RFC1327 mapping rules syntax and show how it can be stored in the Internet DNS 🎀
1.1 Definitions syntax
The definitions in this document are given in a BNF-like syntax, using these conventions 🧠
| means choice
\ is used for continuation of a definition over several lines
[] means optional
{} means repeated one or more timesThe definitions only go into detail up to a certain level. Below that, self-explaining character text strings get used instead 🌷
2. Motivation 💭
okay so implementations of RFC1327 gateways need a database that stores address mapping info for X.400 and RFC822 📦 That info has to be disseminated to all RFC1327 gateways. In the Internet community, the DNS has proven to be a practical means of providing a distributed name service 🙌 Here's why a DNS based system is better than a table based approach for mapping between O/R addresses and domain names:
- It avoids fetching and storing entire mapping tables on every host that wants to implement RFC1327 gateways and/or tools 🙅♀️
- Modifications to the DNS based mapping info can be made available more quickly than with a table driven approach ⚡
- It allows full authority delegation, in agreement with the Internet regionalization process 🗺️
- Table management is not necessarily required for DNS-based RFC1327 gateways 🫠
- One can determine the mappings in use by a remote gateway by querying the DNS (remote debugging) 🔍
Also, lots of other tools, like address converters and User Agents, can take advantage of the real-time availability of RFC1327 tables 🌈 That makes maintaining the info so much easier 🫶
3. The domain space for X.400 O/R name addresses ✨
okay bestie, so the usual domain names (the ones after the @ in an RFC822 e-mail address 💌) and all their info, like host IP addresses and mail exchanger names, live in the DNS as one big distributed database spread across a bunch of top-level domains 🌸. Some of those TLDs are for traditional categories or international organisations (EDU, COM, NET, ORG, INT, MIL...). Then every country gets its own two letter ISO country code as a TLD (FR, DE, GB, IT, RU, ...), and yes, that includes "US" for USA 🇺🇸. The special IN-ADDR.ARPA top-level/second-level couple is where the IP address to domain name relationship gets stored 🔍. Our proposal defines the right way to locate the X.400 O/R name space inside that same structure, which means we can finally store the RFC1327 mapping data in DNS 💅.
The RFC1327 mapping info is made of three tables. table1 translates X.400 to RFC822, while table2 and gate map RFC822 back into X.400 🦋. Each mapping table is made of mapping rules, and a single rule is a keyword (the argument of the mapping function, pulled from the address being translated) plus a translator (the mapping function parameter):
keyword#translator#The # sign is a delimiter that encloses the translator. Here's an example:
foo.bar.us#PRMD$foo\.bar.ADMD$intx.C$us#Local mappings are not meant to leave their restricted environment, so they should not be included in DNS 🙈. If you do use local mappings, store them in static local tables, the same way local static host tables can be used alongside DNS.
The keyword of a table2 or gate entry is a valid RFC822 domain, so the usual domain name space works totally fine for storing these 💖.
The keyword of a table1 entry, though, belongs to the X.400 O/R name space. That space doesn't usually fit into the regular domain name space, even though there are a few similarities, so a new name structure is needed to represent it. This new structure contains the X.400 mail domains 🧚.
To keep DNS working correctly, the new X.400 name structure must be hooked onto the existing domain name space in a way that respects the existing name hierarchy 👑.
One option was to create another special branch starting from the root of the DNS tree, kinda like the in-addr.arpa tree. That would have needed a central authority to coordinate, at international level, the management of each national X.400 name tree, including the X.400 public service providers. Coordinating that globally is a seriously heavy burden 😭. Moreover, the X.400 name structure is super 'country oriented', so while it needs coordination at national level, it doesn't have anything like an international root. The international X.400 service is really built on a huge number of bilateral agreements, and only some communities have an international coordination service at all.
The X.400 two letter ISO country codes, however, are the same ones used for the RFC822 country top-level domains, and that gives us the perfect hook to insert new branches 🎀. So our proposal is to create, under each national top-level ISO country code, a new branch in the name space. This branch represents exactly the X.400 O/R name structure as defined in that country, following the ADMD, PRMD, O, OU hierarchy. A unique reserved label, X42D, is placed under each country top-level domain, so the national X.400 name space gets its own structure:
. (root)
|
+-----------------+-----------+--------+-----------------+...
| | | |
edu it us fr
| | | |
+---+---+... +-----+-----+... +-----+-----+... +--+---+...
| | | | | | | | | |
... ... cnr X42D infn va ca X42D X42D inria
| | | |
+------------+------------+... ... ... +----+-------+...
| | | | |
ADMD-PtPostel ADMD-garr ADMD-Master400 ADMD-atlas ADMD-red
| | | |
+----------+----+... ... +-------+------+... ...
| | | |
PRMD-infn PRMD-STET PRMD-Telecom PRMD-Renault
| | | |
... ... ... ...Creating the X.400 name tree at national level solves the international coordination problem ✨. Technically, the coordination problem just moves down to national level, but there it's way easier to solve. The coordination at national level between the X.400 communities and the Internet world is already a requirement for creating the national static RFC1327 mapping tables, and using the Internet DNS gives even more reasons for it 🫶.
The national coordination also fits the ongoing proposal to define exactly the RFC1327 Mapping Authorities. DNS allows a step by step authority distribution, up to a final complete delegation, which can be easily controlled at national level according to national needs and situations 🌸. Another perk is that each country can set up its own X.400 name structure in DNS and deploy its own authority delegation on its own local timescale and requirements, with no loss of global service in the meantime 💜. And last, putting the new X.400 name tree and its coordination process at national level fits right into the Internet regionalization and internationalisation process, since local bodies take care of local coordination problems 🌈.
So the DNS name space contains everything an e-mail gateway or tool needs to do the X.400-RFC822 mapping, and a simple query to the nearest nameserver gets it 🙌. There's no longer any need to store, maintain, or distribute any mapping table by hand 💅. The new X.400 name space can also hold further info about the X.400 community, because DNS lets you use a complete set of resource records, so further developments are possible. This set of RRs in the new X.400 name space must be considered 'reserved' and thus not used until further specifications 🔒.
The new domain space trees will be built the same way the existing DNS space was first organised: at the start the information is stored in a fairly centralised way, and then authority is gradually distributed 🦋. A separate document will describe the implementation phase and the methods to make sure the new service is introduced smoothly 🎀.
4. The new DNS resource record for RFC1327 mapping rules: PX ✨
The Internet DNS spec (RFC1035) already provides a bunch of specific resource records (RRs) for specific kinds of info 💖. In particular, there's the Mail eXchanger (MX) RR and the host Address (A) record, which Internet SMTP mailers use. Since we're going to store the RFC822 to X.400 mapping info in the existing DNS name tree, we need a brand new DNS RR so we don't clash with, or accidentally misuse, any existing data structures 🙈. The same new RR will also be used to store the X.400 to RFC822 mappings. Plus, the mapping info (the RFC1327 mapping rules) has a specific format and syntax that needs its own appropriate data structure and processing 🧚. Defining a new RR also gives us the flexibility to handle whatever future development comes along 🌈.
The definition of the new PX DNS resource record is:
class: IN (Internet)
name: PX (pointer to X.400/RFC822 mapping information)
value: 26The PX RDATA format looks like this:
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| PREFERENCE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ MAP822 /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ MAPX400 /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+where:
PREFERENCE: a 16 bit integer that specifies the preference given to this RR among others at the same owner. Lower values are preferred 🍓;MAP822: a<domain-name>element containing<rfc822-domain>, which is the RFC822 part of the RFC1327 mapping information;MAPX400: a<domain-name>element containing the value of<x400-in-domain-syntax>, derived from the X.400 part of the RFC1327 mapping information (see sect. 4.2).
PX records cause no additional section processing 💅. The PX RR format is the usual one:
<name> [<class>] [<TTL>] <type> <RDATA>When we store a table1 entry in DNS, <name> will be an X.400 mail domain name in DNS syntax (see sect. 4.2). When we store a table2 or gate table entry, <name> will be an RFC822 mail domain name, including both fully qualified DNS domains and mail only domains (MX-only domains) 🦋. All the normal DNS conventions, like default values, wildcards, abbreviations and message compression, apply to all the components of the PX RR too ✨. In particular, <name>, MAP822 and MAPX400, as <domain-name> elements, must have the final "." (root) when they are fully qualified 🔥.
4.1 Additional features of the PX resource record ✨
okay bestie, so the PX RDATA definition, plus DNS being able to tell an exact value apart from a wildcard for the <name> parameter, is basically an extension of the RFC1327 mapping rules 💅 any RFC1327 mapping table entry is an implicit wildcard entry 🌸 so this rule:
net2.it#PRMD$net2.ADMD$p400.C$it#covers any RFC822 domain ending with 'net2.it', unless there are more detailed rules for some subdomain in 'net2.it'. which means there's no way to say "this RFC1327 entry is an exact match only" 🙈
in DNS, an entry like this:
*.net2.it. IN PX 10 net2.it. PRMD-net2.ADMD-p400.C-it.gives you the usual wildcard match, same as RFC1327 tables. but an entry like this:
ab.net2.it. IN PX 10 ab.net2.it. O-ab.PRMD-net2.ADMDb.C-it.is only valid for an exact match of the 'ab.net2.it' RFC822 domain. main character energy ✨
also, quick heads up: in DNS syntax there's no '#' delimiter around the MAP822 and MAPX400 fields. the syntax from sect. 4.2 doesn't let a <blank> (ASCII decimal 32) character show up inside those fields, so you don't need the explicit delimiter that the original RFC1327 syntax asks for 🎀
next up, PREFERENCE 🫶 the PX RDATA has its own numeric PREFERENCE value, and it means exactly the same thing as the one in the MX RR. so you can give a domain more than one mapping (RFC822 to X.400 and also X.400 back to RFC822) and rank them by preference. in RFC1327 static tables you can't do that, you get one mapping per RFC822 domain, and the same limit applies to any X.400 domain mapping to an RFC822 one 😭
and then there's the ADMD situation, which is a whole saga 💀 the X.400 recommendations have a note suggesting that ADMD=<blank> should be reserved for some special cases. some national functional profiles for an X.400 MHS say that if a PRMD can be reached through any of its national ADMDs, no matter whether it's connected to one or several of them, it should use ADMD=<blank> to show that. and if a PRMD has no connection to any ADMD at all, it should use ADMD=0 to say so, etc. BUT in most real-world setups, ADMD service providers won't accept messages from their subscribers if they have a blank ADMD, so those subscribers have to use their own ADMD value. and that makes it hard to show the mappings that actually work for domains with multiple connectivity. the PX RDATA 'PREFERENCE' extension was added to deal with exactly this 👑
however, these extensions don't exist in RFC1327 static tables, so it's strongly discouraged to use them when you're interworking with any table-based gateway or application 😤 they were added for flexibility, like the PREFERENCE value, or they were already baked into the DNS mechanism, like wildcards. so use them very carefully, or just treat them as 'reserved for future use'. for current use specifically, the PREFERENCE value in the PX record should be fixed to 50, and only wildcard specifications should be used for <name> values 🌈
4.2 The DNS syntax for an X.400 'domain' 🎀
so the syntax for RFC1327 mapping rules is defined in appendix F of that document. but honestly it isn't very human-friendly, and it has a bunch of characters that already mean something else in the Internet DNS 😵💫 to avoid any problems (especially with some old DNS implementations still floating around the Internet), we define a syntax for the X.400 part of any RFC1327 mapping rule (and so for any X.400 O/R name) that's compatible with a <domain-name> element, like this:
<domain-name> ::= <subdomain> | " "
<subdomain> ::= <label> | <label> "." <subdomain>
<label> ::= <alphanum>|
<alphanum> {<alphanumhyphen>} <alphanum>
<alphanum> ::= "0".."9" | "A".."Z" | "a".."z"
<alphanumhyphen> ::= "0".."9" | "A".."Z" | "a".."z" | "-"(see RFC1035, section 2.3.1, page 8). the legal character set for <label> doesn't match the IA5 Printablestring one that RFC1327 uses for mapping rules 🙃 but there's a really simple "escape mechanism" to get around that. we can describe the X.400 part of an RFC1327 mapping rule like this:
<map-rule> ::= <map-elem> | <map-elem> { "." <map-elem> }
<map-elem> ::= <attr-label> "$" <attr-value>
<attr-label> ::= "C" | "ADMD" | "PRMD" | "O" | "OU"
<attr-value> ::= " " | "@" | IA5-Printablestringnotice how <domain-name> and <map-rule> look kinda alike, and <label> and <map-elem> look the same too 👀 so if we nail down the right way to turn a <map-elem> into a <label> (and back again), writing an RFC1327 mapping rule in <domain-name> syntax is solved 🦋
the RFC822 domain part of any RFC1327 mapping rule is already in <domain-name> syntax, so it stays exactly as it is 💖
specifically, in a 'table1' mapping rule, the 'keyword' value must be converted into <x400-in-domain-syntax> (X.400 mail DNS mail domain), while the 'translator' value is already a valid RFC822 domain. and the other way around: in a 'table2' or 'gate' mapping rule, the 'translator' must be converted into <x400-in-domain-syntax>, while the 'keyword' is already a valid RFC822 domain. ✨
4.2.1 IA5-Printablestring to <alphanumhyphen> mappings
okay so the clash between IA5-Printablestring and the <label> character set is fixed with one simple character mapping rule 🌸 whenever an IA5 character isn't in <alphanumhyphen>, it gets mapped using its 3 digit decimal ASCII code, wrapped in hyphens. there's also a small set of special rules for the most common cases, and some frequent character combos from RFC1327 rules get their own special mappings too 🧚
let's set up the basic rules:
RFC1327 rule DNS store translation conditions
-----------------------------------------------------------------
<attr-label>$@ <attr-label> missing attribute
<attr-label>$<blank> <attr-label>"b" blank attribute
<attr-label>$xxx <attr-label>-xxx elsewhereand for the non <alphanumhyphen> characters in <attr-value>:
RFC1327 rule DNS store translation conditions
-----------------------------------------------------------------
- -h- hyphen
\. -d- quoted dot
<blank> -b- blank
<non A/N character> -<3digit-decimal>- elsewhereif the DNS store translation of <attr-value> ends with a hyphen, that last hyphen gets dropped 🙈
now the examples, because they're way easier to get than the rules 💅
RFC1327 rule DNS store translation conditions
-----------------------------------------------------------------
PRMD$@ PRMD missing attribute
ADMD$<blank> ADMDb blank attribute
ADMD$400-net ADMD-400-h-net hyphen mapping
PRMD$UK\.BD PRMD-UK-d-BD quoted dot mapping
O$ACME Inc\. O-ACME-b-Inc-d blank & final hyphen
PRMD$main-400-a PRMD-main-h-400-h-a hyphen mapping
O$-123-b O--h-123-h-b hyphen mapping
OU$123-x OU-123-h-x hyphen mapping
PRMD$Adis+co PRMD-Adis-043-co 3digit mappingso an X.400 part from an RFC1327 mapping rule like this:
OU$uuu.O$@.PRMD$ppp\.rrr.ADMD$aaa ddd-mmm.C$ccturns into this:
OU-uuu.O.PRMD-ppp-d-rrr.ADMD-aaa-b-ddd-h-mmm.C-ccanother one 🌈
OU$sales dept\..O$@.PRMD$ACME.ADMD$ .C$GBbecomes:
OU-sales-b-dept-d.O.PRMD-ACME.ADMDb.C-GB4.2.2 Flow chart
so the X.400 part of an RFC1327 mapping rule (or any other X.400 O/R name) gets converted with some software tools 🛠️ honestly, converting mapping tables from RFC1327 to DNS format (and back) with those rules is way too fiddly for a human to do by hand 😭 so to help people design those tools, here's a little flow chart. the fundamental rule for translation is this one 👑
"A string must be parsed from left to right, moving appropriately the pointer in order not to consider again the already translated left section of the string in subsequent analysis."
Flow chart 1 - Translation from RFC1327 to DNS format:
parse single attribute
(enclosed in "." separators)
|
(yes) --- <label>$@ ? --- (no)
| |
map to <label> (no) <label>$<blank> ? (yes)
| | |
| map to <label>- map to <label>"b"
| | |
| map "\." to -d- |
| | |
| map "-" to -h- |
| | |
| map non A/N char to -<3digit>- |
restart | | |
^ | remove (if any) last "-" |
| | | |
| \-------> add a "." <--------------/
| |
\---------- take next attribute (if any)Flow chart 2 - Translation from DNS to RFC1327 format:
parse single attribute
(enclosed in "." separators)
|
(yes) ---- <label> ? ---- (no)
| |
map to <label>$@ (no) <label>"b" ? (yes)
| | |
| map to <label>$ map to <label>$<blank>
| | |
| map -d- to "\." |
| | |
| map -h- to "-" |
| | |
| map -b- to " " |
restart | | |
^ | map -<3digit>- to non A/N char |
| | | |
| \--------> add a "." <----------/
| |
\------------- take next attribute (if any)Note that the above flow charts deal with the translation of the attributes syntax, only. 🫶
4.2.3. The Country Code convention in the <name> value. 🌍💖
okay so the RFC822 domain space and the X.400 O/R address space (remember section 3?) share one super specific thing: the X.400 ISO country codes are literally the same as the RFC822 ISO top level domains for countries 👯♀️ it's giving twin energy. Earlier we figured out how to write any X.400 domain in <domain-name> syntax, and section 3 set up the new name space that hangs off each country top level domain under X42D.cc (where 'cc' is the two letter ISO country code) ✨
So the <name> value for a 'table1' entry should come from the X.400 domain value, translated into <domain-name> syntax, with the 'X42D.cc.' post-fix stuck on the end. For example:
ADMD$acme.C$frproduces this key in <domain-name> syntax:
ADMD-acme.C-frand once you post-fix it with 'X42D.fr.', you get:
ADMD-acme.C-fr.X42D.fr.But here's the tea 🫖: because X.400 country codes and RFC822 country top level domains are encoded identically, the 'C-fr.X42D.fr.' bit is clearly redundant 🙄
So we define the 'Country Code convention' for the <name> key:
"The C-cc section of an X.400 domain in <domain-name> syntax must be omitted when creating a <name> key, as it is identical to the top level country code used to identify the DNS zone where the information is stored".
So here are the <name> key examples. Iconic 💅
X.400 domain DNS <name> key
--------------------------------------------------------------------
ADMD$acme.C$fr ADMD-acme.X42D.fr.
PRMD$ux\.av.ADMD$ .C$gb PRMD-ux-d-av.ADMDb.X42D.gb.
PRMD$ppb.ADMD$Dat 400.C$de PRMD-ppb.ADMD-Dat-b-400.X42D.de.4.3. Creating the appropriate DNS files 🗂️
RFC1327 assumes the mapping is asymmetric between X.400 and RFC822 addresses (going one way is not the same deal as going the other way), so you need two separate relations to store the mapping database: RFC1327 'table1' and RFC1327 'table2' 🎀. DNS keeps them as two different sections too, even though both use the PX resource record. RFC1327 also has a third one, the RFC1327 'gate' Table. It has the same syntax rules as 'table2', so the same translation procedure gets applied. We'll dig into the 'gate' table more in section 4.4 ✨
Okay now the fun part: how do you make an actual DNS entry from one RFC1327 mapping rule? RFC1327 defines a mapping rule entry in appendix F, and it looks like this:
<x400-domain>#<rfc822-domain># (case A: 'table1' entry)and
<rfc822-domain>#<x400-domain># (case B: 'table2' and 'gate' entry)These two cases need to be handled separately 🫶
For case A, you:
- take <x400-domain> and translate it into <domain-name> syntax, which gives you <x400-in-domain-syntax>;
- create the <name> key from <x400-in-domain-syntax>, i.e. apply the Country Code convention from sect. 4.2.3;
- construct the DNS PX record as:
*.<name> IN PX 50 <rfc822-domain> <x400-in-domain-syntax>Please note that inside PX RDATA, the <rfc822-domain> comes before the <x400-in-domain-syntax>, and that's true for a 'table1' entry too 📌
Here's an example. From the rule
PRMD$ab.ADMD$ac.C$fr#ab.fr#we get:
*.PRMD-ab.ADMD-ac.X42D.fr. IN PX 50 ab.fr. PRMD-ab.ADMD-ac.C-fr.Quick reminder that <name>, <rfc822-domain> and <x400-in-domain-syntax> are all fully qualified <domain-name> elements, so they end with a "." 🌸
Now case B. For this one, you:
- take <rfc822-domain> as the <name> key;
- translate <x400-domain> into <x400-in-domain-syntax>;
- construct the DNS PX record as:
*.<name> IN PX 50 <rfc822-domain> <x400-in-domain-syntax>For example, from the rule
ab.fr#PRMD$ab.ADMD$ac.C$fr#we get:
*.ab.fr. IN PX 50 ab.fr. PRMD-ab.ADMD-ac.C-fr.Again, note those fully qualified <domain-name> elements 🧚
Here's a made-up example of what a file holding the RFC1327 mapping rules and the RFC1327 'gate' table looks like in DNS format 📄
!
! RFC1327 table 1: X.400 --> RFC822
!
*.ADMD-acme.X42D.it. IN PX 50 it. ADMD-acme.C-it.
*.PRMD-accred.ADMD-tx400.X42D.it. IN PX 50 \
accred.it. PRMD-accred.ADMD-tx400.C-it.
*.O-u-h-newcity.PRMD-x4net.ADMDb.X42D.it. IN PX 50 \
cs.ncty.it. O-u-h-newcity.PRMD-x4net.ADMDb.C-it.
!
! RFC1327 table 2: RFC822 --> X.400
!
*.nrc.it. IN PX 50 nrc.it. PRMD-nrc.ADMD-acme.C-it.
*.ninp.it. IN PX 50 ninp.it. O.PRMD-ninp.ADMD-acme.C-it.
*.bd.it. IN PX 50 bd.it. PRMD-uk-d-bd.ADMDb.C-it.
!
! RFC1327 Gate Table
!
my.it. IN PX 50 my.it. OU-int-h-gw.O.PRMD-ninp.ADMD-acme.C-it.G.
co.it. IN PX 50 co.it. O-mhs-h-relay.PRMD-x4net.ADMDb.C-it.G.(Here the "" just means the line keeps going on the same line. The wrapping is only there because of typography, so don't panic 😭)
Now, the special ".G." suffix on the right side of the 'gate' Table section is important. Its whole purpose is described in section 4.4 🔥 The matching RFC1327 tables look like this:
#
# RFC1327 table 1: X.400 --> RFC822
#
ADMD$acme.C$it#it#
PRMD$accred.ADMD$tx400.C$it#accred.it#
O$u-newcity.PRMD$x4net.ADMD$ .C$it#cs.ncty.it#
#
# RFC1327 table 2: RFC822 --> X.400
#
nrc.it#PRMD$nrc.ADMD$acme.C$it#
ninp.it#O.PRMD$ninp.ADMD$acme.C$it#
bd.it#PRMD$uk\.bd.ADMD$ .C$it#
#
# RFC1327 Gate Table
#
my.it#OU$int-gw.O$@.PRMD$ninp.ADMD$acme.C$it#
co.it#O$mhs-relay.PRMD$x4net.ADMD$ .C$t#4.4. Storing the RFC1327 Gate table 🚪✨
Section 4.3.4 of RFC1327 also explains how an address should be converted between RFC822 and X.400 when a complete mapping is impossible. So the RFC1327 'gate' table exists to allow the use of DDAs for domains that can't be mapped. DNS has to store and distribute this data too 🫶
Now, one of the big features of DNS is that it distributes authority 👑. A site runs the "primary" nameserver for a particular sub-tree, which makes it the only place allowed to update information about that sub-tree. This lets us add one more feature to the table-based approach, and it clears up a possible ambiguity about the 'gate' table (and therefore about DDA encoding) 💜
The authority that maintains a DNS entry in the usual RFC822 domain space is the only one allowed to decide whether its domain gets mapped using Standard Attributes (SA) syntax or Domain Defined Attributes (DDA) syntax. If the authority picks SA, the PX RDATA will be a 'table2' entry. Otherwise, it'll be a 'gate' table entry. So for any RFC822 domain, you can't have both a 'table2' entry and a 'gate' table entry, and what a gateway should do is clearly stated 🙌
The RFC1327 'gate' table syntax is actually identical to RFC1327 'table2', so the same syntax translation rules from RFC1327 to DNS format apply. But a gateway (or any other application) must know whether the answer it got back from DNS holds 'table2' info or 'gate' table info. The fix is easy: add a ".G." post-fix to the PX RDATA value whenever it holds a 'gate' table entry. You already saw the result in section 4.3. Since every X.400 O/R domain ends with a country code ("C-xx" in our DNS syntax), the extra ".G." doesn't create any conflicts or ambiguities at all. This post-fix must obviously be removed before the RFC1327 'gate' table data gets used 🧹
5. Finding RFC1327 mapping information from DNS 🔍
The RFC1327 mapping information is stored in DNS both in the normal RFC822 domain name space and in the newly defined X.400 name space. The info lives in PX resource records, and it's not a full RFC822 or X.400 O/R address. It's a template that specifies which fields of the domain the mapping algorithm uses 💅
When mapping info is stored in DNS, queries get issued whenever an iterative search through the mapping table would happen (RFC1327: section 4.3.4, State I; section 4.3.5, mapping B). Thanks to how the DNS search mechanism works, DNS itself returns the longest possible match in the stored mapping rule with one single query, so no iteration and no multiple queries are needed 🙌 As RFC1327 specifies, a search of the mapping table ends in either success (mapping found) or failure (query failed, mapping not found).
When a DNS query is issued, there's a third possible result: timeout. If you get a timeout, the gateway operation gets delayed and then retried later. Success or failure gets processed according to the algorithms in RFC1327. If DNS returns an error code, an error message should be logged, and the gateway operation gets delayed just like with a timeout. These pathological situations should ideally be avoided with the careful duplication and caching mechanism DNS itself provides 😭
Finding the nameserver that can authoritatively answer the query is handled automatically by the DNS distributed name service 🦋
5.1. A DNS query example 🎀
Picture an RFC1327 mail-gateway out on the Internet. When it translates addresses from RFC822 to X.400, it can look up the RFC1327 mapping rule by asking DNS. As an example, say it's translating the address SUN.CCE.NRC.IT. The gateway just queries DNS for the matching PX resource record, and DNS should contain a PX record like this:
*.cce.nrc.it. IN PX 50 cce.nrc.it. O-cce.PRMD-nrc.ADMD-acme.C-it.That first query returns the right mapping rule immediately, in DNS store format.
There's no ".G." at the end of that PX RDATA value, so applying the syntax translation from paragraph 4.2 gives you the RFC1327 Table 2 mapping rule 💖
Now let's try an example where a 'gate' table rule comes back. Say we're looking for an RFC822 domain ending in the top level domain "MW", and DNS holds this PX record:
*.mw. IN PX 50 mw. O-cce.PRMD-nrc.ADMD-acme.C-it.G.DNS returns 'mw.' and 'O-cce.PRMD-nrc.ADMD-acme.C-it.G.', which is a 'gate' table entry in DNS store format. Drop the final ".G." and apply the syntax translation from paragraph 4.2, and the original rule is back ✨ Plus, the ".G." flag also tells the gateway to use DDA encoding for the RFC822 domain being looked up 🌈
Going the other way, let's translate this X.400 address to RFC822:
C=de; ADMD=pkz; PRMD=nfc; O=top;The mail gateway should convert the syntax according to paragraph 4.2, apply the 'Country code convention' from 4.2.3 to get the right DNS translation of the X.400 O/R name, and then query DNS for the matching PX resource record. The record it needs to look up ends up being:
O-top.PRMD-nfc.ADMD-pkz.X42D.de.And DNS could contain:
*.ADMD-pkz.X42D.de. IN PX 50 pkz.de. ADMD-pkz.C-de.As long as there aren't more specific records in DNS, the wildcard mechanism will hand back the RFC1327 'table1' rule in encoded format 🫧
6. Administration of mapping information ✨
okay so the DNS, using the PX RR, can totally pass the mapping info out to every RFC1327 gateway on the Internet 🌐. BUT not every gateway is gonna be able to use the Internet DNS, and that's just how it is 💅. It's expected that some gateways in a management domain will follow one of these models: (a) Table-based, (b) DNS-based, (c) X.500-based
Table-based management domains keep submitting and grabbing their mapping tables from the International Mapping Table coordinator, either manually or through some automated procedures 🤖. Their mapping info should show up in DNS through the appropriate DNS authority, using the same mechanism already in place for MX records 📬. If a branch doesn't have its own DNS server yet, some higher authority in the DNS tree will provide the service for it, bestie 🫶. A transition procedure similar to the one used to move from the hosts.txt tables to DNS can also be applied to the deployment phase of this proposal 🦋. An informational document describing the implementation phase and the detailed coordination procedures is expected 📄. The deployment phase must also follow the directives produced by the current work on RFC1327 mapping authorities, so that the mapping info stays consistent 🧩.
Another distributed directory service that can distribute the RFC1327 mapping info is X.500 🌍. Coordination, alignment, and uniqueness of mapping info between DNS and X.500 is an essential fact if both systems are in place 🔥. The ideal solution is a dynamic alignment mechanism that transparently makes the DNS mapping info available in X.500 and vice versa 💖. Some work in this specific field is already being done [see Costa], and it can result in a global transparent directory service, where the info is stored in DNS or in X.500 but is visible completely by either of the two systems 🧚.
7. Conclusion 🎀
Introducing the new PX resource record and defining the X.400 O/R name space in the DNS structure gives us a seriously good repository for mapping info 📦. The mapping info is stored in the DNS tree so it can be easily obtained with the DNS distributed name service 🌳. The DNS space for X.400 O/R names is also a place to store and distribute some other X.400 MHS info 💜. Using DNS has many known advantages for storing, managing, and updating info ✨. A successful number of tests were performed under the provisional top level domain X400.IT, and the results confirmed the advantages of the method 🙌.
Software to query DNS and then convert between the textual representation of DNS resource records and the address format defined in RFC1327 still needs to be developed 🛠️. This software must also allow a smooth implementation and deployment period, and eventually take care of the transition phase 💅. A further informational document describing the operation and implementation of the service is expected 📄.
8. Acknowledgements 🫶
We wanna thank everyone who contributed to the discussion and revision of this document, because so many of their ideas are essential parts of this work 💖. Special shoutouts to Jon Postel, Paul Mockapetris, Rob Austin, and the whole IETF x400ops, RARE wg-msg, and IETF namedroppers groups 📣. A super special mention goes to Christian Huitema for his fundamental contribution 👑.
9. References 📚
- [CCITT] CCITT SG 5/VII, "Recommendation X.400, Message Handling Systems: System Model - Service Elements", October 1988.
- [RFC 1327] Kille, S., "Mapping between X.400(1988)/ISO 10021 and RFC 822", RFC 1327, March 1992.
- [RFC 1034] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, USC/Information Sciences Institute, November 1987.
- [RFC 1035] Mockapetris, P., "Domain names - Implementation and Specification", STD 13, RFC 1035, USC/Information Sciences Institute, November 1987.
- [RFC 1033] Lottor, M., "Domain Administrators Operation Guide", RFC 1033, SRI International, November 1987.
- [Costa] Costa, A., Macedo, J., and V. Freitas, "Accessing and Managing DNS Information in the X.500 Directory", Proceeding of the 4th Joint European Networking Conference, Trondheim, NO, May 1993.
- [Houttin] Houttin, J., Hansen, K., and S. Aumont, "Address Mapping Functions and Authorities", Internet-DRAFT, May 1993.
10. Security Considerations 💀
Security issues are not discussed in this memo. 🙈
11. Authors' Addresses 🖋️
Here are the authors, with their addresses exactly as they were written 🧚:
Claudio Allocchio
Sincrotrone Trieste
Padriciano 99
I 34012 Trieste
Italy
RFC822: Claudio.Allocchio@elettra.trieste.it
X.400: C=it;A=garr;P=Trieste;O=Elettra;
S=Allocchio;G=Claudio;
Phone: +39 40 3758523
Fax: +39 40 226338
Antonio Blasco Bonito
CNUCE - CNR
Reparto infr. reti
Viale S. Maria 36
I 56126 Pisa
Italy
RFC822: bonito@cnuce.cnr.it
X.400: C=it;A=garr;P=cnr;O=cnuce;S=bonito;
Phone: +39 50 593246
Fax: +39 50 589354
Bruce Cole
Cisco Systems Inc.
P.O. Box 3075
1525 O'Brien Drive
Menlo Park, CA 94026
U.S.A.
RFC822: bcole@cisco.com
X.400: C=us;A= ;P=Internet;
DD.rfc-822=bcole(a)cisco.com;
Phone: +1 415 6888245
Fax: +1 415 6884575
Silvia Giordano
Centro Svizzero di
Calcolo Scientifico
Via Cantonale
CH 6928 Manno
Switzerland
RFC822: giordano@cscs.ch
X.400: C=ch;A=arcom;P=switch;O=cscs;
S=giordano;
Phone: +41 91 508213
Fax: +41 91 506711
Robert Hagens
Advanced Network and Services
1875 Campus Commons Drive
Reston, VA 22091
U.S.A.
RFC822: hagens@ans.net
X.400: C=us;A= ;P=Internet;
DD.rfc-822=hagens(a)ans.net;
Phone: +1 703 7587700📦 where this page comes from
- ietf: rfc1664 1994-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms