File: rfc2163.txt

package info (click to toggle)
doc-rfc 1999.08-1
  • links: PTS
  • area: main
  • in suites: potato
  • size: 68,428 kB
  • ctags: 6
  • sloc: sh: 2,491; perl: 390; makefile: 44
file content (1459 lines) | stat: -rw-r--r-- 58,789 bytes parent folder | download | duplicates (13)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459






Network Working Group                                       C. Allocchio
Request for Comments: 2163                                    GARR-Italy
Obsoletes: 1664                                             January 1998
Category: Standards Track


                  Using the Internet DNS to Distribute
            MIXER Conformant Global Address Mapping (MCGAM)

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

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

Abstract

   This memo is the complete technical specification to store in the
   Internet Domain Name System (DNS) the mapping information (MCGAM)
   needed by MIXER conformant e-mail gateways and other tools to map
   RFC822 domain names into X.400 O/R names and vice versa.  Mapping
   information can be managed in a distributed rather than a centralised
   way. Organizations can publish their MIXER mapping or preferred
   gateway routing information using just local resources (their local
   DNS server), avoiding the need for a strong coordination with any
   centralised organization. MIXER conformant gateways and tools located
   on Internet hosts can retrieve the mapping information querying the
   DNS instead of having fixed tables which need to be centrally updated
   and distributed.

   This memo obsoletes RFC1664. It includes the changes introduced by
   MIXER specification with respect to RFC1327: the new 'gate1' (O/R
   addresses to domain) table is fully supported. Full backward
   compatibility with RFC1664 specification is mantained, too.

   RFC1664 was a joint effort of IETF X400 operation working group
   (x400ops) and TERENA (formely named "RARE") Mail and Messaging
   working group (WG-MSG). This update was performed by the IETF MIXER
   working group.






Allocchio                   Standards Track                     [Page 1]

RFC 2163                      MIXER MCGAM                   January 1998


1. Introduction

   The connectivity between the Internet SMTP mail and other mail
   services, including the Internet X.400 mail and the commercial X.400
   service providers, is assured by the Mail eXchanger (MX) record
   information distributed via the Internet Domain Name System (DNS). A
   number of documents then specify in details how to convert or encode
   addresses from/to RFC822 style to the other mail system syntax.
   However, only conversion methods provide, via some algorithm or a set
   of mapping rules, a smooth translation, resulting in addresses
   indistinguishable from the native ones in both RFC822 and foreign
   world.

   MIXER describes a set of mappings (MIXER Conformant Global Address
   Mapping - MCGAM) which will enable interworking between systems
   operating the CCITT X.400 (1984/88/92) Recommendations and systems
   using using the RFC822 mail protocol, or protocols derived from
   RFC822. That document addresses conversion of services, addresses,
   message envelopes, and message bodies between the two mail systems.
   This document is concerned with one aspect of MIXER: the mechanism
   for mapping between X.400 O/R addresses and RFC822 domain names. As
   described in Appendix F of MIXER, implementation of the mappings
   requires a database which maps between X.400 O/R addresses and domain
   names; in RFC1327 this database was statically defined.

   The original approach in RFC1327 required many efforts to maintain
   the correct mapping: all the gateways needed to get coherent tables
   to apply the same mappings, the conversion tables had to be
   distributed among all the operational gateways, and also every update
   needed to be distributed.

   The concept of mapping rules distribution and use has been revised in
   the new MIXER specification, introducing the concept of MIXER
   Conformant Global Address Mapping (MCGAM). A MCGAM does not need to
   be globally installed by any MIXER conformant gateway in the world
   any more. However MIXER requires now efficient methods to publish its
   MCGAM.

   Static tables are one of the possible methods to publish MCGAM.
   However this static mechanism requires quite a long time to be spent
   modifying and distributing the information, putting heavy constraints
   on the time schedule of every update.  In fact it does not appear
   efficient compared to the Internet Domain Name Service (DNS).  More
   over it does not look feasible to distribute the database to a large
   number of other useful applications, like local address converters,
   e-mail User Agents or any other tool requiring the mapping rules to
   produce correct results.




Allocchio                   Standards Track                     [Page 2]

