File: rfc2162.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (1907 lines) | stat: -rw-r--r-- 58,553 bytes parent folder | download | duplicates (5)
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
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627
1628
1629
1630
1631
1632
1633
1634
1635
1636
1637
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647
1648
1649
1650
1651
1652
1653
1654
1655
1656
1657
1658
1659
1660
1661
1662
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683
1684
1685
1686
1687
1688
1689
1690
1691
1692
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706
1707
1708
1709
1710
1711
1712
1713
1714
1715
1716
1717
1718
1719
1720
1721
1722
1723
1724
1725
1726
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738
1739
1740
1741
1742
1743
1744
1745
1746
1747
1748
1749
1750
1751
1752
1753
1754
1755
1756
1757
1758
1759
1760
1761
1762
1763
1764
1765
1766
1767
1768
1769
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794
1795
1796
1797
1798
1799
1800
1801
1802
1803
1804
1805
1806
1807
1808
1809
1810
1811
1812
1813
1814
1815
1816
1817
1818
1819
1820
1821
1822
1823
1824
1825
1826
1827
1828
1829
1830
1831
1832
1833
1834
1835
1836
1837
1838
1839
1840
1841
1842
1843
1844
1845
1846
1847
1848
1849
1850
1851
1852
1853
1854
1855
1856
1857
1858
1859
1860
1861
1862
1863
1864
1865
1866
1867
1868
1869
1870
1871
1872
1873
1874
1875
1876
1877
1878
1879
1880
1881
1882
1883
1884
1885
1886
1887
1888
1889
1890
1891
1892
1893
1894
1895
1896
1897
1898
1899
1900
1901
1902
1903
1904
1905
1906
1907






Network Working Group                                      C. Allocchio
Request for Comments: 2162                             I.N.F.N. - Italy
Obsoletes: 1405                                            January 1998
Category: Experimental


           MaXIM-11 - Mapping between X.400 / Internet mail
                                  and
                              Mail-11 mail

Status of this Memo

   This memo defines an Experimental Protocol for the Internet
   community.  It does not specify an Internet standard of any kind.
   Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

Copyright Notice

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

Abstract

   This document describes a set of mappings which will enable inter
   working between systems operating the ISO/IEC 10021 - CCITT (now ITU)
   X.400 Recommendations on Message Handling Systems, and systems
   running the Mail-11 (also known as DECnet mail or VMSmail) protocol.
   The specifications are valid both within DECnet Phase IV and
   DECnet/OSI addressing and routing scheme.

   The complete scenario of X.400 / MIME / Mail-11 is also considered,
   in order to cover the possible complex cases arising in multiple
   gateway translations.

   This document covers mainly the X.400 O/R address to/from Mail-11
   address mapping and the RFC822 to/from Mail-11 ones; other mappings
   are based on MIXER specifications. Bodypart mappings are not
   specified in this document: MIXER and MIME-MHS specifications can be
   applied to map bodyparts between X.400, MIME and Mail-11, too. In
   fact MIME encoding can be used without modifications within Mail-11
   text bodyparts.

   This document obsoletes RFC 1405, which was a combined effort of
   TERENA Working Group on Messaging, and the IETF X.400 Ops Working
   Group. This update was prepared by IETF MIXER working group.






Allocchio                     Experimental                      [Page 1]

RFC 2162                        MaXIM-11                    January 1998


Chapter 1 - Introduction

1.1. X.400

   The standard referred shortly into this document as "X.400" relates
   to the ISO/IEC 10021 - CCITT 1984, 1988 and 1992 X.400 Series
   Recommendations covering the Message Oriented Text Interchange
   Service (MOTIS). This document covers the Inter Personal Messaging
   System (IPMS) only.

1.2. Mail-11

   Mail-11, also known as DECnet mail and often improperly referred as
   VMSmail, is the proprietary protocol implemented by Digital Equipment
   Corporation (DEC) to establish a real-time text messaging system
   among systems implementing the DECnet Phase IV and DECnet/OSI (CLNS)
   networking protocols.

1.3. RFC822 / MIME

   RFC822 was defined as a standard for personal messaging systems
   within the DARPA Internet and is now diffused on top of many
   different message transfer protocols, like SMTP, UUCP, BITNET, JNT
   Grey Book, CSnet. MIME specifications allows transport of non-textual
   information into RFC822 messages. Their mapping with X.400 is fully
   described in MIXER and MIME-MHS. In this document we will consider
   their relations with Mail-11, too.

1.4. The user community

   The community using MIME or X.400 messaging system is currently
   growing in the whole world, but there is still a number of very large
   communities using Mail-11 based messaging systems willing to
   communicate easily with X.400 based Message Handling Systems and with
   MIME based systems. Among these large DECnet based networks we can
   include the High Energy Physics network (HEPnet) and the Space
   Physics Analysis Network (SPAN).

   Many other local communities actively use internally Mail-11 mailing
   protocols. As any other "non standard" mail protocol, using non
   standard mapping techniques between Mail-11 and standard mail systems
   can produce unpredictable results.

   For these reasons a set of rules covering conversion between Mail-11
   and X.400 or MIME is described in this document.






Allocchio                     Experimental                      [Page 2]

RFC 2162                        MaXIM-11                    January 1998


   This document also covers the case of Mail-11 systems implementing
   the "foreign mail protocol" allowing Mail-11 to interface other mail
   systems, including RFC822 based system.

Chapter 2 - Message Elements

2.1. Service Elements

   Mail-11 protocol offers a very restricted set of elements composing a
   Inter Personal Message (IPM), whereas X.400 and RFC822/MIME
   specifications support a complex and large amount of service
   elements.  Considering the case where a message is relayed between
   two X.400 MHS or MIME Message Transport System (MTS) via a Mail-11
   messaging system this could result in a nearly complete loss of
   information.

   To minimise the inconvenience, any of the X.400 or MIME service
   elements which do not map directly into Mail-11 equivalent ones
   accordingly to this specification, will be included into Mail-11 text
   body parts as an additional RFC822-like header; this additional
   header will be inserted between the Mail-11 P2 headers (From:, To:,
   CC:, Subj:) and the other Mail-11 bodyparts. In particular, X.400
   elements will also be at first converted into textual representation
   before insertion.

   An example, where a multimedia message has been encoded into mail-11
   after having crossed also a MIME-MHS (MIXER conformant) gateway:

     From:  smtp%"Admin@SURFnet.nl"  "Erik"  18-OCT-1994 13:55:00.49
     To:    ALLOCCHIO
     CC:    smtp%"netman@MailFLOW.dante.net"
     Subj:  enjoy this nice picture!

     X400-Originator: root@sun3.SURFnet.nl
     X400-Recipients: Allocchio@elettra.ts.it, netman@MailFLOW.dante.net
     Sender: Erik Newmann <root@SURFnet.nl>
     Organisation: SURFnet bv
     Mime-Version: 1.0
     Content-Type: multipart/mixed; boundary="----- =_aaaaaa0"
     Content-ID: <21223.78342785@SURFnet.nl>

     ------- =_aaaaaa0
     Content-Type: text/plain; charset="us-ascii"
     Content-ID: <21223.78342785@SURFnet.nl>

     look... you never saw this one!!
     I just include the picture in the next bodypart
     and I hope you get it fine.



