idnits 2.17.1 draft-ietf-x400ops-mapsmail-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Expected the document's filename to be given on the first page, but didn't find any ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 4 longer pages, the longest (page 6) being 303 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 192 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 4 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** There are 3 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 10 has weird spacing: '... This docum...' == Line 11 has weird spacing: '... enable inter...' == Line 12 has weird spacing: '...dations on M...' == Line 15 has weird spacing: '...omplete scena...' == Line 16 has weird spacing: '...n order to co...' == (187 more instances...) == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (August 22, 1992) is 11563 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 16 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 COSINE S2.2 Claudio Allocchio 2 Draft v2.3 I.N.F.N. - Italy 3 August 22, 1992 4 Allocchio@elettra.trieste.it 6 Mapping between X.400(1984/1988) and Mail-11 (DECnet mail) 8 Status of this Memo: 10 This document describes a set of mappings which will 11 enable inter working between systems operating the CCITT X.400 12 (1984/1988) Recommendations on Message Handling Systems, and 13 systems running the Mail-11 (also known as DECnet mail) protocol. 14 The specifications are valid within DECnet Phase IV addressing and 15 routing scheme. The complete scenario of X.400 / RFC822 / Mail-11 16 is also considered, in order to cover the possible complex cases 17 arising in multiple gateway translations. 19 This document cover mainly the O/R address to DECnet from/to 20 address mapping (and vice versa); other mappings are based on 21 RFC1327 and its updates. 23 This document provides an experimental standard definition, and 24 is expected to be revised after an initial test period. 26 Distribution is unlimited. 28 This document is an Internet Draft. Internet Drafts are working 29 documents of the Internet Engineering Task Force (IETF), its Areas, 30 and its Working Groups. Note that other groups may also distribute 31 working documents as Internet Drafts. 33 Internet Drafts are draft documents valid for a maximum of six 34 months. Internet Drafts may be updated, replaced, or obsoleted 35 by other documents at any time. It is not appropriate to use 36 Internet Drafts as reference material or to cite them other than 37 as a "working draft" or "work in progress." 39 Please check the I-D abstract listing contained in each Internet 40 Draft directory to learn the current status of this or any other 41 Internet Draft. 43 Document Expiration Date 45 This document was submitted on September 23rd, 1992 and its 46 validity will expire on March 23rd 1993. 48 (c) notice: 49 Mail-11, DECnet, VMSmail, VAX/VMS, DEC are trademarks of Digital 50 Equipment Corporation; Jnet is a trademark of Joiner Inc. 52 Chapter 1 - Introduction 54 1.1. X.400 56 The standard referred shortly into this document as 57 "X.400" relates to the CCITT 1984 and 1988 X.400 Series 58 Recommendations covering the Message Oriented Text Interchange 59 Service (MOTIS). This document covers the Inter Personal Messaging 60 System (IPMS) only. 62 1.2. Mail-11 64 Mail-11, also known as DECnet mail and often improperly 65 referred as VMSmail, is the proprietary protocol implemented by 66 Digital Equipment Corporation (DEC) to establish a real-time text 67 messaging system among systems implementing the DECnet Phase IV 68 networking protocols. 70 1.3. RFC 822 72 RFC 822 was defined as a standard for personal messaging 73 systems within the DARPA Internet and is now diffused on top of 74 many different message transfer protocols, like SMTP, UUCP, 75 BITNET, JNT Grey Book, CSnet. Its mapping with X.400 is fully 76 described in RFC1327. In this document we will try to consider 77 its relations with Mail-11, too. 79 1.4. The user community. 81 The community using X.400 messaging system is currently 82 growing in the whole world, but there is still a number of very 83 large communities using Mail-11 based messaging systems willing 84 to communicate easily with X.400 based Message Handling Systems. 85 Among these large DECnet based networks we can include the High 86 Energy Physics network (HEPnet) and the Space Physics Analysis 87 Network (SPAN). 89 The se DECnet communities will in the future possibly 90 migrate to DECnet Phase V (DECnet-OSI) protocols, converting thus 91 their messaging systems to OSI specifications, i.e. merging into 92 the X.400 MHS; however the transition period could be long, and 93 there could always be some DECnet Phase IV communities around. 95 For these reasons a set of mapping rules covering 96 conversion between Mail-11 and X.400 is described in this 97 document. 99 This document also covers the case of Mail-11 systems 100 implementing the "foreign mail protocol" allowing Mail-11 to 101 interface other mail systems, including RFC 822 based system. 103 Chapter 2 - Message Elements 105 2.1. Service Elements 107 Mail-11 protocol offers a very restricted set of elements 108 composing a Inter Personal Message (IPM), whereas X.400 109 specifications support a complex and large amount of service 110 elements. Considering the case where a message is relayed between 111 two X.400 MHS via a DECnet network this could result in a nearly 112 complete loss of information. To minimise this inconvenience most 113 of X.400 service elements will be mapped into Mail-11 text body 114 parts. To consider also the case when a message originates from a 115 network implementing RFC 822 protocols and is relayed via Mail-11 116 to and X.400 MHS, the applied mapping from X.400 service elements 117 into Mail-11 text body part the rules specified in RFC1327 and 118 their updates will be used, producing an RFC822-like header. 120 2.2. Mail-11 service elements 122 All envelope (P1) and header (P2) Mail-11 service 123 elements are supported in the conversion to X.400. Note that 124 Mail-11 P1 is solely composed by P1.From and P1.To, and any other 125 Mail-11 element belongs to Mail-11 P2: 127 - P1.From 128 maps to P1.Originator 130 - P1.To 131 maps to P1.Primary Recipient 133 - P2.From 134 maps to P2.Originator 136 - P2.To 137 maps to P2.Primary Recipient 139 - Cc 140 maps to P2.Copy Recipient 142 - Date 143 maps to Submission Time Stamp 145 - Subj 146 maps to Subject 148 Any eventual RFC822-like text header in Mail-11 body part will be 149 interpreted as specified into RFC1327 and its updates. 151 2.3. X.400 service elements 153 The following X.400 service elements are supported 154 directly into Mail-11 conversion: 156 - P1.Originator 157 maps to P1.'From' 159 - P1.Primary Recipients 160 maps to P1.'To' 162 - P2.Originator 163 maps to P2.'From' 165 - P2.Primary Recipients 166 maps to P2.'To' 168 - Copy Recipients 169 maps to 'Cc' 171 - Submission Time Stamp 172 maps to 'date' 174 - Subject 175 maps to 'Subj' 177 The following X.400 service element is partially 178 supported into Mail-11 conversion: 180 - Blind Copy Recipient 181 to ensure the required privacy, when a message 182 contains a BCC address, the following actions 183 occurs: 184 - a new message is created, containing the body 185 parts; 186 - a new envelope is added to the new message, 187 containing the originator and the BCC 188 recipient addresses only. 189 - the new message is delivered separately. 191 Any other X.400 service element support is done 192 accordingly to RFC1327 including the mapped element into the 193 RFC822-like header into Mail-11 body part. 195 Chapter 3 - Basic Mappings 197 The basic mappings indicated in RFC1327 and its updates 198 should be fully used. 200 Chapter 4 - Addressing 202 4.1. Mail-11 addressing 204 Mail-11 addressing can vary from a very simple case up 205 to complex ones, if there are other Mail-11 to "something-else" 206 gateways involved. In any case a Mail-11 address is an ASCII 207 string composed of different elements. 209 4.2. X.400 addressing 211 On the other hand, An X.400 O/R address is a collection 212 of attributes, which can anyway be presented as an IA5 textual 213 representation as defined in chapter 4 of RFC1327. 215 4.3. Mail-11 address components 217 Let us start defining the different parts composing a 218 Mail-11 address. We can consider any Mail-11 address as composed 219 by 3 parts: 221 [[route]::] [[node]::] local part 223 where 'route' and 'node' are optional and only 'local 224 part' is compulsory. Here comes a strict definition of these 225 elements 227 node = *(ALPHA/DIGIT) / *DIGIT / *DIGIT "." *DIGIT 229 route = *(node "::") 231 local part = username / nickname / for-protocol 233 username = *(ALPHA/DIGIT) 235 nickname = > 237 for-protocol = (f-pref f-sep <">f-address<">) 239 f-pref = *(ALPHA/DIGIT) 241 f-sep = "%" / "::" 243 f-address = printablestring / rfc822-address / X400-text-address 245 X400-text-address = 247 Please note that in x-text-address both the ";" notation and the 248 "/" notation are equivalent and allowed (see examples in 249 different sect.) 251 some examples: 253 route node local part 254 ---------------------------------------------------------- 255 USER47 256 MYNODE::BETTY 257 BOSTON::CLUS02::GOOFY1::MARY34 258 IN%"M.T.Rose@Dicdum.cc.edu" 259 UCLA13::MVAX93::MRGATE::"MBOX1::MBX34::MYC3::BOB" 260 MIAMI2::George.Rosenthal 261 CCUBVX::VS3100::Jnet%"IAB3425@IBAX23L" 262 MRGATE::"C=xx::A=bbb::P=ppp::S=Joe" 263 MAINVX::IN%"path1!path2!user%dom" 264 GWX400::gw%"C=xx;ADMD=aaa;PRMD=ppp;S=Lee;" 265 GX409A::x400%"/C=xx/A=aaa/P=ppp/S=Lee" 266 Chapter 5 - Mapping 268 5.1. Mapping scheme 270 DECnet address field is somehow a 'flat land' with some 271 obliged routes to reach some hidden areas. Thus a truly 272 hierarchical mapping scheme using mapping tables as suitable 273 for RFC822 is not the appropriate solution. A fixed set of rules 274 using DDAs support is defined in order to define the mapping. 276 Another important aspect of the problem is the 277 coexistence of many disjoint DECnet networks, using the same 278 DECnet address space, i.e. 'area' and 'node' numbers. A possible 279 case exists when we have a common X.400 and/or RFC 822 mailing 280 system acting as glue to connect different isolated Mail-11 281 islands. Thus, to identify uniquely each DECnet network we must 282 also introduce the concept of 'DECnet network name', which we 283 will refer shortly as 'net' from now onwards. We define as 'net' 284 a unique ASCII string identifying the DECnet network we are 285 connected to. To be more specific, the 'net' element will 286 identify the DECnet community being served, i.e. it could also 287 differ from the actual official network name. Aliases are 288 allowed for the 'net' attribute. Some possible examples are: 290 net = 'HEPnet' the High Energy Physics DECnet Network 291 net = 'SPAN' the Space Physics Analysis Network 292 net = 'Enet' the Digital Equipment Corporate Network 294 The need of labelling each DECnet network with its name 295 comes also from the requirement to implement the 'intelligent' 296 gateway, i.e. the gateway which is able to understand its 297 ability to connect directly to the specified DECnet network, 298 even if the O/R address specify a path to a different gateway. 299 A more detailed discussion of the problem is in 5.3 and 5.5. 301 A registry of 'net' attributes and their correspondent 302 gateways must also be implemented to insure uniqueness of names. 303 A simple table coupling 'net' and the gateway address is used, 304 in a syntax similar to the 'gate' table used in RFC1327. An 305 example: 307 HEPnet#OU$Cosine-gw.O$@.PRMD$infn.ADMD$garr.C$IT# 308 SPAN#OU$Cosine-gw.O$@.PRMD$infn.ADMD$garr.C$IT# 309 SPAN#O$ESRIN1.PRMD$esa.ADMD$Master400.C$it# 311 Ambiguous left entries are allowed. Gateway implementations 312 could simply choose among one of them, or try them all in cyclic 313 order to obtain better performances. 315 In order to keep the mapping rules very simple, 316 avoiding the need to analyse Mail-11 addresses to distinguish 317 the 'route', 'node' and 'local part', we will define only the 318 minimum set of DDAs strictly needed to cover the mapping 319 problem. 321 5.2. Mail-11 --> X.400 323 We define the following Domain Defined Attributes to map 324 a Mail-11 address: 326 DD.Dnet 327 DD.Mail-11 329 We thus define the mapping rule 331 route::node::localpart 333 maps into 335 C=xx; ADMD=yyy; PRMD=zzz; O=ooo; OU=uuu; DD.Dnet=net; 336 DD.Mail-11=route::node::localpart; 338 with 340 xx = country code of the gateway performing the 341 conversion 342 yyy = Admd of the gateway performing the conversion 343 zzz = Prmd of the gateway performing the conversion 344 ooo = Organisation of the gateway performing the 345 conversion 346 uuu = Org. Unit(s) of the gateway performing the 347 conversion 348 net = name of the DECnet network (e.g. HEPnet, 349 SPAN,...) 351 ('zzz', 'ooo', 'uuu' being used or dropped appropriately in 352 order to identify uniquely within the X.400 MHS the gateway 353 performing the conversion). 355 The following defaults also apply: 357 if 'node' is missing and we are mapping the Mail-11 originator 358 (From) then 'node' defaults to the DECnet node name of the 359 gateway (gwnode); 361 if 'node' is missing and we are mapping the Mail-11 recipient 362 (To, Cc) then 'node' defaults to the DECnet node name of the 363 'From' address. 365 if 'DD.Dnet=net' is missing, then it defaults to a value 366 defined locally by the gateway: if the gateway is connected to 367 one DECnet network only, then 'net' will be the name of this 368 unique network; if the gateway is connected to more than one 369 DECnet network, then the gateway will establish a 'first 370 choice' DECnet network, and 'net' will default to this value. 372 In case 'local part' contains 'x400-text-address' see also 373 section 6.4.3; 375 In case 'local part' contains 'rfc822-address' see also section 376 6.4.4. 378 5.2.1. Examples 380 Let us suppose that: 382 the DECnet network name (net) is 'HEP'; 383 the DECnet node name of the gateway (gwnode) is 'X4TDEC'; 384 the Country Code of the gateway is 'IT' and its ADMD is 'garr' 385 (and these two fields are enough to identify uniquely the 386 gateway within the x.400 MHS). 388 USER47 389 C=it; ADMD=garr; DD.Dnet=HEP; DD.Mail-11=X4TDEC::USER47; 391 MYNODE::BETTY 392 C=it; ADMD=garr; DD.Dnet=HEP; DD.Mail-11=MYNODE::BETTY; 394 BOSTON::CLUS02::GOOFY1::MARY34 395 C=it; ADMD=garr; DD.Dnet=HEP; DD.Mail-11=BOSTON::GOOFY1::MARY34; 397 UCLA13::MVAX93::MRGATE::"MBOX1::MBX34:MYC3::BOB" 398 C=it; ADMD=garr; DD.Dnet=HEP; 399 DD.Mail-11=UCLA13::MVAX93::MRGATE::(q)MBOX1::MBX34::MYC3::BOB(q) 401 MIAMI2::George.Rosenthal 402 C=it; ADMD=garr; DD.Dnet=HEP; DD.Mail-11=MIAMI2::George.Rosenthal; 404 MRGATE::"C=xx::A=bbb::P=ppp::S=Joe" 405 C=it; ADMD=garr; DD.Dnet=HEP; 406 DD.Mail-11=X4TDEC::MRGATE::(q)C=xx::A=bbb::P=ppp::S=Joe(q) 408 MAINVX::In%"path1!path2!user%dom" 409 C=it; ADMD=garr; DD.Dnet=HEP; 410 DD.Mail-11=MAINVX::In(p)(q)path1(b)path2(b)user(p)dom(q) 412 5.3. X.400 encoding of Mail-11 --> Mail-11 414 In order to assure path reversibility in case of 415 multiple Mail-11/X.400 gateway crossing we must distinguish two 416 cases: 418 - DD.Dnet=net is known to the gateway as one of the DECnet 419 networks it is connected to. In this case the mapping is 420 trivial: 422 C=xx; ADMD=yyy; PRMD=zzz; O=ooo; OU=uuu; DD.Dnet=net; 423 DD.Mail-11=route::node::localpart; 425 (see sect. 5.2 for explication of 'xx', 'yyy', 'zzz', 'ooo', 426 'uuu','net') 428 maps into 430 route::node::localpart 432 - DD.Dnet=net is NOT known to the gateway as one of the DECnet 433 networks it is connected to. In this case the mapping rule 434 described into section 5.4 apply: 436 C=xx; ADMD=yyy; PRMD=www; DD.Dnet=net; 437 DD.Mail-11=route::node::localpart; 439 maps into 441 gwnode::gw%"C=xx;ADMD=yyy;PRMD=www;DD.Dnet=net; 442 DD.Mail-11=route::node::localpart;" 444 5.3.1. Examples 446 Let us suppose that: 448 the DECnet network name (net) is 'HEP'; 449 the DECnet node name of the gateway (gwnode) is 'X4TDEC'; 450 the Country Code of the gateway is 'IT' and its ADMD is 'garr'; 451 (and these two fields are enough to identify uniquely the 452 gateway within the x.400 MHS). 454 C=it; ADMD=garr; DD.Dnet=HEP; 455 DD.Mail-11=X4TDEC::MRGATE::(q)C=ab::A=dsa::P=qwerty::OU=mine::S=Clay(q) 456 MRGATE::"C=ab::A=dsa::P=qwerty::OU=mine::S=Clay" 458 C=it; ADMD=garr; DD.Dnet=EASYNET; DD.Mail-11=ROM01::CARLO; 459 X4TDEC::gw%"C=it;ADMD=garr;DD.Dnet=EASYNET; 460 DD.Mail-11=ROM01::CARLO;" 462 (in the above example 'EASYNET' is supposed to be not connected 463 to our gateway located on X4TDEC DECnet node). 465 5.4. X.400 --> Mail-11 467 The mapping of an X.400 O/R address into Mail-11 is 468 done encoding the various attributes into the X400-text-address 469 as defined in chapter 4 of RFC1327, and including this as 470 'f-address'. A 'f-pref' and a 'f-sep' are added completing 471 'local part'. 'gwnode' is included as the DECnet node name of 472 the gateway. 474 Thus 476 x400-text-address 478 will be encoded like 480 gwnode::gw%"x400-text-address" 482 having spaces dividing attributes as optional. 484 5.4.1. Example 486 Let us suppose that: 488 the DECnet node name of the gateway (gwnode) is 'X4TDEC'; 490 Thus 492 C=gb; ADMD=Gold 400; PRMD=AC.UK; O=ucl; OU=cs; G=Paul; S=Smith; 494 will be encoded like 496 X4TDEC::gw%"/C=gb/A=Gold 400/P=AC.UK/O=ucl/OU=cs/G=Paul/S=Smith" 498 or its equivalent with the ";" notation 500 X4TDEC::gw%"C=gb;ADMD=Gold 400;PRMD=AC.UK;O=ucl;OU=cs;G=Paul;S=Smith;" 502 5.5. Mail-11 encoding of X.400 --> X.400 504 It can happened that Mail-11 is used to relay messages 505 between X.400 systems; this will mean multiple X.400/Mail-11 506 gateway crossing and we will encounter Mail-11 addresses 507 containing embedded X.400 information's. In order to assure path 508 reversibility we must then distinguish two cases: 510 - the embedded X.400 address belongs to a domain whose naming 511 and routing rules are known to the global X.400 MHS. In this 512 case the mapping is trivial: 514 route::gwnode::gw%"x400-text-address" 516 maps into 518 x400-text-address 520 'route' and 'gwnode' are mapped into X.400 Trace service 521 elements. 523 - the encoded x.400 domain does not belong to the global X.400 524 name space. In this case the mapping rule described into 525 section 5.2 apply: 527 route::gwnode::gw%"x400-text-address" 529 maps into 531 C=xx; ADMD=yyy; DD.Dnet=net; 532 DD.Mail-11=route::gwnode::gw(p)(q)x400-text-address(q); 534 The latter case is deprecated and must be regarded as a 535 possible temporary solution only, while waiting to include into 536 the global X.400 MHS also this domain. 538 5.5.1. Examples 540 Let us suppose that: 542 the DECnet network name (net) is 'HEP'; 543 the DECnet node name of the gateway (gwnode) is 'X4TDEC'; 544 the Country Code of the gateway is 'IT' and its ADMD is 'garr'; 545 (and these two fields are enough to identify uniquely the 546 gateway within the x.400 MHS). 548 X4TDEC::gw%"C=fr;ADMD=atlas;PRMD=ifip;O=poly;S=Moreau;" 549 C=fr; ADMD=atlas; PRMD=ifip; O=poly; S=Moreau; 551 X4TDEC::gw%"C=zz;ADMD= ;PRMD=Botwa;O=Miner;S=Chiuaw;" 552 C=it; ADMD=garr; DD.Dnet=HEP; 553 DD.Mail-11=X4TDEC::gw(p)(q)C=zz;ADMD= ; 554 PRMD=Botwa;O=Miner;S=Chiuaw;(q) 556 (in the above example C=zz is unknown to the global X.400 MHS) 557 Chapter 6 - Complex mapping 559 6.1. The protocol triangle 561 The bilateral mappings described in chapter 5 must be 562 extended in order to cover also the case in which also RFC 822 563 addressing is involved, and the following triangular situation 564 occurs: 566 x.400 567 / \ 568 / \ 569 / \ 570 Mail-11----RFC822 572 The X.400 - RFC 822 side is fully covered by RFC1327, 573 and the previous chapters in this document cover the 574 Mail-11 - X.400 side. 576 Currently a number of implementations also perform the 577 mapping along the Mail-11 - RFC 822 side. The most important 578 among these de facto standards are discussed in Appendix A, 579 jointly with a Mail-11 - RFC 822 mapping scheme which covers 580 this side of the triangle. 582 6.2. RFC822 mapped in Mail-11 584 The 'rfc822-address' is usually included in 'local 585 part' as 'f-address' using the Mail-11 foreign mail protocol 586 syntax: 588 route::gwnode::gw%"rfc822-address" 590 an example 592 NVXA23::SMTPGW::in%"M.T.Rose@CS.UCLA.edu" 594 6.3. Mail-11 mapped in RFC822 596 There are different styles in mapping a Mail-11 address 597 in RFC 822; let's have a short summary. 599 - Mail-11 address encoded in "Left Hand Side" (LHS) of RFC 822 600 address, using "%" syntax or "::" syntax; 602 route::node::localpart 604 maps to 606 localpart%node%route@gw-domains 608 or 610 "route::node::localpart"@gw-domains 612 where 'gw-domains' identify uniquely the Mail-11 / RFC822 613 gateway. 615 - Mail-11 address maps partly to LHS and partly to 'domain' part 616 of RFC822 address: 618 node::localpart 620 maps to 622 localpart@node.gw-domains 624 - Mail-11 address is completely hidden by a mapping table 625 or directory and the resultant RFC822 address contains no 626 trace at all of the original address. 628 As you could notice, in any of the quoted cases the resultant 629 RFC822 address is not distinguishable from a genuine RFC822 630 address. 632 6.4. Multiple conversions 634 Let us now examine briefly the possible situations 635 which involve multiple conversions, having one protocol as a 636 relay between the other two. This summary suggest some possible 637 enhanced solutions to avoid heavy and unduly mappings, but the 638 'step by step' approach, considering blindly one conversion as 639 disjointed to the other, as described in the previous sections, 640 can always be used. 642 6.4.1. X.400 --> RFC 822 --> Mail-11 644 We apply the RFC1327 rules to the first step, obtaining 645 an RFC 822 address which can be mapped in Mail-11 using the 646 'f-address' field, as described in section 6.2. 648 an example: 650 C=gb; ADMD=Gold 400; PRMD=AC.UK; O=UCL; OU=cs; G=Paul; S=Smith; 652 maps accordingly to RFC1327 to 654 Paul.Smith@cs.UCL.AC.UK 656 and finally becomes 658 SMTPGW::In%"Paul.Smith@cs.UCL.AC.UK" 660 where 'SMTPGW' is the DECnet node name of the machine running 661 the RFC 822 to Mail-11 gateway. 663 6.4.2. Mail-11 --> RFC 822 --> X.400 665 Some of the possible mapping described in section 6.3 666 apply to the Mail-11 address, hiding completely its origin. The 667 RFC1327 apply on the last step. 669 an example: 671 RELAY::MYNODE::BETTY 673 could map into RFC 822 as 675 BETTY%MYNODE@RELAY.dnet.gw1.it 677 and accordingly to RFC1327 679 C=it; A=garr; P=dom1; O=gw1; OU=RELAY; S=BETTY(p)MYNODE; 681 where 'dnet.gw1.it' is the domain of the machine running the 682 Mail-11 to RFC 822 gateway. 684 6.4.3. X.400 --> Mail-11 --> RFC 822 686 The X.400 address is stored into Mail-11 'f-address' 687 element as described in sections 5.3 and 5.4; then if the 688 Mail-11 to RFC 822 gateway is able to understand the presence 689 of a 'x400-text-address' into the Mail-11 address, then it 690 applies RFC1327 to it, and encodes 'route' and 'node' as 691 'Received:' elements into RFC 822 message header. Otherwise it 692 applies the rules described in 6.3 694 an example: 696 C=gb; ADMD=Gold 400; PRMD=AC.UK; O=UCL; OU=cs; G=Paul; S=Smith; 698 will be encoded like 700 X4TDEC::gw%"/C=gb/A=Gold 400/P=AC.UK/O=UCL/OU=cs/G=Paul/S=Smith" 702 If the Mail-11 to RFC822 gateway recognise the x400-text-address, 703 then the address becomes, accordingly to RFC1327 705 Paul.Smith@cs.UCL.AC.UK 707 and the following RFC 822 header line is added 709 Received: from X4TDEC with DECnet (Mail-11) on xx-xxx-xxxx. 711 Otherwise one of the dumb rules could produce 713 gw%"/C=gb/A=Gold 400/P=AC.UK/O=UCL/OU=cs/G=Paul/S=Smith"@X4TDEC.domains 715 6.4.4. RFC 822 --> Mail-11 --> X.400 717 The RFC 822 address is encoded in Mail-11 f-address 718 element as described in sect. 6.2; then if the Mail-11 to X.400 719 gateway is able to understand the presence of an 720 'rfc822-address' into the Mail-11 address, then it applies 721 RFC1327 to it, and encodes 'route' and 'node' as 'trace' 722 elements of the message header. Otherwise it applies the rules 723 described in 5.2 and 5.5. 725 an example: 727 Paul.Smith@cs.UCL.AC.UK 729 will be encoded like 731 SMTPGW::In%"Paul.Smith@cs.UCL.AC.UK" 733 If the Mail-11 to X.400 gateway recognise the rfc822-address, 734 then the address becomes, accordingly to RFC1327 736 C=gb; ADMD=Gold 400; PRMD=AC.UK; O=UCL; OU=cs; G=Paul; S=Smith; 738 and a 'trace' record is added into the X.400 P1 data, stating 739 that a node named SMTPGW was crossed. 741 Otherwise dumb rule produces 743 C=it; ADMD=garr; DD.Dnet=HEP; 744 DD.Mail-11=SMTPGW::In(p)(q)Paul.Smith(a)cs.UCL.AC.UK(q) 746 6.4.5. RFC 822 --> X.400 --> Mail-11 748 We apply RFC1327 to the first conversion, obtaining an 749 X.400 address. Then the rules described in sections 5.3 and 5.4 750 are used to store the X.400 address as 'x400-text-address' into 751 the Mail-11 'local part'. 753 an example: 755 Paul.Smith@cs.UCL.AC.UK 757 maps accordingly to RFC1327 to 759 C=gb; ADMD=Gold 400; PRMD=AC.UK; O=UCL; OU=cs; G=Paul; S=Smith; 761 and finally becomes 763 SMTPGW::gw%"/C=gb/A=Gold 400/P=AC.UK/O=UCL/OU=cs/G=Paul/S=Smith" 765 where 'SMTPGW' is the DECnet node name of the machine running 766 the X.400 to Mail-11 gateway. 768 6.4.6. Mail-11 --> X.400 --> RFC 822 770 The Mail-11 address is encoded as specified in sections 771 5.2 and 5.5; then RFC1327 is used to convert the address in 772 RFC822. 774 an example: 776 RELAY::MYNODE::BETTY 778 maps into X.400 as 780 C=it; ADMD=garr; DD.Dnet=HEP; DD.Mail-11=RELAY::MYNODE::BETTY; 782 and accordingly to RFC1327 784 "/C=it/A=garr/DD.Dnet=HEP/DD.Mail-11=RELAY::MYNODE::BETTY"@gw2.it 786 where 'gw2.it' is the domain of the machine running the RFC1327 787 gateway. 789 Appendix A Mail-11 - RFC 822 mapping 791 A.1 Introduction 793 The implementation of a Mail-11 - RFC 822 gateway was 794 faced by many software developers independently, and was 795 included in many mail products which were running on both 796 VAX/VMS and UNIX systems. As there was not a unique standard 797 mapping way, the implementations resulted into a number of 798 possible variant methods to map a Mail-11 address into an 799 RFC 822 one. Some of these products became then largely 800 widespread, starting to create a number of de-facto mapping 801 methods. 803 In this small appendix some sort of standardisation of 804 the mapping problem is considered, trying to be compatible with 805 the existing installed software. We must also remind that, in 806 some cases, only simple Mail-11 addresses could be mapped into 807 RFC 822, having complex ones producing all sort of quite strange 808 results. 810 On the other hand, the mapping of an RFC 822 address in 811 Mail-11 was quite straightforward, resulting in a common 812 definition which uses "Mail-11 foreign mail protocol" to design 813 an RFC 822 address: 815 [[node::][node::]...]prot%"rfc-822-address" 817 or 819 [node::][node::]...]::"rfc-822-address" 821 A.2 De-facto implementations 823 A considerable number of de-facto implementations of 824 Mail-11 / RFC822 gateways is existing. As said in the 825 introduction, the mapping of RFC 822 addresses in Mail-11 is 826 accomplished using the foreign mail protocol syntax and is thus 827 unique. 829 On the other hand, Mail-11 addresses are encoded in RFC 822 830 syntax in various ways. Here are the most common ones: 832 a) "node::user"@gateway-address 833 b) user%node@gateway-address 834 c) user@node.decnet.domains 835 d) user%node.dnet@gateway-address 837 Let's have a quick look to these different choices. 839 a - This form simply encloses as quoted Left Hand Side string 840 the original Mail-11 address into the RFC 822 address of the 841 Mail-11 / RFC822 gateway. This method is fully conformant with 842 RFC 822 syntax, and the Mail-11 address is left untouched; thus 843 no encoding rules need to applied to it. 845 b - As one will immediately notice, this form has nothing in it 846 indicating the address is a Mail-11 one; this makes the encoding 847 indistinguishable from a similar encoding of RSCS (BITnet) 848 addresses used by some IBM VM Mailer systems. It should thus be 849 deprecated. 851 c - In this case a sort of 'reserved word' (decnet) embedded 852 into the address itself identifies the presence of a Mail-11 853 original address preceding it. The decoding is possible, 854 dropping 'domains' and extracting 'user' and 'node' parts. 855 However complex Mail-11 addresses cannot be mapped properly in 856 this syntax, and there is no specific rule for adding the 857 'domains' part of the address. 859 d - In this case again there is a 'reserved word' (dnet) which 860 make possible the identification of the original Mail-11 861 address; 'gateway-address' points to the Mail-11 / RFC822 862 gateway and 'node' and 'user' information can be easily drawn 863 from the address. However complex Mail-11 addresses cannot be 864 embedded easily into this syntax. 866 A.3 Recommended mappings 868 From the examples seen in the previous paragraphs we 869 can derive a canonical form for representing the mapping between 870 Mail-11 and RFC822. 872 A3.1 RFC822 mapped in Mail-11 874 The mapping of an RFC 822 address in Mail-11 is 875 straightforward, using the "Mail-11 foreign mail protocol" 876 syntax. The two possible variants are: 878 [[node::][node::]...]prot%"rfc-822-address" 880 or 882 [node::][node::]...]::"rfc-822-address" 884 A3.2 Mail-11 mapped in RFC822 886 RFC822 foresee a canonical form for representing 887 non-RFC822 addresses: put the foreign address in local part 888 (Left Hand Side, LHS) is a form as similar as possible to its 889 original syntax. Thus the suggested mapping is: 891 "Mail-11-address"@gateway-address 893 This format assures also the return path via the appropriate 894 gateway. 896 A.4 Conclusions 898 A standard way of mapping Mail-11 addresses into 899 RFC 822 and vice versa is feasible. A suggestion is thus made to 900 unify all existing and future implementations. It should be 901 noted, however, that there is no way to specify in these 902 mappings the name of the decnet community owning the encoded 903 address, as it was done for X.400, thus the implementation of 904 the 'intelligent' gateway in this case is impossible. 906 Acknowledgements 908 I wish to thank all those people which read the first 909 draft and contributed a lot with their useful suggestions to the 910 revision of this document, in particular RARE WG1 and IETF X.400 911 ops group members and S. Hardcastle-Kille. 913 Author's address 915 Claudio Allocchio Phone: +39 40 3758523 916 Cosine S2.2 Fax: +30 49 226338 917 Sincrotrone Trieste e-mail: allocchio@elettra.trieste.it 918 c/o Area di Ricerca 919 Padriciano 99 920 I 34012 Trieste (TS) 921 Italy 923 References 925 CCITT, "CCITT Recommendations X.400-X.430," Message Handling 926 Systems: Red Book, October 1984 928 CCITT, "CCITT Recommendations X.400-X.420," Message Handling 929 Systems: Blue Book, November 1988 931 D.H. Crocker, "Standard of the Format of ARPA Internet Text 932 Messages," RFC 822, August 1982. 934 S.E. Kille, "Mapping Between X.400 and RFC 822," UK Academic 935 Community Report (MG.19) / RFC 987, June 1986. 937 S.E. Kille, "Mapping Between X.400(1988) / ISO 10021 and RFC 938 822," RFC 1327, March 1992. 940 Digital Equipment Corp.;, "VAX/VMS Mail Utility" 942 Joiner Associates Inc., "Jnet User's Manual" 944 PMDF User's Guide. 946 Document Expiration Date 948 This document was submitted on September 23rd, 1992 and its 949 validity will expire on March 23rd 1993.