RFC 2163                      MIXER MCGAM                   January 1998


   Two much more efficient methods are proposed by MIXER for publication
   of MCGAM: the Internet DNS and X.500. This memo is the complete
   technical specification for publishing MCGAM via Internet DNS.

   A first proposal to use the Internet DNS to store, retrieve and
   maintain those mappings was introduced by two of the authors of
   RFC1664 (B. Cole and R. Hagens) adopting two new DNS resource record
   (RR)  types: TO-X400 and TO-822. This proposal now adopts a more
   complete strategy, and requires one new RR only. The distribution of
   MCGAMs via DNS is in fact an important service for the whole Internet
   community: it completes the information given by MX resource record
   and it allows to produce clean addresses when messages are exchanged
   among the Internet RFC822 world and the X.400 one (both Internet and
   Public X.400 service providers).

   A first experiment in using the DNS without expanding the current set
   of RR and using available ones was deployed by some of the authors of
   RFC1664 at the time of its development. 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 of the
   experiment was positive, and a few test applications ran under this
   provisional set up. This test was also very useful in order to define
   a possible migration strategy during the deployment of the new DNS
   containing the new RR. The Internet DNS nameservers wishing to
   provide this mapping information need in fact to be modified to
   support the new RR type, and in the real Internet, due to the large
   number of different implementations, this takes some time.

   The basic idea is to adopt a new DNS RR to store the mapping
   information. The RFC822 to X.400 mapping rules (including the so
   called 'gate2' rules) will be stored in the ordinary DNS tree, while
   the definition of a new branch of the name space defined under each
   national top level domain is envisaged in order to contain the X.400
   to RFC822 mappings ('table1' and 'gate1'). A "two-way" mapping
   resolution schema is thus fully implemented.

   The creation of the new domain name space representing the X.400 O/R
   names structure also provides the chance to use the DNS to distribute
   dynamically other X.400 related information, thus solving other
   efficiency problems currently affecting the X.400 MHS service.

   In this paper we will adopt the MCGAM syntax, showing how it can be
   stored into the Internet DNS.








Allocchio                   Standards Track                     [Page 3]

RFC 2163                      MIXER MCGAM                   January 1998


1.1 Definitions syntax

   The definitions in this document is given in BNF-like syntax, using
   the following conventions:

      |   means choice
      \   is used for continuation of a definition over several lines
      []  means optional
      {}  means repeated one or more times

   The definitions, however, are detailed only until a certain level,
   and below it self-explaining character text strings will be used.

2. Motivation

   Implementations of MIXER gateways require that a database store
   address mapping information for X.400 and RFC822. This information
   must be made available (published) to all MIXER gateways. In the
   Internet community, the DNS has proven to be a practical mean for
   providing a distributed name service. Advantages of using a DNS based
   system over a table based approach for mapping between O/R addresses
   and domain names are:

     - It avoids fetching and storing of entire mapping tables by every
       host that wishes to implement MIXER gateways and/or tools

     - Modifications to the DNS based mapping information can be made
       available in a more timely manner 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
       MIXER gateways.

     - One can determine the mappings in use by a remote gateway by
       querying the DNS (remote debugging).

   Also many other tools, like address converters and User Agents can
   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 addresses

   Usual domain names (the ones normally used as the global part of an
   RFC822 e-mail address) and their associated information, i.e., host
   IP addresses, mail exchanger names, etc., are stored in the DNS as a



Allocchio                   Standards Track                     [Page 4]

RFC 2163                      MIXER MCGAM                   January 1998


   distributed database under a number of top-level domains. Some top-
   level domains are used for traditional categories or international
   organisations (EDU, COM, NET, ORG, INT, MIL...). On the other hand
   any country has its own two letter ISO country code as top-level
   domain (FR, DE, GB, IT, RU, ...), including "US" for USA.  The
   special top-level/second-level couple IN-ADDR.ARPA is used to store
   the IP address to domain name relationship. This memo defines in the
   above structure the appropriate way to locate the X.400 O/R name
   space, thus enabling to store in DNS the MIXER mappings (MCGAMs).

   The MIXER mapping information is composed by four tables:

    - '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 mapping
   rule is composed by a keyword (the argument of the mapping function
   derived from the address to be translated) and a translator (the
   mapping function parameter):

                            keyword#translator#

   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 restricted
   environment, thus they should not be included in DNS. If local
   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 problems
   to store these entries.
   On the other hand, the keyword of a 'table1' and 'gate1' entry
   belongs to the X.400 O/R name space. The X.400 O/R name space does
   not usually fit into the usual domain name space, although there are
   a number of similarities; a new name structure is thus needed to
   represent it. This new name structure contains the X.400 mail
   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 a
   way which respects the existing name hierarchy.

   A possible solution was to create another special branch, starting
   from the root of the DNS tree, somehow similar to the in-addr.arpa
   tree. This idea would have required to establish a central authority



Allocchio                   Standards Track                     [Page 5]

RFC 2163                      MIXER MCGAM                   January 1998


   to coordinate at international level the management of each national
   X.400 name tree, including the X.400 public service providers. This
   coordination problem is a heavy burden if approached globally. More
   over the X.400 name structure is very 'country oriented': thus while
   it requires a coordination at national level, it does not have
   concepts like the international root. In fact the X.400 international
   service is based  on a large number of bilateral agreements, and only
   within some communities an international coordination service exists.

   The X.400 two letter ISO country codes, however, are the same used
   for the RFC822 country top-level domains and this gives us an
   appropriate hook to insert the new branches. The proposal is, in
   fact, 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 each single country, following the
   ADMD, PRMD, O, OU hierarchy. A unique reserved label 'X42D' is placed
   under each country top-level domain, and hence the national X.400
   name space derives 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
             |               |                 |              |
            ...             ...               ...            ...


   The creation of the X.400 new name tree at national level solves the
   problem of the international coordination. Actually the coordination
   problem is just moved at national level, but it thus becomes easier
   to solve. The coordination at national level between the X.400
   communities and the Internet world is already a requirement for the
   creation of the national static MIXER mapping tables; the use of the
   Internet DNS gives further motivations for this coordination.