Allocchio                     Experimental                      [Page 3]

RFC 2162                        MaXIM-11                    January 1998


     regards,

     Erik                                         (continues...)

     ------- =_aaaaaa0                            (continued...)
     Content-Type: image/gif
     Content-ID: <21223.78342785@SURFnet.nl>
     Content-Description: a nice snapshot!
     Content-Transfer-Encoding: base64

     RAV8372FAASD83D721NSHDHD3ASDFJKHWEHKJHCBASDFA829CA8SDB29B132RBAKDFA
     9KSJ2KJAA0SDFNAL20DDKFALJ20AJDLFB239B9SC9B29BA9BDFADSDF03998ASDFASD

     ------- =_aaaaaa0

   We need, in fact, to consider also the case when a message originates
   from a network implementing RFC822/MIME protocols and is relayed via
   Mail-11 to an X.400 MHS, or vice versa.

   Whenever any X.400 element not covered in this specification needs to
   be converted into textual representation (to be included into a
   Mail-11 RFC822-like header or text bodypart) we will apply the rules
   specified in MIXER (X.400 to RFC822/MIME sections).

   Vice versa, MIXER specification (RFC822/MIME to X.400 sections) also
   gives the correct rules to convert from textual representations
   contained into Mail-11 RFC822-like header or bodyparts into X.400
   elements.

   On the other hand, RFC822/MIME headers not covered by this
   specification are included 'as they are' into Mail-11 RFC822-like
   header and bodyparts. The way back from Mail-11 to RFC822/MIME
   structure becomes thus straightforward.

   The above methods assures maximum transparency and minimal or null
   loss of information also when Mail-11 is involved.















Allocchio                     Experimental                      [Page 4]

RFC 2162                        MaXIM-11                    January 1998


2.2. Mail-11 service elements to X.400 service elements.

   All envelope (P1) and header (P2) Mail-11 service elements are
   supported in the conversion to X.400. Note that Mail-11 P1 is solely
   composed by P1-11.From and P1-11.To, and any other Mail-11 element
   belongs to Mail-11 P2:

        - P1-11.From
                maps to P1.Originator

        - P1-11.To
                maps to P1.Primary Recipient

        - P2-11.'From:'
                usually maps to P2.Originator (see section 2.6)

        - P2-11.'To:'
                maps to P2.Primary Recipient

        - P2-11.'CC:'
                maps to P2.Copy Recipient

        - P2-11.Date
                maps to P2.Submission Time Stamp

        - P2-11.'Subj:'
                maps to P2.Subject

   Any eventual RFC822-like text header in Mail-11 body part will be
   interpreted as specified into MIXER.

2.3. X.400 service elements to Mail-11 service elements

   The following X.400 service elements are supported directly into
   Mail-11 conversion:

        - P1.Originator
                maps to P1-11.'From:'

        - P1.Primary Recipients
                maps to P1-11.'To:'

        - P2.Originator
                usually maps to P2-11.'From:' (see section 2.6)

        - P2.Primary Recipients
                maps to P2-11.'To:'




Allocchio                     Experimental                      [Page 5]

RFC 2162                        MaXIM-11                    January 1998


        - P2.Copy Recipients
                maps to P2-11.'CC:'

        - P2.Submission Time Stamp
                maps to P2-11.Date

        - P2.Subject
                maps to P2-11.'Subj:'

   The following X.400 service element is partially supported into
   Mail-11 conversion:

        - P2.Blind Copy Recipient
                to ensure the required privacy, when a message contains
                a BCC address, the following actions occurs:
                - a new message is created, containing the body parts;
                - a new envelope is added to the new message, containing
                  the originator and the BCC recipient addresses only;
                - a note is added to the message informing the BCC
                  recipient about the fact that the message was a BCC;
                - the new message is delivered separately;
                - a note is added to the message delivered to TO and CC
                  recipients informing them about the fact that there
                  were some BCC recipients, too.

   Any other X.400 service element support is done accordingly to MIXER
   including the mapped element into the RFC822-like header into Mail-11
   body part.

2.4. Mail-11 service elements to RFC822/MIME service elements.

   All envelope (P1) and header (P2) Mail-11 service elements are
   supported in the conversion to RFC822/MIME:

        - P1-11.From
                maps to 822-MTS.Originator

        - P1-11.To
                maps to 822-MTS.Primary Recipient

        - P2-11.'From:'
                usually maps to 822.'From:' (see section 2.6)

        - P2-11.'To:'
                maps to 822.'To:'

        - P2-11.'CC:'
                maps to 822.'Cc:'



Allocchio                     Experimental                      [Page 6]

RFC 2162                        MaXIM-11                    January 1998


        - P2-11.Date
                maps to 822.'Date:'

        - P2-11.'Subj:'
                maps to 822.'Subject:'

   Any eventual RFC822-like text header in Mail-11 body part will be
   re-inserted into RFC822/MIME message 'as it is'.

2.5. RFC822/MIME service elements to Mail-11 service elements

   The following RFC822 service elements are supported directly into
   Mail-11 conversion:

        - 822-MTS.Originator
                maps to P1-11.From

        - 822-MTS.Primary Recipients
                maps to P1-11.To

        - 822.'From:'
                usually maps to P2-11.'From:' (see section 2.5)

        - 822.'To:'
                maps to P2-11.'To:'

        - 822.'Cc:'
                maps to P2-11.'CC:'

        - 822.'Date:'
                maps to P2-11.Date

        - 822.'Subject:'
                maps to P2-11.'Subj:'

















Allocchio                     Experimental                      [Page 7]

RFC 2162                        MaXIM-11                    January 1998


   The following RFC822 service element is partially supported into
   Mail-11 conversion:

        - 822.'Bcc:'
                to ensure the required privacy, when a message contains
                a BCC address, the following actions occurs:
                - a new message is created, containing the body parts;
                - a new envelope is added to the new message, containing
                  the originator and the BCC recipient addresses only;
                - a note is added to the message informing the BCC
                  recipient about the fact that the message was a BCC;
                - the new message is delivered separately;
                - a note is added to the message delivered to TO and CC
                  recipients informing them about the fact that there
                  were some BCC recipients, too.

   Any other RFC822/MIME service element support is done simply
   including the element 'as it is' into the RFC822-like header and into
   a Mail-11 body part.

2.6. Rules to define the Mail-11 P2-11.'From:' element

   Mail-11 User Agents (usually VMSmail) uses the P2-11.'From:' element
   as destination in case the REPLY command is issued, ignoring any
   other specification like 'Sender:' 'Reply-To:' 'Return-Path:' etc.
   Also a number of automatic responders uses this field only to address
   their messages.

   Is it thus essential to insert into this field the correct
   information, i.e. the correct address where, according to X.400 or
   RFC822 rules the REPLY command or any automatically generated message
   should go.

   The rules specified in RFC822, section 4.4.4 should be used as a
   selection criterion to define the content of this field.

   In particular, in case the P2-11.'From:' element is not generated
   from the P2.Originator (X.400) or from the 822.'From:' (RFC822), it
   is essential to preserve into a 'From:' record of the RFC822-like
   header the original information contained into the P2.Originator or
   822.'From:' fields.










Allocchio                     Experimental                      [Page 8]

