Internet Draft Claudio Allocchio I.N.F.N. - Italy March 2nd, 1992 Allocchio@elettra-ts.infn.it Mapping between X.400(1984/1988) and Mail-11 (DECnet mail) Status of this Memo: 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 / RFC822 / Mail-11 is also considered, in order to cover the possible complex cases arising in multiple gateway translations. This document cover mainly the O/R address to DECnet from/to address mapping (and vice versa); other mappings are based on RFC1148 and its updates. Distribution is unlimited. (c) notice: Mail-11, DECnet, VMSmail, VAX/VMS, DEC are trademarks of Digital Equipment Corporation; Jnet is a trademark of Joiner Inc. Chapter 1 - Introduction 1.1. X.400 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. 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 networking protocols. 1.3. RFC 822 RFC 822 was defined as a standard for personal messaging systems within the DARPA Internet and is now diffused on top of may different message transfer protocols, like SMTP, UUCP, BITNET, JNT Grey Book, CSnet. Its mapping with X.400 is fully described in RFC1148. In this document we will try to consider its relations with Mail-11, too. 1.4. The user community. 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 RFC 822 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 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 RFC 822 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 specified in RFC1148 and their updates will be used, producing an RFC822-like header. 2.2. Mail-11 service elements All Mail-11 service elements are supported in the conversion to X.400: - From maps to Originator - To maps to Primary Recipient - Cc maps to Copy Recipient - Date maps to Submission Time Stamp - Subj maps to Subject Any eventual RFC822-like text header in Mail-11 body part will be interpreted as specified into RFC1148 and its updates. 2.3. X.400 service elements The following X.400 service elements are supported directly into Mail-11 conversion: - Originator maps to 'From' - Primary Recipients maps to '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 maps to Mail-11 'Cc' element, with a (BCC) comment note aside it. The other recipients of the message are hidden as required by the BCC element itself. Any other X.400 service element support is done accordingly to RFC1148 including the mapped element into the RFC822-like header into Mail-11 body part. Chapter 3 - Basic Mappings The basic mappings indicated in RFC987, RFC1148 and their updates should be fully used. Chapter 4 - Addressing 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 chapter 4 of RFC1148. 4.3. Mail-11 address components 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 = > 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 = Please note that in x-text-address both the ";" notation and the "/" notation are equivalent and allowed (see examples in different sect.) some examples: route node local part ---------------------------------------------------------- USER47 MYNODE::BETTY BOSTON::CLUS02::GOOFY1::MARY34 IN%"M.T.Rose@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" Chapter 5 - Mapping 5.1. Mapping scheme 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 RFC822 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. 'area' and 'node' numbers. A possible case exists when we have a common X.400 and/or RFC 822 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. Some possible examples are: 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 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. In order to keep the mapping rules very simple, avoiding the need to analyse Mail-11 addresses to distinguish the 'route', 'node' and 'local part', we will define only the minimum set of DDAs strictly 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 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 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 bythe 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 connectedto 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 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 '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) 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) 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 - 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;" 5.3.1. Examples 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). C=it; ADMD=garr; DD.Dnet=HEP; DD.Mail-11=X4TDEC::MRGATE::(q)C=ab::A=dsa::P=qwerty::OU=mine::S=Clay(q) MRGATE::"C=ab::A=dsa::P=qwerty::OU=mine::S=Clay" 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). 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 RFC1148, and including this as 'f-address'. A 'f-pref' and a 'f-sep' are added completing 'local part'. 'gwnode' is included as the DECnet node name of the gateway. Thus x400-text-address will be encoded like gwnode::gw%"x400-text-address" having spaces separing attributes as optional. 5.4.1. Example 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=Paul; S=Smith; will be encoded like X4TDEC::gw%"/C=gb/A=Gold 400/P=AC.UK/O=ucl/OU=cs/G=Paul/S=Smith" or its equivalent with the ";" notation X4TDEC::gw%"C=gb;ADMD=Gold 400;PRMD=AC.UK;O=ucl;OU=cs;G=Paul;S=Smith;" 5.5. Mail-11 encoding of X.400 --> X.400 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 information's. 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 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); 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. 5.5.1. Examples 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; 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 6.1. The protocol triangle The bilateral mappings described in chapter 5 must be extended in order to cover also the case in which also RFC 822 addressing is involved, and the following triangular situation occurs: x.400 / \ / \ / \ Mail-11----RFC822 The X.400 - RFC 822 side is fully covered by RFC1148, and the previous chapters in this document cover the Mail-11 - X.400 side. There is no specification covering the mail-11 - RFC 822 side, but a number of implementations can be considered as a de facto mapping scheme. 6.2. RFC822 mapped in Mail-11 The 'rfc822-address' is usually included in 'local part' as 'f-address' using the Mail-11 foreign mail protocol syntax: route::gwnode::gw%"rfc822-address" an example NVXA23::SMTPGW::in%"M.T.Rose@CS.UCLA.edu" 6.3. Mail-11 mapped in RFC822 There are different styles in mapping a Mail-11 address in RFC 822; let's have a short summary. - Mail-11 address encoded in "Left Hand Side" (LHS) of RFC 822 address, using "%" syntax or "::" syntax; route::node::localpart maps to localpart%node%route@gw-domains or "route::node::localpart"@gw-domains where 'gw-domains' identify uniquely the Mail-11 / RFC822 gateway. - Mail-11 address maps partly to LHS and partly to 'domain' part of RFC822 address: node::localpart maps to localpart@node.gw-domains - Mail-11 address is completely hidden by a mapping table / directory and the resultant RFC822 address contains no trace at all of the original address. As you could notice, in any of the quoted cases the resultant RFC822 address is not distinguishable from a genuine RFC822 address. 6.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. 6.4.1. X.400 --> RFC 822 --> Mail-11 We apply the RFC1148 rules to the first step, obtaining an RFC 822 address which can be mapped in Mail-11 using the 'f- address' field, as described in section 6.2. an example: C=gb; ADMD=Gold 400; PRMD=AC.UK; O=UCL; OU=cs; G=Paul; S=Smith; maps accordingly to RFC1148 to Paul.Smith@cs.UCL.AC.UK and finally becomes SMTPGW::In%"Paul.Smith@cs.UCL.AC.UK" where 'SMTPGW' is the DECnet node name of the machine running the RFC 822 to Mail-11 gateway. 6.4.2. Mail-11 --> RFC 822 --> X.400 Some of the possible mapping described in section 6.3 apply to the Mail-11 address, hiding completely its origin. The RFC1148 apply on the last step. an example: RELAY::MYNODE::BETTY could map into RFC 822 as BETTY%MYNODE@RELAY.dnet.gw1.it and accordingly to RFC1148 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 RFC 822 gateway. 6.4.3. X.400 --> Mail-11 --> RFC 822 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 RFC 822 gateway is able to understand the presence of a 'x400-text- address' into the Mail-11 address, then it applies RFC1148 to it, and encodes 'route' and 'node' as 'Received:' elements into RFC 822 message 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=Paul; S=Smith; will be encoded like X4TDEC::gw%"/C=gb/A=Gold 400/P=AC.UK/O=UCL/OU=cs/G=Paul/S=Smith" If the Mail-11 to RFC 822 gateway recognise the x400-text- address, then the address becomes, accordingly to RFC1148 Paul.Smith@cs.UCL.AC.UK and the following RFC 822 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=Paul/S=Smith"@X4TDEC.domains 6.4.4. RFC 822 --> Mail-11 --> X.400 The RFC 822 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 'rfc822-address' into the Mail-11 address, then it applies RFC1148 to it, and encodes 'route' and 'node' as 'trace' elements of the message header. Otherwise it applies the rules described in 5.2 and 5.5. an example: Paul.Smith@cs.UCL.AC.UK will be encoded like SMTPGW::In%"Paul.Smith@cs.UCL.AC.UK" If the Mail-11 to X.400 gateway recognise the rfc822-address, then the address becomes, accordingly to RFC1148 C=gb; ADMD=Gold 400; PRMD=AC.UK; O=UCL; OU=cs; G=Paul; S=Smith; 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)Paul.Smith(a)cs.UCL.AC.UK(q) 6.4.5. RFC 822 --> X.400 --> Mail-11 We apply RFC1148 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 'local part'. an example: Paul.Smith@cs.UCL.AC.UK maps accordingly to RFC1148 to C=gb; ADMD=Gold 400; PRMD=AC.UK; O=UCL; OU=cs; G=Paul; S=Smith; and finally becomes SMTPGW::gw%"/C=gb/A=Gold 400/P=AC.UK/O=UCL/OU=cs/G=Paul/S=Smith" where 'SMTPGW' is the DECnet node name of the machine running the X.400 to Mail-11 gateway. 6.4.6. Mail-11 --> X.400 --> RFC 822 The Mail-11 address is encoded as specified in sections 5.2 and 5.5; then RFC1148 is used to convert the address in RFC822. 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 RFC1148 "/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 RFC1148 gateway. Acknowledgements I wish to thank all those people which read the first draft and contributed a lot with their useful suggestions to the revision of this document, in particular RARE WG1 members and S. Hardcastle-Kille. References CCITT, "CCITT Recommendations X.400-X.430," Message Handling Systems: Red Book, October 1984 CCITT, "CCITT Recommendations X.400-X.420," Message Handling Systems: Blue Book, November 1988 D.H. Crocker, "Standard of the Format of ARPA Internet Text Messages," RFC 822, August 1982. S.E. Kille, "Mapping Between X.400 and RFC 822," UK Academic Community Report (MG.19) / RFC 987, June 1986. S.E. Kille, "Mapping Between X.400(1988) / ISO 10021 and RFC 822," RFC 1148, March 1990. Digital Equipment Corp.;, "VAX/VMS Mail Utility" Joiner Associates Inc., "Jnet User's Manual" PMDF User's Guide.