Allocchio                   Standards Track                     [Page 6]

RFC 2163                      MIXER MCGAM                   January 1998


   The coordination at national level also fits in the new concept of
   MCGAM pubblication. The DNS in fact allows a step by step authority
   distribution, up to a final complete delegation: thus organizations
   whishing to publish their MCGAM just need to receive delegation also
   for their branch of the new X.400 name space. A further advantage of
   the national based solution is to allow each country to set up its
   own X.400 name structure in DNS and to deploy its own authority
   delegation according to its local time scale and requirements, with
   no loss of global service in the mean time. And last, placing the new
   X.400 name tree and coordination process at national level fits into
   the Internet regionalization and internationalisation process, as it
   requires local bodies to take care of local coordination problems.

   The DNS name space thus contains completely the information required
   by an e-mail gateway or tool to perform the X.400-RFC822 mapping: a
   simple query to the nearest nameserver provides it. Moreover there is
   no more any need to store, maintain and distribute manually any
   mapping table. The new X.400 name space can also contain further
   information about the X.400 community, as DNS allows for it a
   complete set of resource records, and thus it allows further
   developments. This set of RRs in the new X.400 name space must be
   considered 'reserved' and thus not used until further specifications.

   The construction of the new domain space trees will follow the same
   procedures used when organising at first the already existing DNS
   space: at first the information will be stored in a quite centralised
   way, and distribution of authority will be gradually achieved. A
   separate document will describe the implementation phase and the
   methods to assure a smooth introduction of the new service.

4. The new DNS resource record for MIXER mapping rules: PX

   The specification of the Internet DNS (RFC1035) provides a number of
   specific resource records (RRs) to contain specific pieces of
   information. In particular they contain the Mail eXchanger (MX) RR
   and the host Address (A) records which are used by the Internet SMTP
   mailers. As we will store the RFC822 to X.400 mapping information in
   the already existing DNS name tree, we need to define a new DNS RR in
   order to avoid any possible clash or misuse of already existing data
   structures. The same new RR will also be used to store the mappings
   from X.400 to RFC822. More over the mapping information, i.e., the
   MCGAMs, has a specific format and syntax which require an appropriate
   data structure and processing. A further advantage of defining a new
   RR is the ability to include flexibility for some eventual future
   development.






Allocchio                   Standards Track                     [Page 7]