RFC 2162                        MaXIM-11                    January 1998


   Vice versa, when converting from Mail-11 into X.400 or RFC822/MIME
   the information contained into the 'From:' field of the RFC822-like
   header (if present) will supersede the one contained into the Mail-11
   P2-11.'From:'. An example:

     From:  smtp%"Admin@SURFnet.nl"  "Erik"  18-OCT-1994 13:55:00.49
     To:    ALLOCCHIO
     CC:    smtp%"netman@MailFLOW.dante.net"
     Subj:  enjoy this nice picture!

     From: Erik Newmann <root@SURFnet.nl>
     Reply-To: Admin@SURFnet.nl
     Organisation: SURFnet bv
     Message-Id: <21235.25442281@SURFnet.nl>

   when converting back into RFC822 the header will be:

     From: Erik Newmann <root@SURFnet.nl>
     Reply-To: Admin@SURFnet.nl
     To: Allocchio@elettra.ts.it
     Cc: netman@MailFLOW.dante.net
     Subject: enjoy this nice picture!
     Organisation: SURFnet bv
     Message-Id: <21235.25442281@SURFnet.nl>

   The described method, although violating canonical conversion
   principles, assures the maximum functionality to the users, and
   provides consistency in case of multiple conversions for a single
   message.

Chapter 3 - Basic Mappings

   The basic mappings indicated in MIXER and its updates should be fully
   used.

   A special consideration must be used for encoding RFC822 addresses
   containing quotes '"' into Mail-11. In fact Mail-11 addresses cannot
   contain that special character, as it is reserved to delimit "quoted
   strings" themselves, as when using the Mail-11 foreign mail protocol.
   An example:

      "John Poe"@Mixergw.local.ca.us    (RFC822)

   cannot be included in a Mail-11 foreign mail protocol address 'as
   is', due to the quotes in the LHS section. Quotes must thus be
   encoded.  MIXER specifies exactly how to encode quotes and other
   characters when translating RFC822 addresses into X.400. Mail-11
   addresses are not limited to printablestring, as for X.400, but a



Allocchio                     Experimental                      [Page 9]

RFC 2162                        MaXIM-11                    January 1998


   subset of the MIXER encoding can be used for the quotes character,
   and, as a direct consequence, for open and closed round brackets '('
   and ')':

      smtp%"(q)John Poe(q)@Mixergw.local.ca.us"

Chapter 4 - Addressing - Mail-11 / X.400

4.1. Mail-11 addressing

   Mail-11 addressing can vary from a very simple case up to complex
   ones, if there are other Mail-11 to "something-else" gateways
   involved. In any case a Mail-11 address is an ASCII string composed
   of different elements.

4.2. X.400 addressing

   On the other hand, An X.400 O/R address is a collection of
   attributes, which can anyway be presented as an IA5 textual
   representation as defined in RFC1685 and CCITT F.401, Annex B.

4.3. Mail-11 address components

   Let us start defining the different parts composing a Mail-11
   address. Mail-11 addresses syntax is slightly different between Phase
   IV and DECnet/OSI cases:

   - Phase IV:  we consider a Mail-11 address as composed by 3 parts:

        [route] [node::] local-part

   where 'route' and 'node' are optional and only 'local-part' is
   compulsory.

   - DECnet/OSI: we consider a Mail-11 address as composed by 3 parts:

        [net:] [node-clns::] local-part

   where 'net and 'node-clns' are optional and only 'local-part' is
   compulsory.

   Here comes a formal definition of these elements

     node = *(ALPHA/DIGIT) / *DIGIT / *DIGIT "." *DIGIT

     route = *(node "::")

     subdomain = *(ALPHA/DIGIT)



Allocchio                     Experimental                     [Page 10]

RFC 2162                        MaXIM-11                    January 1998


     node-clns = *("." subdomain)

     net = *(ALPHA/DIGIT)

     local-part = username / nickname / for-protocol

     username = *(ALPHA/DIGIT)

     nickname = <printablestring - <" " and HTAB>>

     for-protocol = (f-pref f-sep <">f-address<">)

     f-pref = *(ALPHA/DIGIT)

     f-sep = "%" / "::"

     f-address = printablestring / RFC822-address / X400-text-address

     X400-text-address = <textual representation of an X.400 O/R addr>

     Please note that in x400-text-address both the ";" notation and the
     "/" notation are equivalent and allowed (see examples in different
     sect.)

        Some examples (Phase IV):

           route           node    local-part
           -----------------------------------------------------------
                                   USER47
                           MYNODE::BETTY
           BOSTON::CLUS02::GOOFY1::MARY34
                                   IN%"M.P.Tracy@Dicdum.cc.edu"
                   UCLA13::MVAX93::MRGATE::"MBOX1::MBX34::MYC3::BOB"
                           MIAMI2::George.Rosenthal
                   CCUBVX::VS3100::Jnet%"IAB3425@IBAX23L"
                                   MRGATE::"C=xx::A=bbb::P=ppp::S=Joe"
                           MAINVX::IN%"path1!path2!user%dom"
                           GWX400::gw%"C=xx;ADMD=aaa;PRMD=ppp;S=Lee;"
                           GX409A::x400%"/C=xx/A=aaa/P=ppp/S=Lee"
                                   smtp%"postmast@nodeb.bitnet"
                   MICKEY::PRFGAT::profs%"NANCY@IBMB"
                                   edu%"HU427BD%CSUNIB@abc.acme.edu"









Allocchio                     Experimental                     [Page 11]

RFC 2162                        MaXIM-11                    January 1998


   Some examples (DECnet/OSI):

      net  node              local-part
      -----------------------------------------------------------
                              USER47
           .IT.MYDOM1.MYNODE::BETTY
      OMNI:.US.GOV.LB.GOOFY1::MARY34
                              IN%"M.P.Tracy@Dicdum.cc.edu"
      NET1:.SALES.ADM.MVAX93::MRGATE::"MBOX1::MBX34::MYC3::BOB"
             .FR.LYON.MIAMI2::George.Rosenthal
           .AU.ABXY2W.VS3100::Jnet%"IAB3425@IBAX23L"
                              MRGATE::"C=xx::A=bbb::P=ppp::S=Joe"
       INT:.GB.3LABV56.MAINV::IN%"path1!path2!user%dom"
                      GWX400::gw%"C=xx;ADMD=aaa;PRMD=ppp;S=Lee;"
                              smtp%"postmast@nodeb.bitnet"
      OMNI:.DE.TEST.V1.GWY32::GX409A::x400%"/C=xx/A=aaa/P=ppp/S=Lee"

   Note that also in DECnet/OSI there can be Phase IV like node names,
   the so called "Phase IV compatibility node names", but no 'route'
   term is allowed in front of them. In case the address consists of a
   DECnet/OSI 'net' and/or 'node' specification, plus an old Phase IV
   node address (like the last one in above examples) we consider the
   old Phese IV node name (GX409A) as 'local-part'.

Chapter 5 - Mapping - Mail-11 / X.400

