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
|
<pre>Network Working Group C. Allocchio
Request for Comments: 1405 I.N.F.N. - Italy
January 1993
<span class="h1">Mapping between X.400(1984/1988) and Mail-11 (DECnet mail)</span>
Status of this Memo
This memo defines an Experimental Protocol for the Internet
community. Discussion and suggestions for improvement are requested.
Please refer to the current edition of the "IAB Official Protocol
Standards" for the standardization state and status of this protocol.
Distribution of this memo is unlimited.
Abstract
This document describes a set of mappings which will enable inter
working between systems operating the CCITT X.400 ( 1984 / 1988 )
Recommendations on Message Handling Systems, and systems running the
Mail-11 (also known as DECnet mail) protocol. The specifications are
valid within DECnet Phase IV addressing and routing scheme.
The complete scenario of X.400 / <a href="./rfc822">RFC822</a> / Mail-11 is also considered,
in order to cover the possible complex cases arising in multiple
gateway translations.
This document covers mainly the O/R address to DECnet from/to address
mapping (and vice versa); other mappings are based on <a href="./rfc1327">RFC 1327</a> and
its eventual future updates.
This is a combined effort of COSINE S2.2, the RARE MSG Working Group,
and the IETF X.400 Ops Working Group.
Chapter 1 - Introduction
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. X.400</span>
The standard referred shortly into this document as "X.400" relates
to the CCITT 1984 and 1988 X.400 Series Recommendations covering the
Message Oriented Text Interchange Service (MOTIS). This document
covers the Inter Personal Messaging System (IPMS) only.
<span class="h3"><a class="selflink" id="section-1.2" href="#section-1.2">1.2</a>. Mail-11</span>
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
<span class="grey">Allocchio [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc1405">RFC 1405</a> Mail-11 Mapping January 1993</span>
among systems implementing the DECnet Phase IV networking protocols.
<span class="h3"><a class="selflink" id="section-1.3" href="#section-1.3">1.3</a>. <a href="./rfc822">RFC822</a></span>
<a href="./rfc822">RFC822</a> 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. Its mapping with X.400 is fully described in
<a href="./rfc1327">RFC1327</a>. In this document we will try to consider its relations with
Mail-11, too.
<span class="h3"><a class="selflink" id="section-1.4" href="#section-1.4">1.4</a>. The user community</span>
The community using 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. Among
these large DECnet based networks we can include the High Energy
Physics network (HEPnet) and the Space Physics Analysis Network
(SPAN).
These DECnet communities will in the future possibly migrate to
DECnet Phase V (DECnet-OSI) protocols, converting thus their
messaging systems to OSI specifications, i.e., merging into the X.400
MHS; however the transition period could be long, and there could
always be some DECnet Phase IV communities around.
For these reasons a set of mapping rules covering conversion between
Mail-11 and X.400 is described in this document.
This document also covers the case of Mail-11 systems implementing
the "foreign mail protocol" allowing Mail-11 to interface other mail
systems, including <a href="./rfc822">RFC822</a> based system.
Chapter 2 - Message Elements
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. Service Elements</span>
Mail-11 protocol offers a very restricted set of elements composing a
Inter Personal Message (IPM), whereas X.400 specifications support a
complex and large amount of service elements. Considering the case
where a message is relayed between two X.400 MHS via a DECnet network
this could result in a nearly complete loss of information. To
minimise this inconvenience most of X.400 service elements will be
mapped into Mail-11 text body parts. To consider also the case when a
message originates from a network implementing <a href="./rfc822">RFC822</a> protocols and
is relayed via Mail-11 to and X.400 MHS, the applied mapping from
X.400 service elements into Mail-11 text body part the rules
<span class="grey">Allocchio [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc1405">RFC 1405</a> Mail-11 Mapping January 1993</span>
specified in <a href="./rfc1327">RFC1327</a> and their updates will be used, producing an
<a href="./rfc822">RFC822</a>-like header.
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. Mail-11 service elements</span>
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.From and P1.To, and any other Mail-11 element belongs
to Mail-11 P2:
- P1.From
maps to P1.Originator
- P1.To
maps to P1.Primary Recipient
- P2.From
maps to P2.Originator
- P2.To
maps to P2.Primary Recipient
- Cc
maps to P2.Copy Recipient
- Date
maps to Submission Time Stamp
- Subj
maps to Subject
Any eventual <a href="./rfc822">RFC822</a>-like text header in Mail-11 body part will be
interpreted as specified into <a href="./rfc1327">RFC1327</a> and its updates.
<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>. X.400 service elements</span>
The following X.400 service elements are supported directly into
Mail-11 conversion:
- P1.Originator
maps to P1.'From'
- P1.Primary Recipients
maps to P1.'To'
- P2.Originator
maps to P2.'From'
<span class="grey">Allocchio [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc1405">RFC 1405</a> Mail-11 Mapping January 1993</span>
- P2.Primary Recipients
maps to P2.'To'
- Copy Recipients
maps to 'Cc'
- Submission Time Stamp
maps to 'date'
- Subject
maps to 'Subj'
The following X.400 service element is partially supported into
Mail-11 conversion:
- 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
<a href="./rfc1327">RFC1327</a> including the mapped element into the <a href="./rfc822">RFC822</a>-like header into
Mail-11 body part.
Chapter 3 - Basic Mappings
The basic mappings indicated in <a href="./rfc1327">RFC1327</a> and its updates should be
fully used.
Chapter 4 - Addressing
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Mail-11 addressing</span>
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.
<span class="grey">Allocchio [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc1405">RFC 1405</a> Mail-11 Mapping January 1993</span>
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. X.400 addressing</span>
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 chapter 4 of <a href="./rfc1327">RFC1327</a>.
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>. Mail-11 address components</span>
Let us start defining the different parts composing a Mail-11
address. We can consider any Mail-11 address as composed by 3 parts:
[[route]::] [[node]::] local-part
where 'route' and 'node' are optional and only 'local-part' is
compulsory.
Here comes a strict definition of these elements
node = *(ALPHA/DIGIT) / *DIGIT / *DIGIT "." *DIGIT
route = *(node "::")
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 / <a href="./rfc822">RFC822</a>-address / X400-text-address
X400-text-address = <textual representation of an X.400 O/R addr>
Please note that in x-text-address both the ";" notation and the "/"
notation are equivalent and allowed (see examples in different sect.)
<span class="grey">Allocchio [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc1405">RFC 1405</a> Mail-11 Mapping January 1993</span>
Some examples:
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"
Chapter 5 - Mapping
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Mapping scheme</span>
DECnet address field is somehow a 'flat land' with some obliged
routes to reach some hidden areas. Thus a truly hierarchical mapping
scheme using mapping tables as suitable for <a href="./rfc822">RFC822</a> is not the
appropriate solution. A fixed set of rules using DDAs support is
defined in order to define the mapping.
Another important aspect of the problem is the coexistence of many
disjoint DECnet networks, using the same DECnet address space, i.e.,
common X.400 and/or <a href="./rfc822">RFC822</a> mailing system acting as glue to connect
different isolated Mail-11 islands. Thus, to identify uniquely each
DECnet network we must also introduce the concept of 'DECnet network
name', which we will refer shortly as 'net' from now onwards. We
define as 'net' a unique ASCII string identifying the DECnet network
we are connected to. To be more specific, the 'net' element will
identify the DECnet community being served, i.e., it could also
differ from the actual official network name. Aliases are allowed for
the
net = 'HEPnet' the High Energy Physics DECnet network
net = 'SPAN' the Space Physics Analysis Network
net = 'Enet' the Digital Equipment Corporate Network
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
<span class="grey">Allocchio [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc1405">RFC 1405</a> Mail-11 Mapping January 1993</span>
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.
A registry of 'net' attributes and their correspondent gateways must
also be implemented to insure uniqueness of names. A simple table
coupling 'net' and the gateway address is used, in a syntax similar
to the 'gate' table used in <a href="./rfc1327">RFC1327</a>. An example:
HEPnet#OU$Cosine-gw.O$@.PRMD$infn.ADMD$garr.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 them, or try them all in cyclic order to
obtain better performances.
In order to keep the mapping rules very simple, avoiding the need to
analyse Mail-11 addresses to distinguish the 'route', 'node' and
needed to cover the mapping problem.
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Mail-11 --> X.400</span>
We define the following Domain Defined Attributes to map a Mail-11
address:
DD.Dnet
DD.Mail-11
We thus define the 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;
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., HEPnet, SPAN,...)
('zzz','ooo','uuu' being used or dropped appropriately in order to
<span class="grey">Allocchio [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc1405">RFC 1405</a> Mail-11 Mapping January 1993</span>
identify uniquely within the X.400 MHS the gateway performing the
conversion).
The following defaults also apply:
if 'node' is missing and we are mapping the Mail-11 originator (From)
then 'node' defaults to the DECnet node name of the gateway (gwnode);
if 'node' is missing and we are mapping the Mail-11 recipient (To,
Cc) then 'node' defaults to the DECnet node name of the 'From'
address.
if 'DD.Dnet=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.
In case 'local-part' contains 'x400-text-address' see also <a href="#section-6.4.3">section</a>
<a href="#section-6.4.3">6.4.3</a>;
In case 'local-part' contains '<a href="./rfc822">RFC822</a>-address' see also <a href="#section-6.4.4">section</a>
<a href="#section-6.4.4">6.4.4</a>.
<span class="h4"><a class="selflink" id="section-5.2.1" href="#section-5.2.1">5.2.1</a>. Examples</span>
Let us suppose that:
the DECnet network name (net) is 'HEP';
the DECnet node name of the gateway (gwnode) is 'X4TDEC';
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=HEP; DD.Mail-11=X4TDEC::USER47;
MYNODE::BETTY
C=it; ADMD=garr; DD.Dnet=HEP; DD.Mail-11=MYNODE::BETTY;
BOSTON::CLUS02::GOOFY1::MARY34
C=it; ADMD=garr; DD.Dnet=HEP; DD.Mail-11=BOSTON::GOOFY1::MARY34;
UCLA13::MVAX93::MRGATE::"MBOX1::MBX34:MYC3::BOB"
C=it; ADMD=garr; DD.Dnet=HEP;
DD.Mail-11=UCLA13::MVAX93::MRGATE::(q)MBOX1::MBX34::MYC3::BOB(q)
<span class="grey">Allocchio [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc1405">RFC 1405</a> Mail-11 Mapping January 1993</span>
MIAMI2::George.Rosenthal
C=it; ADMD=garr; DD.Dnet=HEP; DD.Mail-11=MIAMI2::George.Rosenthal;
MRGATE::"C=xx::A=bbb::P=ppp::S=Joe"
C=it; ADMD=garr; DD.Dnet=HEP;
DD.Mail-11=X4TDEC::MRGATE::(q)C=xx::A=bbb::P=ppp::S=Joe(q)
MAINVX::In%"path1!path2!user%dom"
C=it; ADMD=garr; DD.Dnet=HEP;
DD.Mail-11=MAINVX::In(p)(q)path1(b)path2(b)user(p)dom(q)
<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>. X.400 encoding of Mail-11 --> Mail-11</span>
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
- 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 <a href="#section-5.4">section 5.4</a> 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;"
<span class="h4"><a class="selflink" id="section-5.3.1" href="#section-5.3.1">5.3.1</a>. Examples</span>
Let us suppose that:
the DECnet network name (net) is 'HEP';
the DECnet node name of the gateway (gwnode) is 'X4TDEC';
the Country Code of the gateway is 'IT' and its ADMD is 'garr';
(and these two fields are enough to identify uniquely the gateway
<span class="grey">Allocchio [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc1405">RFC 1405</a> Mail-11 Mapping January 1993</span>
within the X.400 MHS).
C=it; ADMD=garr; DD.Dnet=HEP;
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 X4TDEC DECnet node).
<span class="h3"><a class="selflink" id="section-5.4" href="#section-5.4">5.4</a>. X.400 --> Mail-11</span>
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 <a href="./rfc1327">RFC1327</a>, and including this as 'f-address'. A 'f-pref' and a the
DECnet node name of the gateway.
Thus
x400-text-address
will be encoded like
gwnode::gw%"x400-text-address"
having spaces dividing attributes as optional.
<span class="h4"><a class="selflink" id="section-5.4.1" href="#section-5.4.1">5.4.1</a>. Example</span>
Let us suppose that:
the DECnet node name of the gateway (gwnode) is 'X4TDEC';
Thus
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"
or its equivalent with the ";" notation
X4TDEC::gw%"C=gb;ADMD=Gold 400;PRMD=AC.UK;O=ucl;OU=cs;G=Jim;S=Clay;"
<span class="grey">Allocchio [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc1405">RFC 1405</a> Mail-11 Mapping January 1993</span>
<span class="h3"><a class="selflink" id="section-5.5" href="#section-5.5">5.5</a>. Mail-11 encoding of X.400 --> X.400</span>
It can happened 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:
- 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"
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 <a href="#section-5.2">section 5.2</a>
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);
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.
<span class="h4"><a class="selflink" id="section-5.5.1" href="#section-5.5.1">5.5.1</a>. Examples</span>
Let us suppose that:
the DECnet network name (net) is 'HEP';
the DECnet node name of the gateway (gwnode) is 'X4TDEC';
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;
<span class="grey">Allocchio [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc1405">RFC 1405</a> Mail-11 Mapping January 1993</span>
X4TDEC::gw%"C=zz;ADMD= ;PRMD=Botwa;O=Miner;S=Chiuaw;"
C=it; ADMD=garr; DD.Dnet=HEP;
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 - Complex mapping
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. The protocol triangle</span>
The bilateral mappings described in chapter 5 must be extended in
order to cover also the case in which also <a href="./rfc822">RFC822</a> addressing is
involved, and the following triangular situation occurs:
x.400
/ \
/ \
/ \
Mail-11----RFC822
The X.400 - <a href="./rfc822">RFC822</a> side is fully covered by <a href="./rfc1327">RFC1327</a>, and the previous
chapters in this document cover the Mail-11 - X.400 side.
Currently a number of implementations also perform the mapping along
the Mail-11 - <a href="./rfc822">RFC822</a> side. The most important among these de facto
standards are discussed in <a href="#appendix-A">Appendix A</a>, jointly with a Mail-11 -
<a href="./rfc822">RFC822</a> mapping scheme which covers this side of the triangle.
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. <a href="./rfc822">RFC822</a> mapped in Mail-11</span>
The '<a href="./rfc822">RFC822</a>-address' is usually included in 'local-part' as
route::gwnode::gw%"<a href="./rfc822">rfc822</a>-address"
an example
NVXA23::SMTPGW::in%"M.T.Rose@CS.UCLA.edu"
<span class="h3"><a class="selflink" id="section-6.3" href="#section-6.3">6.3</a>. Mail-11 mapped in <a href="./rfc822">RFC822</a></span>
There are different styles in mapping a Mail-11 address in <a href="./rfc822">RFC822</a>;
let's have a short summary.
- Mail-11 address encoded in "Left Hand Side" (LHS) of <a href="./rfc822">RFC822</a>
address, using "%" syntax or "::" syntax;
route::node::localpart
<span class="grey">Allocchio [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc1405">RFC 1405</a> Mail-11 Mapping January 1993</span>
maps to
localpart%node%route@gw-domains
or
"route::node::localpart"@gw-domains
where 'gw-domains' identify uniquely the Mail-11 / <a href="./rfc822">RFC822</a> gateway.
- Mail-11 address maps partly to LHS and partly to 'domain' part of
<a href="./rfc822">RFC822</a> address:
node::localpart
maps to
localpart@node.gw-domains
- Mail-11 address is completely hidden by a mapping table / directory
and the resultant <a href="./rfc822">RFC822</a> address contains no trace at all of the
original address.
As you could notice, in any of the quoted cases the resultant <a href="./rfc822">RFC822</a>
address is not distinguishable from a genuine <a href="./rfc822">RFC822</a> address.
<span class="h3"><a class="selflink" id="section-6.4" href="#section-6.4">6.4</a>. Multiple conversions</span>
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.
<span class="h4"><a class="selflink" id="section-6.4.1" href="#section-6.4.1">6.4.1</a>. X.400 --> <a href="./rfc822">RFC822</a> --> Mail-11</span>
We apply the <a href="./rfc1327">RFC1327</a> rules to the first step, obtaining an <a href="./rfc822">RFC822</a>
address which can be mapped in Mail-11 using the 'f-address' field,
as described in <a href="#section-6.2">section 6.2</a>.
an example:
C=gb; ADMD=Gold 400; PRMD=AC.UK; O=UCL; OU=cs; G=Jim; S=Clay;
maps accordingly to <a href="./rfc1327">RFC1327</a> to
Jim.Clay@cs.UCL.AC.UK
<span class="grey">Allocchio [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc1405">RFC 1405</a> Mail-11 Mapping January 1993</span>
and finally becomes
SMTPGW::In%"Jim.Clay@cs.UCL.AC.UK"
where 'SMTPGW' is the DECnet node name of the machine running the
<a href="./rfc822">RFC822</a> to Mail-11 gateway.
<span class="h4"><a class="selflink" id="section-6.4.2" href="#section-6.4.2">6.4.2</a>. Mail-11 --> <a href="./rfc822">RFC822</a> --> X.400</span>
Some of the possible mapping described in <a href="#section-6.3">section 6.3</a> apply to the
Mail-11 address, hiding completely its origin. The <a href="./rfc1327">RFC1327</a> apply on
the last step.
an example:
RELAY::MYNODE::BETTY
could map into <a href="./rfc822">RFC822</a> as
BETTY%MYNODE@RELAY.dnet.gw1.it
and accordingly to <a href="./rfc1327">RFC1327</a>
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 <a href="./rfc822">RFC822</a> gateway.
<span class="h4"><a class="selflink" id="section-6.4.3" href="#section-6.4.3">6.4.3</a>. X.400 --> Mail-11 --> <a href="./rfc822">RFC822</a></span>
The X.400 address is stored into Mail-11 'f-address' element as
described in sections <a href="#section-5.3">5.3</a> and <a href="#section-5.4">5.4</a>; then if the Mail-11 to <a href="./rfc822">RFC822</a>
gateway is able to understand the presence of a 'x400-text-address'
into the Mail-11 address, then it applies <a href="./rfc1327">RFC1327</a> to it, and encodes
header. Otherwise it applies the rules described in 6.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 <a href="./rfc822">RFC822</a> gateway recognise the x400-text-address,
then the address becomes, accordingly to <a href="./rfc1327">RFC1327</a>
Jim.Clay@cs.UCL.AC.UK
<span class="grey">Allocchio [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc1405">RFC 1405</a> Mail-11 Mapping January 1993</span>
and the following <a href="./rfc822">RFC822</a> 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
<span class="h4"><a class="selflink" id="section-6.4.4" href="#section-6.4.4">6.4.4</a>. <a href="./rfc822">RFC822</a> --> Mail-11 --> X.400</span>
The <a href="./rfc822">RFC822</a> address is encoded in Mail-11 f-address element as
described in sect. 6.2; then if the Mail-11 to X.400 gateway is able
to understand the presence of an '<a href="./rfc822">RFC822</a>-address' into the Mail-11
address, then it applies <a href="./rfc1327">RFC1327</a> 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 <a href="./rfc822">RFC822</a>-address, then
the address becomes, accordingly to <a href="./rfc1327">RFC1327</a>
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)
<span class="h4"><a class="selflink" id="section-6.4.5" href="#section-6.4.5">6.4.5</a>. <a href="./rfc822">RFC822</a> --> X.400 --> Mail-11</span>
We apply <a href="./rfc1327">RFC1327</a> to the first conversion, obtaining an X.400 address.
Then the rules described in sections <a href="#section-5.3">5.3</a> and <a href="#section-5.4">5.4</a> are used to store
the X.400 address as 'x400-text-address' into the Mail-11
an example:
Jim.Clay@cs.UCL.AC.UK
maps accordingly to <a href="./rfc1327">RFC1327</a> to
<span class="grey">Allocchio [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc1405">RFC 1405</a> Mail-11 Mapping January 1993</span>
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 node name of the machine running the
X.400 to Mail-11 gateway.
<span class="h4"><a class="selflink" id="section-6.4.6" href="#section-6.4.6">6.4.6</a>. Mail-11 --> X.400 --> <a href="./rfc822">RFC822</a></span>
The Mail-11 address is encoded as specified in sections <a href="#section-5.2">5.2</a> and <a href="#section-5.5">5.5</a>;
then <a href="./rfc1327">RFC1327</a> is used to convert the address in <a href="./rfc822">RFC822</a>.
an example:
RELAY::MYNODE::BETTY
maps into X.400 as
C=it; ADMD=garr; DD.Dnet=HEP; DD.Mail-11=RELAY::MYNODE::BETTY;
and accordingly to <a href="./rfc1327">RFC1327</a>
"/C=it/A=garr/DD.Dnet=HEP/DD.Mail-11=RELAY::MYNODE::BETTY"@gw2.it
where 'gw2.it' is the domain of the machine running the <a href="./rfc1327">RFC1327</a>
gateway.
Appendix A Mail-11 - <a href="./rfc822">RFC822</a> mapping
<span class="h3"><a class="selflink" id="appendix-A.1" href="#appendix-A.1">A.1</a> Introduction</span>
The implementation of a Mail-11 - <a href="./rfc822">RFC822</a> gateway was faced by many
software developers independently, and was included in many mail
products which were running on both VAX/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 <a href="./rfc822">RFC822</a> one. Some of these products became then
largely widespread, starting to create a number of de facto mapping
methods.
In this small appendix 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 <a href="./rfc822">RFC822</a>, having complex
ones producing all sort of quite strange results.
<span class="grey">Allocchio [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc1405">RFC 1405</a> Mail-11 Mapping January 1993</span>
On the other hand, the mapping of an <a href="./rfc822">RFC822</a> address in Mail-11 was
quite straightforward, resulting in a common definition which uses
"Mail-11 foreign mail protocol" to design an <a href="./rfc822">RFC822</a> address:
[[node::][node::]...]prot%"<a href="./rfc822">rfc-822</a>-address"
or
[node::][node::]...]::"<a href="./rfc822">rfc-822</a>-address"
<span class="h3"><a class="selflink" id="appendix-A.2" href="#appendix-A.2">A.2</a> De facto implementations</span>
A considerable number of de-facto implementations of Mail-11/RFC822
gateways is existing. As said in the introduction, the mapping of
<a href="./rfc822">RFC822</a> 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 <a href="./rfc822">RFC822</a> 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 <a href="./rfc822">RFC822</a> address of the
Mail-11/RFC822 gateway. This method is fully conformant with
<a href="./rfc822">RFC822</a> syntax, and the Mail-11 address is left untouched; thus
no encoding rules need to applied to it.
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.
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.
<span class="grey">Allocchio [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc1405">RFC 1405</a> Mail-11 Mapping January 1993</span>
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.
<span class="h3"><a class="selflink" id="appendix-A.3" href="#appendix-A.3">A.3</a> Recommended mappings</span>
From the examples seen in the previous paragraphs we can derive a
canonical form for representing the mapping between Mail-11 and
<a href="./rfc822">RFC822</a>.
A3.1 <a href="./rfc822">RFC822</a> mapped in Mail-11
The mapping of an <a href="./rfc822">RFC822</a> address in Mail-11 is straightforward, using
the "Mail-11 foreign mail protocol" syntax. The two possible variants
are:
[[node::][node::]...]prot%"<a href="./rfc822">rfc-822</a>-address"
or
[node::][node::]...]::"<a href="./rfc822">rfc-822</a>-address"
A3.2 Mail-11 mapped in <a href="./rfc822">RFC822</a>
<a href="./rfc822">RFC822</a> 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 is:
"Mail-11-address"@gateway-address
This format assures also the return path via the appropriate gateway.
<span class="h3"><a class="selflink" id="appendix-A.4" href="#appendix-A.4">A.4</a> Conclusions</span>
A standard way of mapping Mail-11 addresses into <a href="./rfc822">RFC822</a> and vice
versa is feasible. A suggestion is thus made to unify all existing
and future implementations. It should be noted, however, that there
is no way to specify in these mappings the name of the decnet
community owning the encoded address, as it was done for X.400, thus
the implementation of the 'intelligent' gateway in this case is
impossible.
<span class="grey">Allocchio [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc1405">RFC 1405</a> Mail-11 Mapping January 1993</span>
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. Hardcastle-Kille.
References
[<a id="ref-1">1</a>] CCITT, "CCITT Recommendations X.400-X.430", Message Handling
Systems: Red Book, October 1984.
[<a id="ref-2">2</a>] CCITT, "CCITT Recommendations X.400-X.420", Message Handling
Systems: Blue Book, November 1988.
[<a id="ref-3">3</a>] Crocker, D., "Standard of the Format of ARPA Internet Text
Messages", STD 11, <a href="./rfc822">RFC 822</a>, UDel, August 1982.
[<a id="ref-4">4</a>] Kille, S., "Mapping Between X.400 and <a href="./rfc822">RFC 822</a>", UK Academic
Community Report (MG.19) / <a href="./rfc987">RFC 987</a>, June 1986.
[<a id="ref-5">5</a>] Kille, S., "Mapping Between X.400(1988) / ISO 10021 and <a href="./rfc822">RFC</a>
<a href="./rfc822">822</a>", <a href="./rfc1327">RFC 1327</a>, March 1992.
[<a id="ref-6">6</a>] Digital Equipment Corp.;, "VAX/VMS Mail Utility".
[<a id="ref-7">7</a>] Joiner Associates Inc., "Jnet User's Manual".
[<a id="ref-8">8</a>] PMDF User's Guide.
Security Considerations
Security issues are not discussed in this memo.
Author's Address
Claudio Allocchio
Cosine S2.2
Sincrotrone Trieste
Area di Ricerca
Padriciano 99
I 34012 Trieste
Italy
Phone: +39 40 3758523
Fax: +39 40 226338
EMail: Claudio.Allocchio@elettra.Trieste.it
C=it; A=garr; P=Trieste; O=Elettra; S=Allocchio; G=Claudio;
Allocchio [Page 19]
</pre>
|