RFC 2163                      MIXER MCGAM                   January 1998


   The definition of the new 'PX' DNS resource record is:

      class:        IN   (Internet)

      name:         PX   (pointer to X.400/RFC822 mapping information)

      value:        26

   The PX RDATA format is:

          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
          |                  PREFERENCE                   |
          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
          /                    MAP822                     /
          /                                               /
          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
          /                    MAPX400                    /
          /                                               /
          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

   where:

   PREFERENCE   A 16 bit integer which 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>, the
                RFC822 part of the MCGAM;

   MAPX400      A <domain-name> element containing the value of
                <x400-in-domain-syntax> derived from the X.400 part of
                the MCGAM (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 in DNS a 'table1' or a 'gate1' entry, then <name> will
   be an X.400 mail domain name in DNS syntax (see sect. 4.2). When we
   store a 'table2' or a 'gate2' table entry, <name> will be an RFC822
   mail domain name, including both fully qualified DNS domains and mail
   only domains (MX-only domains). All normal DNS conventions, like
   default values, wildcards, abbreviations and message compression,
   apply also for all the components of the PX RR. In particular <name>,
   MAP822 and MAPX400, as <domain-name> elements, must have the final
   "." (root) when they are fully qualified.




Allocchio                   Standards Track                     [Page 8]

RFC 2163                      MIXER MCGAM                   January 1998


4.1 Additional features of the PX resource record

   The definition of the RDATA for the PX resource record, and the fact
   that DNS allows a distinction between an exact value and a wildcard
   match for the <name> parameter, represent an extension of the MIXER
   specification for mapping rules. In fact, any MCGAM entry is an
   implicit wildcard entry, i.e., the rule

      net2.it#PRMD$net2.ADMD$p400.C$it#

   covers any RFC822 domain ending with 'net2.it', unless more detailed
   rules for some subdomain in 'net2.it' are present. Thus there is no
   possibility to specify explicitly a MCGAM as an exact match only
   rule. In DNS an entry like

      *.net2.it.   IN  PX  10   net2.it.  PRMD-net2.ADMD-p400.C-it.

   specify the usual wildcard match as for MIXER tables. However an
   entry like

      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 not
   allow the <blank> (ASCII decimal 32) character within these fields,
   making unneeded the use of an explicit delimiter as required in the
   MIXER original syntax.

   Another extension to the MIXER specifications is the PREFERENCE value
   defined as part of the PX RDATA section. This numeric value has
   exactly the same meaning than the similar one used for the MX RR. It
   is thus possible to specify more than one single mapping for a domain
   (both from RFC822 to X.400 and vice versa), giving as the preference
   order. In MIXER static tables, however, you cannot specify more than
   one mapping per each RFC822 domain, and the same restriction apply
   for any X.400 domain mapping to an RFC822 one.

   More over, in the X.400 recommendations a note suggests than an
   ADMD=<blank> should be reserved for some special cases. Various
   national functional profile specifications for an X.400 MHS states
   that if an X.400 PRMD is reachable via any of its national ADMDs,
   independently of its actual single or multiple connectivity with
   them, it should use ADMD=<blank> to advertise this fact. Again, if a
   PRMD has no connections to any ADMD it should use ADMD=0 to notify
   its status, etc. However, in most of the current real situations, the
   ADMD service providers do not accept messages coming from their



Allocchio                   Standards Track                     [Page 9]

RFC 2163                      MIXER MCGAM                   January 1998


   subscribers if they have a blank ADMD, forcing them to have their own
   ADMD value. In such a situation there are problems in indicating
   properly the actually working mappings for domains with multiple
   connectivity. The PX RDATA 'PREFERENCE' extension was introduced to
   take in consideration these problems.

   However, as these extensions are not available with MIXER static
   tables, it is strongly discouraged to use them when interworking with
   any table based gateway or application. The extensions were in fact
   introduced just to add more flexibility, like the PREFERENCE value,
    or they were already implicit in the DNS mechanism, like the
   wildcard specification. They should be used very carefully or just
   considered 'reserved for future use'. In particular, for current use,
   the PREFERENCE value in the PX record specification should be fixed
   to a value of 50, and only wildcard specifications should be used
   when specifying <name> values.

4.2 The DNS syntax for an X.400 'domain'

   The syntax definition of the MCGAM rules is defined in appendix F of
   that document. However that syntax is not very human oriented and
   contains a number of characters which have a special meaning in other
   fields of the Internet DNS. Thus in order to avoid any possible
   problem, especially due to some old DNS implementations still being
   used in the Internet, we define a syntax for the X.400 part of any
   MCGAM rules (and hence for any X.400 O/R name) which makes it
   compatible with a <domain-name> element, i.e.,

   <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> does not correspond to the IA5 Printablestring one used in
   MIXER to define MCGAM rules. However a very simple "escape mechanism"
   can be applied in order to bypass the problem. We can in fact simply
   describe the X.400 part of a MCGAM rule format as:

     <map-rule>   ::= <map-elem> | <map-elem> { "." <map-elem> }
     <map-elem>   ::= <attr-label> "$" <attr-value>
     <attr-label> ::= "C" | "ADMD" | "PRMD" | "O" | "OU"
     <attr-value> ::= " " | "@" | IA5-Printablestring






Allocchio                   Standards Track                    [Page 10]

RFC 2163                      MIXER MCGAM                   January 1998


   As you can notice <domain-name> and <map-rule> look similar, and also
   <label> and <map-elem> look the same. If we define the correct method
   to transform a <map-elem> into a <label> and vice versa the problem
   to write a MCGAM rule in <domain-name> syntax is solved.

   The RFC822 domain part of any MCGAM rule is of course already in
   <domain-name> syntax, and thus remains unchanged.

   In particular, in a 'table1' or 'gate1' 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.  Vice versa in a 'table2' or 'gate2' 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

   The problem of unmatching IA5-Printablestring and <label> character
   set definition is solved by a simple character mapping rule: whenever
   an IA5 character does not belong to <alphanumhyphen>, then it is
   mapped using its 3 digit decimal ASCII code, enclosed in hyphens. A
   small set of special rules is also defined for the most frequent
   cases. Moreover some frequent characters combinations used in MIXER
   rules are also mapped as special cases.

   Let's then define the following simple rules:

    MCGAM 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         elsewhere

   Non <alphanumhyphen> characters in <attr-value>:

    MCGAM rule            DNS store translation    conditions
    -----------------------------------------------------------------
    -                     -h-                      hyphen
    \.                    -d-                      quoted dot
    <blank>               -b-                      blank
    <non A/N character>   -<3digit-decimal>-       elsewhere

   If the DNS store translation of <attr-value> happens to end with an
   hyphen, then this last hyphen is omitted.

   Let's now have some examples:





Allocchio                   Standards Track                    [Page 11]

RFC 2163                      MIXER MCGAM                   January 1998


    MCGAM 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 mapping

   Thus, an X.400 part from a MCGAM like

     OU$uuu.O$@.PRMD$ppp\.rrr.ADMD$aaa ddd-mmm.C$cc

   translates to

     OU-uuu.O.PRMD-ppp-d-rrr.ADMD-aaa-b-ddd-h-mmm.C-cc

   Another example:

     OU$sales dept\..O$@.PRMD$ACME.ADMD$ .C$GB

   translates to

     OU-sales-b-dept-d.O.PRMD-ACME.ADMDb.C-GB

4.2.2 Flow chart

   In order to achieve the proper DNS store translations of the X.400
   part of a MCGAM or any other X.400 O/R name, some software tools will
   be used. It is in fact evident that the above rules for converting
   mapping table from MIXER to DNS format (and vice versa) are not user
   friendly enough to think of a human made conversion.

   To help in designing such tools, we describe hereunder a small flow
   chart. The fundamental rule to be applied during translation is,
   however, the following:

      "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."








Allocchio                   Standards Track                    [Page 12]

RFC 2163                      MIXER MCGAM                   January 1998


   Flow chart 1 - Translation from MIXER 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 MIXER 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)