5.1. Mapping scheme

   DECnet phase IV address field is somehow a 'flat land' with some
   obliged routes to reach some hidden areas. Thus a truly hierarchical
   mapping scheme using mapping rules as suitable for RFC822 is not the
   appropriate solution. A fixed set of encoding rules using DDAs
   support is defined in order to define the mapping.

   DECnet/OSI address field is, on the other hand, hyerarchical,
   implementing a real domain style organization, resembling very
   closely the RFC822 domain addresses. However also in DECnet/OSI
   networks the old Phase IV flat addresing schema remains valid,
   expecially for the so called 'Phase IV short aliases'. For this
   reason, and to keep mapping as simple as possible, the same set of
   fixed rules usind DDAs encoding will be used both for Phase IV and
   DECnet/OSI addresses.









Allocchio                     Experimental                     [Page 12]

RFC 2162                        MaXIM-11                    January 1998


   Another important aspect of the problem is the coexistence in DECnet
   phase IV of many disjoint networks, using the same DECnet address
   space, i.e., common X.400 and/or RFC822 mailing system acting as glue
   to connect different isolated Mail-11 islands. In DECnet/OSI this
   aspect is more canonically approached, introducing the concept of
   'net', a unique name identifying the single internally fully
   interconnected DECnet network sharing the same DECnet/OSI name space.

   To identify uniquely each DECnet Phase IV network we will thus extend
   the concept of DECnet/OSI 'net' also to this case. We define as 'net'
   in Phase IV a unique ASCII string identifying the DECnet network we
   are connected to. If the Phase IV network is already migrating and
   thus interconnected to DECnet/OSI areas, the 'net' identifier already
   used in the DECnet/OSI areas is automatically extended to the whole
   DECnet community.

   If the network still uses Phase IV protocols only, a 'net' identifier
   must be chosen. In this case the 'net' element will identify the
   DECnet community being served, but it could also differ from the
   actual official network name. It is reccommended that the same 'net'
   identifier will be adopted unmodified when the eventual migration to
   DECnet/OSI will take place within that DECnet community.

   Aliases are allowed for the 'net' identifier. Some well known
   identifiers and aliases:

       net = 'OMNI'         the High Energy Physics & Space Physics
                            DECnet network;

   aliases:

       net = 'HEPnet'       alias for 'OMNI'
       net = 'SPAN'         alias for 'OMNI'

   The need of labelling each DECnet network with its name comes also
   from the requirement to implement the 'intelligent' gateway, i.e.,
   the gateway which is able to understand its ability to connect
   directly to the specified DECnet network, even if the O/R address
   specify a path to a different gateway. A more detailed discussion of
   the problem is in 5.3 and 5.5.











Allocchio                     Experimental                     [Page 13]

RFC 2162                        MaXIM-11                    January 1998


   A registry of 'net' attributes to insure uniqueness of names must be
   established: this registry is the same one created for migration to
   DECnet/OSI. A simple table coupling 'net' and the gateway address is
   also used, in a syntax similar to the 'gate1' and 'gate2' tables used
   in MIXER. An example:

        OMNI#OU$Cosine-gw.O$@.PRMD$infn.ADMD$garr.C$IT#
        OMNI#O$ESRIN1.PRMD$esa.ADMD$Master400.C$it#
        HEPnet#OU$Cosine-gw.O$@.PRMD$infn.ADMD$garr.C$IT#
        HEPnet#O$ESRIN1.PRMD$esa.ADMD$Master400.C$it#
        SPAN#OU$Cosine-gw.O$@.PRMD$infn.ADMD$garr.C$IT#
        SPAN#O$ESRIN1.PRMD$esa.ADMD$Master400.C$it#

   Ambiguous left entries are allowed. Gateway implementations could
   simply choose among one of the specified gateways, or try them all in
   cyclic order to obtain better performances.

   Note that aliases are established using this gate table, too: simply
   add equivalent entries into the table, like the 'HEPnet' and 'SPAN'
   entries. Aliases, however, must be used only to enable users to use
   commonly used names, but any  gateway implementing this specification
   must generate addresses with official 'net' names, only ('OMNI' for
   the above table).

   The Mail-11 gateways table, however, just constitutes the list of the
   the appropriate MIXER address translation) RFC822 world. Any other
   gateway implementing this specification (and the related ones) should
   use its local name as first choice for the Mail-11 'net' it can
   reach, and use the official Mail-11 gateway table to reach only the
   non connected ones. This list of Mail-11 gateway entries is supposed
   to contain the list of 'net' tags and their aliases; as this list is
   usually small, currently we do not take into account distribution
   mechanisms for this information different from a static table.

   In order to keep the mapping rules very simple, avoiding the need to
   analyse Mail-11 addresses to distinguish the 'route', 'node', and
   Attributes (DDAs) needed to cover the mapping problem.

5.2. Mail-11 --> X.400

   We define the following Domain Defined Attributes to map a Mail-11
   address:

        DD.Dnet
        DD.Mail-11






Allocchio                     Experimental                     [Page 14]

RFC 2162                        MaXIM-11                    January 1998


   We thus define the Mail-11 Phase IV mapping rule:

        route::node::localpart

      maps into

        C=xx; ADMD=yyy; PRMD=zzz; O=ooo; OU=uuu; DD.Dnet=net;
        DD.Mail-11=route::node::localpart;

   Meanwhile we define the mapping rule for Mail-11 DECnet/OSI:

        net:node-clns::localpart

      maps into

        C=xx; ADMD=yyy; PRMD=zzz; O=ooo; OU=uuu; DD.Dnet=net;
        DD.Mail-11=node-clns::localpart;

   with:

        xx  = country code of the gateway performing the conversion
        yyy = Admd of the gateway performing the conversion
        zzz = Prmd of the gateway performing the conversion
        ooo = Organisation of the gateway performing the conversion
        uuu = Org. Unit(s) of the gateway performing the conversion
        net = name of the DECnet network (e.g., OMNI, HEPnet, SPAN,...)

   ('zzz','ooo','uuu' being used or dropped appropriately in order to
   identify uniquely within the X.400 MHS the gateway performing the
   conversion).

   The following defaults also apply:

   if 'node' (or 'node-clns') is missing and we are mapping the Mail-11
   originator (From) then 'node' (or 'node-clns') defaults to the DECnet
   node name of the gateway (gwnode);

   if 'node' (or 'node-clns') is missing and we are mapping the Mail-11
   recipient (To, Cc) then 'node' (or 'node-clns') defaults to the
   DECnet node name of the 'From' address.

   if 'net' is missing, then it defaults to a value defined locally by
   the gateway: if the gateway is connected to one DECnet network only,
   then 'net' will be the name of this unique network; if the gateway is
   connected to more than one DECnet network, then the gateway will
   establish a 'first choice' DECnet network, and 'net' will default to
   this value.




Allocchio                     Experimental                     [Page 15]

RFC 2162                        MaXIM-11                    January 1998


   The 'node' syntax (DECnet/OSI or Phase IV) depends on the DECnet
   protocol implemented and on the value of a system parameter (usually
   the MAIL$SYSTEM_FLAGS one) on the gateway host.

   In case 'local-part' contains 'x400-text-address' see also section
   6.4.3;

   In case 'local-part' contains 'RFC822-address' see also section
   6.4.4.

