This memo obsoletes RFC1664. It includes the changes introduced
MIXER specification with respect to RFC1327: the new 'gate1' (O/ addresses to domain) table is fully supported. Full
compatibility with RFC1664 specification is mantained, too
RFC1664 was a joint effort of IETF X400 operation working
(x400ops) and TERENA (formely named "RARE") Mail and
working group (WG-MSG). This update was performed by the IETF
working group
The connectivity between the Internet SMTP mail and other services, including the Internet X.400 mail and the commercial X.400
service providers, is assured by the Mail eXchanger (MX) informationdistributed via the Internet Domain Name System (DNS).
number of documents then specify in details how to convert or addresses from/to RFC822 style to the other mail system syntax
However, only conversion methods provide, via some algorithm or a
of mapping rules, a smooth translation, resulting in
indistinguishable from the native ones in both RFC822 and
world
The concept of mapping rules distribution and use has been revised
the new MIXER specification, introducing the concept of Conformant Global Address Mapping (MCGAM). A MCGAM does not need
be globallyinstalled by any MIXER conformant gateway in the
any more. However MIXER requires now efficient methods to publish
MCGAM
Static tables are one of the possible methods to publish MCGAM
However this static mechanism requires quite a long time to be
modifying and distributing the information, putting heavy
on the time schedule of every update. In fact it does not
efficient compared to the Internet Domain Name Service (DNS).
over it does not look feasible to distribute the database to a
number of other useful applications, like local address converters
e-mail User Agents or any other tool requiring the mapping rules
produce correct results
A first proposal to use the Internet DNS to store, retrieve maintain those mappings was introduced by two of the authors
RFC1664 (B. Cole and R. Hagens) adopting two new DNS resource
(RR) types: TO-X400 and TO-822. This proposal now adopts a completestrategy, and requires one new RR only. The distribution
MCGAMs via DNS is in fact an important service for the whole community: it completes the information given by MX resource
and it allows to produce clean addresses when messages are
among the Internet RFC822 world and the X.400 one (both Internet
Public X.400 service providers).
A first experiment in using the DNS without expanding the current
of RR and using available ones was deployed by some of the authors
RFC1664 at the time of its development. The existing PTR
records were used to store the mapping rules, and a new DNS tree
created under the ".it" top level domain. The result of experiment was positive, and a few test applications ran under provisional set up. This test was also very useful in order to
a possible migration strategy during the deployment of the new containing the new RR. The Internet DNS nameservers wishing
provide this mapping information need in fact to be modified
support the new RR type, and in the real Internet, due to the
number of different implementations, this takes some time
The basic idea is to adopt a new DNS RR to store the information. The RFC822 to X.400 mapping rules (including the
called 'gate2' rules) will be stored in the ordinary DNS tree,
the definition of a new branch of the name space defined under national top level domain is envisaged in order to contain the X.400
to RFC822 mappings ('table1' and 'gate1'). A "two-way" resolution schema is thus fully implemented
The definitions, however, are detailed only until a certain level
and below it self-explaining character text strings will be used
2.
Implementations of MIXER gateways require that a database
address mapping information for X.400 and RFC822. This
must be made available (published) to all MIXER gateways. In Internetcommunity, the DNS has proven to be a practical mean providing a distributed name service. Advantages of using a DNS
system over a table based approach for mapping between O/R
and domain names are
- It avoids fetching and storing of entire mapping tables by
host that wishes to implement MIXER gateways and/or
- Modifications to the DNS based mapping information can be available in a more timely manner than with a table approach
Also many other tools, like address converters and User Agents
take advantage of the real-time availability of MIXER tables
allowing a much easier maintenance of the information
3. The domain space for X.400 O/R name
Usual domain names (the ones normally used as the global part of
RFC822 e-mail address) and their associatedinformation, i.e.,
IP addresses, mail exchanger names, etc., are stored in the DNS as
distributeddatabase under a number of top-level domains. Some top
level domains are used for traditional categories or
organisations (EDU, COM, NET, ORG, INT, MIL...). On the other
any country has its own two letter ISO country code as top-
domain (FR, DE, GB, IT, RU, ...), including "US" for USA.
special top-level/second-level couple IN-ADDR.ARPA is used to
the IP address to domain name relationship. This memo defines in
above structure the appropriate way to locate the X.400 O/R
space, thus enabling to store in DNS the MIXER mappings (MCGAMs).
- 'table1' and 'gate1' gives the translation from X.400 to RFC822;
- 'table2' and 'gate2' tables map RFC822 into X.400.
Each mapping table is composed by mapping rules, and a single
rule is composed by a keyword (the argument of the mapping
derived from the address to be translated) and a translator (
mapping functionparameter):
the '#' sign is a delimiter enclosing the translator. An example
foo.bar.us#PRMD$foo\.bar.ADMD$intx.C$us
Local mappings are not intended for use outside their environment, thus they should not be included in DNS. If mappings are used, they should be stored using static local tables
exactly as local static host tables can be used with DNS
The keyword of a 'table2' and 'gate2' table entry is a valid RFC822
domain; thus the usual domain name space can be used without
to store these entries
On the other hand, the keyword of a 'table1' and 'gate1'
belongs to the X.400 O/R name space. The X.400 O/R name space
not usually fit into the usual domain name space, although there
a number of similarities; a new name structure is thus needed represent it. This new name structurecontains the X.400
domains
To ensure the correct functioning of the DNS system, the new X.400
name structure must be hooked to the existing domain name space in
way which respects the existing name hierarchy
A possiblesolution was to create another special branch,
from the root of the DNS tree, somehow similar to the in-addr.
tree. This idea would have required to establish a central
The X.400 two letter ISO country codes, however, are the same
for the RFC822 country top-level domains and this gives us appropriate hook to insert the new branches. The proposal is,
fact, to create under each national top level ISO country code a
branch in the name space. This branch represents exactly the X.400
O/R name structure as defined in each single country, following
ADMD, PRMD, O, OU hierarchy. A unique reserved label 'X42D' is
under each country top-level domain, and hence the national X.400
name space derives its own structure
The coordination at national level also fits in the new concept
MCGAM pubblication. The DNS in fact allows a step by step distribution, up to a final completedelegation: thus
whishing to publish their MCGAM just need to receive delegation
for their branch of the new X.400 name space. A further advantage
the national based solution is to allow each country to set up
own X.400 name structure in DNS and to deploy its own delegationaccording to its local time scale and requirements,
no loss of global service in the mean time. And last, placing the
X.400 name tree and coordination process at national level fits
the Internet regionalization and internationalisation process, as
requires local bodies to take care of local coordinationproblems
The DNS name space thus contains completely the information
by an e-mail gateway or tool to perform the X.400-RFC822 mapping:
simple query to the nearest nameserverprovides it. Moreover there
no more any need to store, maintain and distribute manually
mapping table. The new X.400 name space can also contain information about the X.400 community, as DNS allows for it complete set of resource records, and thus it allows
developments. This set of RRs in the new X.400 name space must considered 'reserved' and thus not used until further specifications
4. The new DNS resource record for MIXER mapping rules:
The specification of the Internet DNS (RFC1035) provides a number specificresource records (RRs) to contain specific pieces information. In particular they contain the Mail eXchanger (MX)
and the host Address (A) records which are used by the Internet
mailers. As we will store the RFC822 to X.400 mapping information
the already existing DNS name tree, we need to define a new DNS RR
order to avoid any possible clash or misuse of already existing
structures. The same new RR will also be used to store the
from X.400 to RFC822. More over the mapping information, i.e.,
MCGAMs, has a specific format and syntax which require an
data structure and processing. A further advantage of defining a
RR is the ability to include flexibility for some eventual development
[] []
When we store in DNS a 'table1' or a 'gate1' entry, then
be an X.400 mail domain name in DNS syntax (see sect. 4.2). When
store a 'table2' or a 'gate2' table entry, will be an RFC822
mail domain name, including both fully qualified DNS domains and
only domains (MX-only domains). All normal DNS conventions,
default values, wildcards, abbreviations and message compression
apply also for all the components of the PX RR. In particular,
MAP822 and MAPX400, as elements, must have the
"." (root) when they are fully qualified
covers any RFC822 domain ending with 'net2.it', unless more
rules for some subdomain in 'net2.it' are present. Thus there is
possibility to specify explicitly a MCGAM as an exact match
rule. In DNS an entry
*.net2.it. IN PX 10 net2.it. PRMD-net2.ADMD-p400.C-it
specify the usual wildcard match as for MIXER tables. However
entry
ab.net2.it. IN PX 10 ab.net2.it. O-ab.PRMD-net2.ADMDb.C-it
is valid only for an exact match of 'ab.net2.it' RFC822 domain
Note also that in DNS syntax there is no '#' delimiter around MAP822
and MAPX400 fields: the syntax defined in sect. 4.2 in fact does
allow the (ASCII decimal 32) character within these fields
making unneeded the use of an explicit delimiter as required in
MIXER original syntax
Another extension to the MIXER specifications is the PREFERENCE
defined as part of the PX RDATA section. This numeric value
exactly the same meaning than the similar one used for the MX RR.
is thus possible to specify more than one single mapping for a
(both from RFC822 to X.400 and vice versa), giving as the
order. In MIXER static tables, however, you cannot specify more
one mapping per each RFC822 domain, and the same restriction
for any X.400 domain mapping to an RFC822 one
More over, in the X.400 recommendations a note suggests than
ADMD= should be reserved for some special cases. nationalfunctional profile specifications for an X.400 MHS
that if an X.400 PRMD is reachable via any of its national ADMDs
independently of its actual single or multipleconnectivity
them, it should use ADMD= to advertise this fact. Again, if
PRMD has no connections to any ADMD it should use ADMD=0 to
its status, etc. However, in most of the current real situations,
ADMD service providers do not accept messages coming from
subscribers if they have a blank ADMD, forcing them to have their
ADMD value. In such a situation there are problems in
properly the actually working mappings for domains with connectivity. The PX RDATA 'PREFERENCE' extension was introduced
take in consideration these problems
The syntax definition of the MCGAM rules is defined in appendix F
that document. However that syntax is not very human oriented contains a number of characters which have a special meaning in
fields of the Internet DNS. Thus in order to avoid any
problem, especially due to some old DNS implementations still
used in the Internet, we define a syntax for the X.400 part of
MCGAM rules (and hence for any X.400 O/R name) which makes
compatible with a element, i.e.,