Allocchio                   Standards Track                    [Page 13]

RFC 2163                      MIXER MCGAM                   January 1998


   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.

   The RFC822 domain space and the X.400 O/R address space, as said in
   section 3, have one specific common feature: the X.400 ISO country
   codes are the same as the RFC822 ISO top level domains for countries.
   In the previous sections we have also defined a method to write in
   <domain-name> syntax any X.400 domain, while in section 3 we
   described the new name space starting at each country top level
   domain under the X42D.cc (where 'cc' is then two letter ISO country
   code).

   The <name> value for a 'table1' or 'gate1' entry in DNS should thus
   be derived from the X.400 domain value, translated to <domain-name>
   syntax, adding the 'X42D.cc.' post-fix to it, i.e.,

     ADMD$acme.C$fr

   produces in <domain-name> syntax the key:

     ADMD-acme.C-fr

   which is post-fixed by 'X42D.fr.' resulting in:

     ADMD-acme.C-fr.X42D.fr.

   However, due to the identical encoding for X.400 country codes and
   RFC822 country top level domains, the string 'C-fr.X42D.fr.' is
   clearly redundant.

   We thus define the 'Country Code convention' for the <name> key,
   i.e.,

     "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".

   Thus we obtain the following <name> key examples:

   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.




Allocchio                   Standards Track                    [Page 14]

RFC 2163                      MIXER MCGAM                   January 1998


4.3 Creating the appropriate DNS files

   Using MIXER's assumption of an asymmetric mapping between X.400 and
   RFC822 addresses, two separate relations are required to store the
   mapping database: MIXER 'table1' and MIXER 'table2'; thus also in DNS
   we will maintain the two different sections, even if they will both
   use the PX resource record. More over MIXER also specify two
   additional tables: MIXER 'gate1' and 'gate2' tables. These additional
   tables, however, have the same syntax rules than MIXER 'table1' and
   'table2' respectively, and thus the same translation procedure as
   'table1' and 'table2' will be applied; some details about the MIXER
   'gate1' and 'gate2' tables are discussed in section 4.4.

   Let's now check how to create, from an MCGAM entry, the appropriate
   DNS entry in a DNS data file. We can again define an MCGAM entry as
   defined in appendix F of that document as:

     <x400-domain>#<rfc822-domain>#  (case A: 'table1' and 'gate1'
     entry)

   and

     <rfc822-domain>#<x400-domain>#  (case B: 'table2' and 'gate2'
     entry)

   The two cases must be considered separately. Let's consider case A.

    - take <x400-domain> and translate it into <domain-name> syntax,
     obtaining <x400-in-domain-syntax>;
    - create the <name> key from <x400-in-domain-syntax> i.e., apply
     the Country Code convention described in sect. 4.2.3;
    - construct the DNS PX record as:

      *.<name>  IN  PX  50  <rfc822-domain>  <x400-in-domain-syntax>

   Please note that within PX RDATA the <rfc822-domain> precedes the
   <x400-in-domain-syntax> also for a 'table1' and 'gate1' entry.

   an example: from the 'table1' rule

     PRMD$ab.ADMD$ac.C$fr#ab.fr#

   we obtain

     *.PRMD-ab.ADMD-ac.X42D.fr. IN PX 50  ab.fr.  PRMD-ab.ADMD-ac.C-fr.

   Note that <name>, <rfc822-domain> and <x400-in-domain-syntax> are
   fully qualified <domain-name> elements, thus ending with a ".".



Allocchio                   Standards Track                    [Page 15]

RFC 2163                      MIXER MCGAM                   January 1998


   Let's now consider case B.

    - take <rfc822-domain> as <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>

   an example: from the 'table2' rule

     ab.fr#PRMD$ab.ADMD$ac.C$fr#

   we obtain

     *.ab.fr.  IN  PX  50  ab.fr.  PRMD-ab.ADMD-ac.C-fr.

   Again note the fully qualified <domain-name> elements.

   A file containing the MIXER mapping rules and MIXER 'gate1' and
   'gate2' table written in DNS format will look like the following
   fictious example:

     !
     ! MIXER 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.
     !
     ! MIXER 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.
     !
     ! MIXER Gate 1 Table
     !
     *.ADMD-XKW-h-Mail.X42D.it.         IN  PX  50   \
                            XKW-gateway.it. ADMD-XKW-h-Mail.C-it.G.
     *.PRMD-Super-b-Inc.ADMDb.X42D.it.  IN  PX  50   \
                            GlobalGw.it. PRMD-Super-b-Inc.ADMDb.C-it.G.
     !
     ! MIXER Gate 2 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.



Allocchio                   Standards Track                    [Page 16]