5.2.1. Examples

   Let us suppose that:

     - the DECnet network name (net) is 'OMNI';
     - the DECnet node name of the gateway (gwnode) is '.IT.DM.X4TDEC'
       alias 'X4TDEC' in Phase IV;
     - the Country Code of the gateway is 'IT' and its ADMD is 'garr'
       (and these two fields are enough to identify uniquely the gateway
       within the X.400 MHS).

    USER47
     C=it; ADMD=garr; DD.Dnet=OMNI; DD.Mail-11=.IT.DM.X4TDEC::USER47;

    MYNODE::BETTY
     C=it; ADMD=garr; DD.Dnet=OMNI; DD.Mail-11=MYNODE::BETTY;

    BOSTON::GOOFY1::MARY34
     C=it; ADMD=garr; DD.Dnet=OMNI; DD.Mail-11=BOSTON::GOOFY1::MARY34;

    .DE.UNI-BN.PHYS.NODE18::MARY34
     C=it; ADMD=garr; DD.Dnet=OMNI;
     DD.Mail-11=.DE.UNI-BN.PHYS.NODE18::MARY34;

    UCLA13::MVAX93::MRGATE::"MBOX1::MBX34:MYC3::BOB"
     C=it; ADMD=garr; DD.Dnet=OMNI;
     DD.Mail-11=UCLA13::MVAX93::MRGATE::(q)MBOX1::MBX34::MYC3::BOB(q)

    ENET:.US.CENTRAL.MIAMI2::George.Rosenthal
     C=it; ADMD=garr; DD.Dnet=ENET;
     DD.Mail-11=.US.CENTRAL.MIAMI2::George.Rosenthal;

    MRGATE::"C=xx::A=bbb::P=ppp::S=Joe"
     C=it; ADMD=garr; DD.Dnet=OMNI;
     DD.Mail-11=X4TDEC::MRGATE::(q)C=xx::A=bbb::P=ppp::S=Joe(q)






Allocchio                     Experimental                     [Page 16]

RFC 2162                        MaXIM-11                    January 1998


    MAINVX::In%"path1!path2!user%dom"
     C=it; ADMD=garr; DD.Dnet=OMNI;
     DD.Mail-11=MAINVX::In(p)(q)path1(b)path2(b)user(p)dom(q)

5.3. X.400 encoding of Mail-11 --> Mail-11

   In order to assure path reversibility in case of multiple Mail-
   11/X.400 gateway crossing we must distinguish two cases:

   - DD.Dnet=net is known to the gateway as one of the DECnet networks
     it is connected to. In this case the mapping is trivial:

        C=xx; ADMD=yyy; PRMD=zzz; O=ooo; OU=uuu; DD.Dnet=net;
        DD.Mail-11=route::node::localpart;

   (see sect. 5.2 for explication of 'xx','yyy','zzz','ooo','uuu','net')

   maps into

        route::node::localpart

   and for DECnet/OSI addresses

        C=xx; ADMD=yyy; PRMD=zzz; O=ooo; OU=uuu; DD.Dnet=net;
        DD.Mail-11=node-clns::localpart;

   maps into

        net:node-clns::localpart

   - DD.Dnet=net is NOT known to the gateway as one of the DECnet
     networks it is connected to. In this case the mapping rule
     described into section 5.4 apply:

        C=xx; ADMD=yyy; PRMD=www; DD.Dnet=net;
        DD.Mail-11=route::node::localpart;

   maps into

        gwnode::gw%"C=xx;ADMD=yyy;PRMD=www;DD.Dnet=net;
        DD.Mail-11=route::node::localpart;"










Allocchio                     Experimental                     [Page 17]

RFC 2162                        MaXIM-11                    January 1998


   Again for DECnet/OSI addresses:

        C=xx; ADMD=yyy; PRMD=www; DD.Dnet=net;
        DD.Mail-11=node-clns::localpart;

   maps into

        gwnode::gw%"C=xx;ADMD=yyy;PRMD=www;DD.Dnet=net;
        DD.Mail-11=node-clns::localpart;"


5.3.1. Examples

   Let us suppose that:

     - the DECnet network name (net) is 'OMNI';
     - the DECnet node name of the gateway (gwnode) is '.IT.DM.X4TDEC';
       alias 'X4TDEC' in Phase IV;
     - the Country Code of the gateway is 'IT' and its ADMD is 'garr';

     (and these two fields are enough to identify uniquely the gateway
     within the X.400 MHS).

     C=it; ADMD=garr; DD.Dnet=OMNI;
     DD.Mail-11=X4TDEC::MRGATE::(q)C=ab::A=dsa::P=qwty::OU=mie::S=Cly(q)
       MRGATE::"C=ab::A=dsa::P=qwty::OU=mie::S=Cly"

     C=it; ADMD=garr; DD.Dnet=EASYNET; DD.Mail-11=ROM01::CARLO;
       X4TDEC::gw%"C=it;ADMD=garr;DD.Dnet=EASYNET;
       DD.Mail-11=ROM01::CARLO;"

   (in the above example 'EASYNET' is supposed to be not connected to
   our gateway located on .IT.DM.X4TDEC DECnet node).

5.4. X.400 --> Mail-11

   The mapping of an X.400 O/R address into Mail-11 is done encoding the
   various attributes into the X400-text-address as defined in chapter 4
   of MIXER, and including this as 'f-address'. A 'f-pref' and a the
   DECnet node name of the gateway.











Allocchio                     Experimental                     [Page 18]

RFC 2162                        MaXIM-11                    January 1998


   Thus

      x400-text-address

   will be encoded like

      gwnode::gw%"x400-text-address"

   having spaces dividing attributes as optional.

5.4.1. Example

   Let us suppose that:

     - the DECnet node name of the gateway (gwnode) is '.IT.DM.X4TDEC'
       alias 'X4TDEC' in Phase IV, and 'net' is 'OMNI'

   Thus

      C=gb; ADMD=G400; PRMD=AC.UK; O=ucl; S=Clay;

   will be encoded like

    X4TDEC::gw%"/C=gb/A=G400/P=AC.UK/O=ucl/S=Clay"

   or its equivalent with the ";" notation and DECnet/OSI 'node'

    OMNI:.IT.DM.X4TDEC::gw%"C=gb;ADMD=G400;PRMD=AC.UK;O=ucl;S=Clay;"

5.5. Mail-11 encoding of X.400 --> X.400

   It can happen that Mail-11 is used to relay messages between X.400
   systems; this will mean multiple X.400/Mail-11 gateway crossing and
   we will encounter Mail-11 addresses containing embedded X.400
   informations. In order to assure path reversibility we must then
   distinguish two cases:















Allocchio                     Experimental                     [Page 19]

RFC 2162                        MaXIM-11                    January 1998


   - the embedded X.400 address belongs to a domain whose naming and
     routing rules are known to the global X.400 MHS.  In this case the
     mapping is trivial:

       route::gwnode::gw%"x400-text-address"

     or (for DECnet/OSI)

       net:gwnode::gw%"x400-text-address"

   maps into

       x400-text-address

      'route' and 'gwnode' are mapped into X.400 Trace service elements.

   - the encoded X.400 domain does not belong to the global X.400 name
     space. In this case the mapping rule described into section 5.2
     apply:

       route::gwnode::gw%"x400-text-address"

   maps into

       C=xx; ADMD=yyy; DD.Dnet=net;
       DD.Mail-11=route::gwnode::gw(p)(q)x400-text-address(q);

   and (for DECnet/OSI)

       net:gwnode::gw%"x400-text-address"

   maps into

       C=xx; ADMD=yyy; DD.Dnet=net;
       DD.Mail-11=gwnode::gw(p)(q)x400-text-address(q);

   The latter case is deprecated and must be regarded as a possible
   temporary solution only, while waiting to include into the global
   X.400 MHS also this domain.












Allocchio                     Experimental                     [Page 20]

RFC 2162                        MaXIM-11                    January 1998


5.5.1. Examples

   Let us suppose that:

     - the DECnet network name (net) is 'OMNI';
     - the DECnet node name of the gateway (gwnode) is '.IT.DM.X4TDEC'
       alias 'X4TDEC' in Phase IV;
     - the Country Code of the gateway is 'IT' and its ADMD is 'garr';
       (and these two fields are enough to identify uniquely the
       gateway within the X.400 MHS).

     X4TDEC::gw%"C=fr;ADMD=atlas;PRMD=ifip;O=poly;S=Moreau;"
       C=fr; ADMD=atlas; PRMD=ifip; O=poly; S=Moreau;

     X4TDEC::gw%"C=zz;ADMD= ;PRMD=Botwa;O=Miner;S=Chiuaw;"
       C=it; ADMD=garr; DD.Dnet=OMNI;
       DD.Mail-11=X4TDEC::gw(p)(q)C=zz;ADMD= ;
       PRMD=Botwa;O=Miner;S=Chiuaw;(q)

   (in the above example  C=zz is unknown to the global X.400 MHS)

Chapter 6 - Mapping - Mail-11 / RFC822

6.1 Introduction

   The implementation of a Mail-11 - RFC822 gateway was faced by many
   software developers independently, and was included in many mail
   products which were running on both VMS and UNIX systems. As there
   was not a unique standard mapping way, the implementations resulted
   into a number of possible variant methods to map a Mail-11 address
   into an RFC822 one. Some of these products became then largely
   widespread, starting to create a number of de facto mapping methods.

   In this chapter some sort of standardisation of the mapping problem
   is considered, trying to be compatible with the existing installed
   software. We must also remind that, in some cases, only simple Mail-
   11 addresses could be mapped into RFC822, having complex ones
   producing all sort of quite strange results. In case DECnet/OSI
   Mail-11 addresses are involved we must also notice that only one
   mapping method can be used from/to RFC822 addresses.











Allocchio                     Experimental                     [Page 21]

RFC 2162                        MaXIM-11                    January 1998


   On the other hand, the mapping of an RFC822 address in Mail-11 was
   quite straightforward, resulting in a common definition which uses
   "Mail-11 foreign mail protocol" to design an RFC822 address:

      [[node::][node::]...]prot%"rfc-822-address"

   or

      [node::][node::]...]prot::"rfc-822-address"

   or again for DECnet/OSI addresses

      [net:][node-clns::]prot%"rfc-822-address"

   or

      [net:][node-clns::]prot::"rfc-822-addres"

6.2 De facto implementations

   A considerable number of de-facto implementations of Mail-11/RFC822
   gateways is existing. As said in the introduction, the mapping of
   RFC822 addresses in Mail-11 is accomplished using the foreign mail
   protocol syntax and is thus unique.

   On the other hand, Mail-11 addresses are encoded in RFC822 syntax in
   various ways. Here are the most common ones:

        a) "node::user"@gateway-address
        b) user%node@gateway-address
        c) user@node.decnet.domains
        d) user%node.dnet@gateway-address

Let's have a quick look to these different choices.

   a - This form simply encloses as quoted Left Hand Side string the
       original Mail-11 address into the RFC822 address of the
       Mail-11/RFC822 gateway. This method is fully conformant with
       RFC822 syntax, and the Mail-11 address is left untouched; thus
       no encoding rules need to applied to it. This method applies also
       easily to DECnet/OSI Mail-11 addresses.

   b - As one will immediately notice, this form has nothing in it
       indicating the address is a Mail-11 one; this makes the encoding
       indistinguishable from a similar encoding of RSCS (BITnet)
       addresses used by some IBM VM Mailer systems. It should thus be
       deprecated.




Allocchio                     Experimental                     [Page 22]

RFC 2162                        MaXIM-11                    January 1998


   c - In this case a sort of 'reserved word' (DECnet)  embedded into
       the address itself identifies the presence of a Mail-11 original
       address preceding it. The decoding is possible, dropping
       'domains' and extracting 'user' and 'node' parts. However complex
       Mail-11 addresses cannot be mapped properly in this syntax, and
       there is no specific rule for adding the 'domains' part of the
       address.

   d - In this case again there is a 'reserved word' (dnet)  which make
       possible the identification of the original Mail-11 address;
       'gateway-address' points to the Mail-11/RFC822 gateway and 'node'
       and 'user' information can be easily drawn from the address.
       However complex Mail-11 addresses cannot be embedded easily into
       this syntax.

   Note the only methods a) can be successfully used for DECnet/OSI
   Mail-11 addresses, while the other cases are already too complex to
   encode in a unique way such addresses in RFC822.

6.3 Recommended mappings

   From the examples seen in the previous paragraphs we can derive a
   canonical form for representing the mapping between Mail-11 and
   RFC822.

6.3.1 RFC822 mapped in Mail-11

   The mapping of an RFC822 address in Mail-11 is straightforward, using
   the "Mail-11 foreign mail protocol" syntax. The two possible variants
   for Phase IV are:

      [[node::][node::]...]prot%"rfc-822-address"

   or

      [node::][node::]...]prot::"rfc-822-address"

   The equivalent two possible variants for DECnet/OSI are:

      [net:][node-clns::]prot%"rfc-822-address"

   or

      [net:][node-clns::]prot::"rfc-822-address"







Allocchio                     Experimental                     [Page 23]

RFC 2162                        MaXIM-11                    January 1998


6.3.2 Mail-11 mapped in RFC822

   RFC822 foresee a canonical form for representing non-RFC822
   addresses: put the foreign address in local part (Left Hand Side,
   LHS) is a form as similar as possible to its original syntax. Thus
   the suggested mapping both for Phase IV and DECnet/OSI is:

      "Mail-11-address"@gateway-address

   This format assures also the return path via the appropriate gateway.

6.3.3 Mail-11 (foreign mail protocol) mapped in RFC822

   A Mail-11 address containing a foreign mail protocol syntax can also
   contain the percent '%' character as a separator between the foreign
   protocol name and the actual address itself. In some cases the
   address part can also be an unquoted string. Some examples:

      deliver%swan
      myprot%root.owner
      listserv%my-private.list.A1

   If these addresses are encoded into an RFC822 address using the
   "natural" method described in 6.3.2, they will result in something
   which can be easily mismatched with an address using the percent hack
   in LHS for source routing.

      "myprot%root.owner"@lohost.mydom.edu    (Mail-11 address)

      "LISTSERV%IBMB.BITnet"@bitgate.anu.edu  (% routing address)

   The percent hack is strongly deprecated, and thus should be avoided;
   the second address above shoud be expressed as:

      @bitgate.anu.edu:"LISTSERV@IBMB.BITnet"

   However, in order to assure maximum functionality and avoid problems,
   it is recommended to encode Mail-11 addresses containing the foreign
   protocol specification in RFC822 syntax using the DD.Mail-11 and
   DD.dnet qualifiers, i.e.

      "/DD.Mail-11=myprot%root.owner/DD.dnet=OMNI"@lohost.mydom.edu

   The DD.dnet defaults as indicated in the similar cases for the Mail-
   11 / X.400 mappings. This encoding method can, of course, also be
   used to map any other Mail-11 address in RFC822, and is the only one
   which enable to specify the network name ('OMNI' in the above
   example) for DECnet Phase IV Mail-11 addresse. The method is fully