RFC 2163                      MIXER MCGAM                   January 1998


   (here the "\" indicates continuation on the same line, as wrapping is
   done only due to typographical reasons).

   Note the special suffix ".G." on the right side of the 'gate1' and
   'gate2' Tables section whose aim is described in section 4.4. The
   corresponding MIXER tables are:

     #
     # MIXER 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#
     #
     # MIXER 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#
     #
     # MIXER Gate 1 Table
     #
     ADMD$XKW-Mail.C$it#XKW-gateway.it#
     PRMD$Super Inc.ADMD$ .C$it#GlobalGw.it#
     #
     # MIXER Gate 2 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 MIXER 'gate1' and 'gate2' tables

   Section 4.3.4 of MIXER also specify how an address should be
   converted between RFC822 and X.400 in case a complete mapping is
   impossible. To allow the use of DDAs for non mappable domains, the
   MIXER 'gate2' table is thus introduced.

   In a totally similar way, when an X.400 address cannot be completely
   converted in RFC822, section 4.3.5 of MIXER specifies how to encode
   (LHS encoding) the address itself, pointing then to the appropriate
   MIXER conformant gateway, indicated in the MIXER 'gate1' table.

   DNS must store and distribute also these 'gate1' and 'gate2' data.

   One of the major features of the DNS is the ability to distribute the
   authority: a certain site runs the "primary" nameserver for one
   determined sub-tree and thus it is also the only place allowed to
   update information regarding that sub-tree. This fact allows, in our



Allocchio                   Standards Track                    [Page 17]

RFC 2163                      MIXER MCGAM                   January 1998


   case, a further additional feature to the table based approach. In
   fact we can avoid one possible ambiguity about the use of the 'gate1'
   and 'gate2' tables (and thus of LHS and DDAs encoding).

   The authority maintaining a DNS entry in the usual RFC822 domain
   space is the only one allowed to decide if its domain should be
   mapped using Standard Attributes (SA) syntax or Domain Defined
   Attributes (DDA) one. If the authority decides that its RFC822 domain
   should be mapped using SA, then the PX RDATA will be a 'table2'
   entry, otherwise it will be a 'gate2' table entry. Thus for an RFC822
   domain we cannot have any more two possible entries, one from 'table2
   and another one from 'gate2' table, and the action for a gateway
   results clearly stated.

   Similarly, the authority mantaining a DNS entry in the new X.400 name
   space is the only one allowed to decide if its X.400 domain should be
   mapped using SA syntax or Left Hand Side (LHS) encoding. If the
   authority decides that its X.400 domain should be mapped using SA,
   then the PX RDATA will be a 'table1' entry, otherwise it will be a
   'gate1' table entry. Thus also for an X.400 domain we cannot have any
   more two possible entries, one from 'table1' and another one from
   'gate1' table, and the action for a gateway results clearly stated.

   The MIXER 'gate1' table syntax is actually identical to MIXER
   'table1', and 'gate2' table syntax is identical to MIXER 'table2'.
   Thus the same syntax translation rules from MIXER to DNS format can
   be applied in both cases. However a gateway or any other application
   must know if the answer it got from DNS contains some 'table1',
   'table2' or some 'gate1', 'gate2' table information. This is easily
   obtained flagging with an additional ".G." post-fix the PX RDATA
   value when it contains a 'gate1' or 'gate2' table entry. The example
   in section 4.3 shows clearly the result. As any X.400 O/R domain must
   end with a country code ("C-xx" in our DNS syntax) the additional
   ".G." creates no conflicts or ambiguities at all. This postfix must
   obviously be removed before using the MIXER 'gate1' or 'gate2' table
   data.

5. Finding MIXER mapping information from DNS

   The MIXER mapping information is stored in DNS both in the normal
   RFC822 domain name space, and in the newly defined X.400 name space.
   The information, stored in PX resource records, does not represent a
   full RFC822 or X.400 O/R address: it is a template which specifies
   the fields of the domain that are used by the mapping algorithm.

   When mapping information is stored in the DNS, queries to the DNS are
   issued whenever an iterative search through the mapping table would
   be performed (MIXER: section 4.3.4, State I; section 4.3.5, mapping



Allocchio                   Standards Track                    [Page 18]

RFC 2163                      MIXER MCGAM                   January 1998


   B). Due to the DNS search mechanism, DNS by itself returns the
   longest possible match in the stored mapping rule with a single
   query, thus no iteration and/or multiple queries are needed. As
   specified in MIXER, a search of the mapping table will result in
   either success (mapping found) or failure (query failed, mapping not
   found).

   When a DNS query is issued, a third possible result is timeout. If
   the result is timeout, the gateway operation is delayed and then
   retried at a later time. A result of success or failure is processed
   according to the algorithms specified in MIXER. If a DNS error code
   is returned, an error message should be logged and the gateway
   operation is delayed as for timeout. These pathological situations,
   however, should be avoided with a careful duplication and chaching
   mechanism which DNS itself provides.

   Searching the nameserver which can authoritatively solve the query is
   automatically performed by the DNS distributed name service.