Allocchio                     Experimental                     [Page 24]

RFC 2162                        MaXIM-11                    January 1998


   compatible with the results also produced by gateways following the
   MIXER specification for Mail-11 addresses encoded in X.400 and then
   translated into RFC822.

Chapter 7 - Complex mapping - X.400 / Mail-11 / RFC822

7.1. The protocol triangle

   The bilateral mappings described in chapters 5 and 6 must be extended
   in order to cover also the case in which also RFC822 addressing is
   involved, and the following triangular situation occurs:


                                   X.400
                                   /  \
                                  /    \
                                 /      \
                             Mail-11----RFC822

   The X.400 - RFC822 side is fully covered by MIXER, and the previous
   chapters in this document cover the Mail-11 - X.400 side and the
   Mail-11 - RFC822 one.

7.2. RFC822 mapped in Mail-11

   The 'RFC822-address' is usually included in 'local-part' as

         route::gwnode::gw%"rfc822-address"

   or the equivalent in DECnet/OSI:

         net:gwnode::gw%"rfc822-address"

   An example in Phase IV

         NVXA23::SMTPGW::in%"M.T.Rose@CS.UCLA.edu"

   and another one in DECnet/OSI

         OMNI:.FR.INET.LABOL.SMTPGW::in%"M.T.Rose@CS.UCLA.edu"

7.3. Mail-11 mapped in RFC822

   There are different styles in mapping a Mail-11 address in RFC822;
   let's have a short summary of what was traditionally done in some
   implementations.





Allocchio                     Experimental                     [Page 25]

RFC 2162                        MaXIM-11                    January 1998


7.3.1 Mail-11 address encoded in "Left Hand Side" (LHS) of RFC822
      address, using "%" syntax or "::" syntax

        route::node::localpart      (Phase IV)

   maps to

        localpart%node%route@gw-domains

   or

         "route::node::localpart"@gw-domains

   Again, let's consider the DECnet/OSI case:

      net:node-clns::localpart      (DECnet/OSI)

   maps to

        "net:node-clns::localpart"@gw-domains

   (note that "%" encoding does not exist for this case)

   where 'gw-domains' identify uniquely the Mail-11 / RFC822 gateway.

7.3.2 Mail-11 address maps partly to LHS and partly to 'domain' part of
      RFC822 address

        node::localpart

   maps to

        localpart@node.gw-domains

   note that this kind of mapping does not exists with DECnet/OSI Mail-
   11 addresses.

7.3.3 Mail-11 address is completely hidden by a mapping table

   In this case the resultant RFC822 address contains no trace at all of
   the original Mail-11 address.










Allocchio                     Experimental                     [Page 26]

RFC 2162                        MaXIM-11                    January 1998


7.4. Multiple conversions

   Let us now examine briefly the possible situations which involve
   multiple conversions, having one protocol as a relay between the
   other two. This summary suggest some possible enhanced solutions to
   avoid heavy and unduly mappings, but the 'step by step' approach,
   considering blindly one conversion as disjointed to the other, as
   described in the previous sections, can always be used.

7.4.1. X.400 --> RFC822 --> Mail-11

   We apply the MIXER rules to the first step, obtaining an RFC822
   address which can be mapped in Mail-11 using the 'f-address' field,
   as described in section 7.2.

   an example:

      C=gb; ADMD=Gold 400; PRMD=AC.UK; O=UCL; OU=cs; G=Jim; S=Clay;

   maps accordingly to MIXER to

      Jim.Clay@cs.UCL.AC.UK

   and finally becomes

      SMTPGW::In%"Jim.Clay@cs.UCL.AC.UK"

   and finally becomes

      SMTPGW::In%"Jim.Clay@cs.UCL.AC.UK"

   where 'SMTPGW' is the DECnet Phase IV node name of the machine
   running the RFC822 to Mail-11 gateway. Again, in case the machine
   running the RFC822 to Mail-11 gateway is a DECnet/OSI one (like
   OMNI:.US.VA.CENTRL) we would get

      OMNI:.US.VA.CENTRL::In%"Jim.Clay@cs.UCL.AC.UK"

7.4.2. Mail-11 --> RFC822 --> X.400

   Some of the possible mapping described in section 7.3 for Phase IV
   apply to the Mail-11 address, hiding completely its origin. The MIXER
   apply on the last step.








Allocchio                     Experimental                     [Page 27]

RFC 2162                        MaXIM-11                    January 1998


   an example:

      RELAY::MYNODE::BETTY

   could map into RFC822 as

      BETTY%MYNODE@RELAY.dnet.gw1.it

   and accordingly to MIXER

      C=it; A=garr; P=dom1; O=gw1; OU=RELAY; S=BETTY(p)MYNODE;

   where 'dnet.gw1.it' is the domain of the machine running the Mail-11
   to RFC822 gateway.

7.4.3. X.400 --> Mail-11 --> RFC822

   The X.400 address is stored into Mail-11 'f-address' element as
   described in sections 5.3 and 5.4; then if the Mail-11 to RFC822
   gateway is able to understand the presence of a 'x400-text-address'
   nto the Mail-11 address, then it applies MIXER to it, and encodes
   header. Otherwise it applies the rules described in 7.3.

   an example:

     C=gb; ADMD=Gold 400; PRMD=AC.UK; O=UCL; OU=cs; G=Jim; S=Clay;

   will be encoded like

     X4TDEC::gw%"/C=gb/A=Gold 400/P=AC.UK/O=UCL/OU=cs/G=Jim/S=Clay"

   If the Mail-11 to RFC822 gateway recognise the x400-text-address,
   then the address becomes, accordingly to MIXER

     Jim.Clay@cs.UCL.AC.UK

   and the following RFC822 header line is added

     Received: from X4TDEC with DECnet (Mail-11) on xx-xxx-xxxx.

   Otherwise one of the dumb rules could produce

    gw%"/C=gb/A=Gold 400/P=AC.UK/O=UCL/OU=cs/G=Jim/S=Clay"@X4TDEC.doms

   The case with DECnet/OSI Mail-11 is conceptually identical.






Allocchio                     Experimental                     [Page 28]

RFC 2162                        MaXIM-11                    January 1998