5.1 A DNS query example

   An MIXER mail-gateway located in the Internet, when translating
   addresses from RFC822 to X.400, can get information about the MCGAM
   rule asking the DNS. As an example, when translating the address
   SUN.CCE.NRC.IT, the gateway will just query DNS for the associated PX
   resource record. The 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.

   The first query will return immediately the appropriate mapping rule
   in DNS store format.

   There is no ".G." at the end of the obtained PX RDATA value, thus
   applying the syntax translation specified in paragraph 4.2 the MIXER
   Table 2 mapping rule will be obtained.

   Let's now take another example where a 'gate2' table rule is
   returned.  If we are looking for an RFC822 domain ending with top
   level domain "MW", and the DNS contains a PX record like this,

      *.mw.   IN  PX  50  mw.  O-cce.PRMD-nrc.ADMD-acme.C-it.G.

   DNS will return 'mw.' and 'O-cce.PRMD-nrc.ADMD-acme.C-it.G.', i.e., a
   'gate2' table entry in DNS store format. Dropping the final ".G." and
   applying the syntax translation specified in paragraph 4.2 the
   original rule will be available. More over, the ".G." flag also tells
   the gateway to use DDA encoding for the inquired RFC822 domain.




Allocchio                   Standards Track                    [Page 19]

RFC 2163                      MIXER MCGAM                   January 1998


   On the other hand, translating from X.400 to RFC822 the address

      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' described in 4.2.3 to derive
   the appropriate DNS translation of the X.400 O/R name and then query
   DNS for the corresponding PX resource record. The obtained record for
   which the PX record must be queried is thus:

      O-top.PRMD-nfc.ADMD-pkz.X42D.de.

   The DNS could contain:

      *.ADMD-pkz.X42D.de.  IN  PX  50  pkz.de.  ADMD-pkz.C-de.

   Assuming that there are not more specific records in DNS, the
   wildcard mechanism will return the MIXER 'table1' rule in encoded
   format.

   Finally, an example where a 'gate1' rule is involved. If we are
   looking for an X.400 domain ending with ADMD=PWT400; C=US; , and the
   DNS contains a PX record like this,

      *.ADMD-PWT400.X42D.us.  IN  PX  50  intGw.com. ADMD-PWT400.C-us.G.

   DNS will return 'intGw.com.' and 'ADMD-PWT400.C-us.G.', i.e., a
   'gate1' table entry in DNS store format. Dropping the final ".G." and
   applying the syntax translation specified in paragraph 4.2 the
   original rule will be available. More over, the ".G." flag also tells
   the gateway to use LHS encoding for the inquired X.400 domain.

6. Administration of mapping information

   The DNS, using the PX RR, is able to distribute the MCGAM rules to
   all MIXER gateways located on the Internet. However, not all MIXER
   gateways will be able to use the Internet DNS. It is expected that
   some gateways in a particular management domain will conform to one
   of the following models:

     (a) Table-based, (b) DNS-based, (c) X.500-based

   Table-based management domains will continue to publish their MCGAM
   rules and retrieve the mapping tables via the International Mapping
   Table coordinator, manually or via some automated procedures. Their
   MCGAM information can be made available also in DNS by the
   appropriate DNS authorities, using the same mechanism already in
   place for MX records: if a branch has not yet in place its own DNS



Allocchio                   Standards Track                    [Page 20]

RFC 2163                      MIXER MCGAM                   January 1998


   server, some higher authority in the DNS tree will provide the
   service for it. A transition procedure similar to the one used to
   migrate from the 'hosts.txt' tables to DNS can be applied also to the
   deployment phase of this specification. An informational document
   describing the implementation phase and the detailed coordination
   procedures is expected.

   Another distributed directory service which can distribute the MCGAM
   information is X.500. Coordination with table-based domains can be
   obtained in an identical way as for the DNS case.

   Coordination of MCGAM information between DNS and X.500 is more
   complex, as it requies some kind of uploading information between the
   two systems. The ideal solution is a dynamic alignment mechanism
   which transparently makes the DNS mapping information available in
   X.500 and vice versa. Some work in this specific field is already
   being done [see Costa] which can result in a global transparent
   directory service, where the information is stored in DNS or in
   X.500, but is visible completely by any of the two systems.

   However we must remind that MIXER concept of MCGAM rules publication
   is different from the old RFC1327 concept of globally distributed,
   coordinated and unique mapping rules. In fact MIXER does not requires
   any more for any conformant gateway or tool to know the complete set
   of MCGAM: it only requires to use some set (eventually empty) of
   valid MCGAM rules, published either by Tables, DNS or X.500
   mechanisms or any combination of these methods. More over MIXER
   specifies that also incomplete sets of MCGAM can be used, and
   supplementary local unpublished (but valid) MCGAM can also be used.
   As a consequence, the problem of coordination between the three
   systems proposed by MIXER for MCGAM publication is non essential, and
   important only for efficient operational matters. It does not in fact
   affect the correct behaviour of MIXER conformant gateways and tools.