7.4.4. RFC822 --> Mail-11 --> X.400

   The RFC822 address is encoded in Mail-11 f-address element as
   described in sect. 7.2; then if the Mail-11 to X.400 gateway is able
   to understand the presence of an 'RFC822-address' into the Mail-11
   address, then it applies MIXER to it, and encodes 'route' and applies
   the rules described in 5.2 and 5.5.

   an example:

      Jim.Clay@cs.UCL.AC.UK

   will be encoded like

      SMTPGW::In%"Jim.Clay@cs.UCL.AC.UK"

   If the Mail-11 to X.400 gateway recognise the RFC822-address, then
   the address becomes, accordingly to MIXER

      C=gb; ADMD=Gold 400; PRMD=AC.UK; O=UCL; OU=cs; G=Jim; S=Clay;

   and a 'trace' record is added into the X.400 P1 data, stating that a
   node named SMTPGW was crossed.

   Otherwise dumb rule produces

      C=it; ADMD=garr; DD.Dnet=HEP;
      DD.Mail-11=SMTPGW::In(p)(q)Jim.Clay(a)cs.UCL.AC.UK(q)

   Again, the case for DECnet/OSI Mail-11 addresses, is conceptually
   identical.

7.4.5. RFC822 --> X.400 --> Mail-11

   We apply MIXER to the first conversion, obtaining an X.400 address.
   Then the rules described in sections 5.3 and 5.4 are used to store
   the X.400 address as 'x400-text-address' into the Mail-11.














Allocchio                     Experimental                     [Page 29]

RFC 2162                        MaXIM-11                    January 1998


   an example:

      Jim.Clay@cs.UCL.AC.UK

   maps accordingly to MIXER to

      C=gb; ADMD=Gold 400; PRMD=AC.UK; O=UCL; OU=cs; G=Jim; S=Clay;

   and finally becomes

      SMTPGW::gw%"/C=gb/A=Gold 400/P=AC.UK/O=UCL/OU=cs/G=Jim/S=Clay"

   where 'SMTPGW' is the DECnet Phase IV node name of the machine
   running the X.400 to Mail-11 gateway. No differences also for
   DECnet/OSI Mail-11 addresses.

7.4.6. Mail-11 --> X.400 --> RFC822

   The Mail-11 address is encoded as specified in sections 5.2 and 5.5;
   then MIXER is used to convert the address in RFC822.

   an example:

      RELAY::MYNODE::BETTY

   maps into X.400 as

      C=it; ADMD=garr; DD.Dnet=OMNI; DD.Mail-11=RELAY::MYNODE::BETTY;

   and accordingly to MIXER

      "/C=it/A=garr/DD.Dnet=OMNI/DD.Mail-11=RELAY::MYNODE::BETTY"@gw2.it

   where 'gw2.it' is the domain of the machine running the MIXER
   gateway.

7.4. Conclusions

   A standard way of mapping Mail-11 addresses into RFC822 and vice
   versa is feasible. A suggestion is thus made to unify all existing
   and future implementations. It should be noted, however, that it
   could be impossible (in case of DECnet Phase IV) to specify in these
   mappings the name of the decnet community owning the encoded address,
   as it can be always done for X.400; thus the implementation of the
   'intelligent' gateway in this case could result impossible.






Allocchio                     Experimental                     [Page 30]

RFC 2162                        MaXIM-11                    January 1998


Chapter 8 - Notifications and Probes

8.1. Overview

   Mail-11 is a real time protocol, i.e. connection is established
   directly to the destination node. This makes possible some level of
   services like verification of an address, and delivery confirmation.

   However, Mail-11 User Agents ususally do not support notification or
   probe services, whereas it is possible to deliver the result of a
   notification or a probe to Mail-11. In this section we will briefly
   describe the level of service which can be obtained on these services
   when Mail-11 is involved.

8.2. Delivery of Notifications via Mail-11

   As described in the previous chapters, it is possible to transport
   also in Mail-11 with minimal loss of information complex information.
   This also includes Notifications. In fact Notifications in
   RFC822/MIME are encoded as MIME multipart messages: there are thus no
   problems in transporting these messages in Mail-11 as any other MIME
   message. Also X.400 Notifications can be transported and delivered
   via Mail-11: MIXER describes in fact how to convert them into MIME
   multipart messages, taking the problem back to the previous
   situation.

   Even when Mail-11 is just an intermediate step for a Notification
   message, this consideration just enable support for the service.

8.3. Generation of Notifications and Probes from Mail-11

   Although Mail-11 does not support Notification or Probe, the service
   could also be supported at gateway level. In fact, due to real time
   nature of Mail-11 protocol, the gateway could be reasonably sure that
   delivery until the other end of the Mail-11 path was successful or
   unsuccessful (and try to verify the feasibility of a delivery in case
   a Probe as requested). However, Mail-11 could just be an intermediate
   relay service, vanishing the value of the information.

   Implementation of this kind of service at gateway level is thus
   questionable, and if done, should clearly state the situation where
   it was generated, and the "confidence level" it conveys.

Security Considerations

   Security issues are not discussed in this memo.





Allocchio                     Experimental                     [Page 31]

RFC 2162                        MaXIM-11                    January 1998


Acknowledgements

   I wish to thank all those people who read the first draft and
   contributed a lot with their useful suggestions to the revision of
   this document, in particular RARE WG1 and IETF X.400 ops group
   members and S. E. Kille.

   Thanks also to a number of implementors (among which Ned Freed,
   Julian Onions, The Hebrew University of Tel Aviv - Pine VMS support
   team), to the HEPnet Mail Technical Committee and to all my Mail-11
   "end users", in particular Enzo Valente, for their suggestions and
   wishes which helped me really a lot to prepare this revision of
   former RFC1405.

References

   [1]  CCITT, "CCITT Recommendations X.400-X.430", Message Handling
        Systems: Red Book, October 1984.

   [2]  CCITT, "CCITT Recommendations X.400-X.420", Message Handling
        Systems: Blue Book, November 1988.

   [3]  CCITT/ISO, "CCITT Recommendations X.400/ ISO IS 10021-1,"
        Message Handling: System and Service Overview , December 1992.

   [4]  Crocker D., "Standard of the Format of ARPA Internet Text
        Messages", STD 11, RFC 822, UDel, August 1982.

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

   [6]  Alvestrand H., Kille S., Miles R., Rose M., and Thompson S.,
        (MIME-MHS) "Mapping between X.400 and RFC-822 Message Bodies,"
        RFC 1495, Aug 1993.

   [7]  Digital Equipment Corp., "VMS Mail Utility".

   [8]  Joiner Associates Inc., "Jnet User's Manual".

   [9]  PMDF User's Guide.

   [10] Alvestrand, H. "Writing X.400 O/R Names", UNINETT / RFC1685,
        August 1994.

   [11] CCITT, "F.401 CCITT Message Handling Services - Operations and
        Definitions of Service - Naming and Addressing for Public
        Message Handling Services, Annex B (08/92)", August 1992.



Allocchio                     Experimental                     [Page 32]

RFC 2162                        MaXIM-11                    January 1998


Author's Address

   Claudio Allocchio
   Sincrotrone Trieste
   SS 14 Km 163.5 Basovizza
   I 34012 Trieste
   Italy

   Phone:   +39 40 3758523
   Fax:     +39 40 3758565
   EMail:  Claudio.Allocchio@elettra.Trieste.it
           C=it; A=garr; P=Trieste; O=Elettra; S=Allocchio; G=Claudio;







































Allocchio                     Experimental                     [Page 33]

RFC 2162                        MaXIM-11                    January 1998


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                     Experimental                     [Page 34]