7. Conclusion

   The introduction of the new PX resource record and the definition of
   the X.400 O/R name space in the DNS structure provide a good
   repository for MCGAM information. The mapping information is stored
   in the DNS tree structure so that it can be easily obtained using the
   DNS distributed name service. At the same time the definition of the
   appropriate DNS space for X.400 O/R names provide a repository where
   to store and distribute some other X.400 MHS information. The use of
   the DNS has many known advantages in storing, managing and updating
   the information. A successful number of tests were been performed
   under the provisional top level domain "X400.IT" when RFC1664 was
   developed, and their results confirmed the advantages of the method.
   Operational exeprience for over 2 years with RFC1664 specification



Allocchio                   Standards Track                    [Page 21]

RFC 2163                      MIXER MCGAM                   January 1998


   confirmed the feasibility of the method, and helped identifying some
   operational procedures to deploy the insertion of MCGAM into DNS.

   Software to query the DNS and then to convert between the textual
   representation of DNS resource records and the address format defined
   in MIXER was developed with RFC1664. This software also allows a
   smooth implementation and deployment period, eventually taking care
   of the transition phase. This software can be easily used (with
   little or null modification) also for this updated specification,
   supporting the new 'gate1' MIXER table. DNS software implementations
   supporting RFC1664 also supports with no modification this memo new
   specification.







































Allocchio                   Standards Track                    [Page 22]

RFC 2163                      MIXER MCGAM                   January 1998


   A further informational document describing operational and
   implementation of the service is expected.

8. Acknowledgements

   We wish to thanks all those who contributed to the discussion and
   revision of this document: many of their ideas and suggestions
   constitute essential parts of this work. In particular thanks to Jon
   Postel, Paul Mockapetris, Rob Austin and the whole IETF x400ops,
   TERENA wg-msg and IETF namedroppers groups. A special mention to
   Christian Huitema for his fundamental contribution to this work.

   This document is a revision of RFC1664, edited by one of its authors
   on behalf of the IETF MIXER working group. The current editor wishes
   to thank here also the authors of RFC1664:

     Antonio Blasco Bonito     RFC822: bonito@cnuce.cnr.it
     CNUCE - CNR               X.400:  C=it;A=garr;P=cnr;
     Reparto infr. reti                O=cnuce;S=bonito;
     Viale S. Maria 36
     I 56126 Pisa
     Italy


     Bruce Cole                RFC822: bcole@cisco.com
     Cisco Systems Inc.        X.400:  C=us;A= ;P=Internet;
     P.O. Box 3075                     DD.rfc-822=bcole(a)cisco.com;
     1525 O'Brien Drive
     Menlo Park, CA 94026
     U.S.A.


     Silvia Giordano           RFC822: giordano@cscs.ch
     Centro Svizzero di        X.400:  C=ch;A=arcom;P=switch;O=cscs;
     Calcolo Scientifico               S=giordano;
     Via Cantonale
     CH 6928 Manno
     Switzerland


     Robert Hagens                   RFC822: hagens@ans.net
     Advanced Network and Services   X.400:  C=us;A= ;P=Internet;
     1875 Campus Commons Drive               DD.rfc-822=hagens(a)ans.net;
     Reston, VA 22091
     U.S.A.






Allocchio                   Standards Track                    [Page 23]

RFC 2163                      MIXER MCGAM                   January 1998


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.

   [RFC 2156] Kille, S. E., " MIXER (Mime Internet X.400 Enhanced
       Relay): Mapping between X.400 and RFC 822/MIME", RFC 2156,
       January 1998.

   [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.

10. Security Considerations

   This document specifies a means by which DNS "PX" records can direct
   the translation between X.400 and Internet mail addresses.

   This can indirectly affect the routing of mail across an gateway
   between X.400 and Internet Mail.  A succesful attack on this service
   could cause incorrect translation of an originator address (thus
   "forging" the originator address), or incorrect translation of a
   recipient address (thus directing the mail to an unauthorized
   recipient, or making it appear to an authorized recipient, that the
   message was intended for recipients other than those chosen by the
   originator) or could force the mail path via some particular gateway
   or message transfer agent where mail security can be affected by
   compromised software.








Allocchio                   Standards Track                    [Page 24]

RFC 2163                      MIXER MCGAM                   January 1998


   There are several means by which an attacker might be able to deliver
   incorrect PX records to a client.  These include: (a) compromise of a
   DNS server,  (b) generating a counterfeit response to a client's DNS
   query, (c) returning incorrect "additional information" in response
   to an unrelated query.

   Clients using PX records SHOULD ensure that routing and address
   translations are based only on authoritative answers.  Once DNS
   Security mechanisms [RFC 2065] become more widely deployed, clients
   SHOULD employ those mechanisms to verify the authenticity and
   integrity of PX records.

11. Author's Address

   Claudio Allocchio
   Sincrotrone Trieste
   SS 14 Km 163.5 Basovizza
   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 3758565


























Allocchio                   Standards Track                    [Page 25]

RFC 2163                      MIXER MCGAM                   January 1998


12.  Full Copyright Statement

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

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

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

   This document and the information contained herein is 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.
























Allocchio                   Standards Track                    [Page 26]