This document is obsolete. Please
refer to RFC 2162.
Network Working Group C. Allocchio Request for Comments: 1405 I.N.F.N. - Italy January 1993
Mapping between X.400(1984/1988) and Mail-11 (DECnet mail)
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 / RFC822 / 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 RFC 1327 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.
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.
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
Allocchio [Page 1]
RFC 1405 Mail-11 Mapping January 1993
among systems implementing the DECnet Phase IV networking protocols.
RFC822 was defined as a standard for personal messaging systems within the DARPA Internet and is now diffused on top of many different message transfer protocols, like SMTP, UUCP, BITNET, JNT Grey Book, CSnet. Its mapping with X.400 is fully described in RFC1327. In this document we will try to consider its relations with Mail-11, too.
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 RFC822 based system.
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 RFC822 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
Allocchio [Page 2]
RFC 1405 Mail-11 Mapping January 1993
specified in RFC1327 and their updates will be used, producing an RFC822-like header.
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 RFC822-like text header in Mail-11 body part will be interpreted as specified into RFC1327 and its updates.
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'
Allocchio [Page 3]
RFC 1405 Mail-11 Mapping January 1993
- 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 RFC1327 including the mapped element into the RFC822-like header into Mail-11 body part.
Chapter 3 - Basic Mappings
The basic mappings indicated in RFC1327 and its updates should be fully used.
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.
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 RFC1327.
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., common X.400 and/or RFC822 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
Allocchio [Page 6]
RFC 1405 Mail-11 Mapping January 1993
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 RFC1327. An example:
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.
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
Allocchio [Page 7]
RFC 1405 Mail-11 Mapping January 1993
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 section 6.4.3;
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).
(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:
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
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 RFC1327, and including this as 'f-address'. A 'f-pref' and a the DECnet node name of the gateway.
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 section 5.2 apply:
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.
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).
The bilateral mappings described in chapter 5 must be extended in order to cover also the case in which also RFC822 addressing is involved, and the following triangular situation occurs:
The X.400 - RFC822 side is fully covered by RFC1327, 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 - RFC822 side. The most important among these de facto standards are discussed in Appendix A, jointly with a Mail-11 - RFC822 mapping scheme which covers this side of the triangle.
There are different styles in mapping a Mail-11 address in RFC822; let's have a short summary.
- Mail-11 address encoded in "Left Hand Side" (LHS) of RFC822 address, using "%" syntax or "::" syntax;
route::node::localpart
Allocchio [Page 12]
RFC 1405 Mail-11 Mapping January 1993
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.
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.
We apply the RFC1327 rules to the first step, obtaining an RFC822 address which can be mapped in Mail-11 using the 'f-address' field, as described in section 6.2.
The X.400 address is stored into Mail-11 'f-address' element as described in sections 5.3 and 5.4; then if the Mail-11 to RFC822 gateway is able to understand the presence of a 'x400-text-address' into the Mail-11 address, then it applies RFC1327 to it, and encodes header. Otherwise it applies the rules described in 6.3
The RFC822 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 RFC1327 to it, and encodes 'route' and applies the rules described in 5.2 and 5.5.
an example:
Jim.Clay@cs.UCL.AC.UK
will be encoded like
SMTPGW::In%"Jim.Clay@cs.UCL.AC.UK"
If the Mail-11 to X.400 gateway recognise the RFC822-address, then the address becomes, accordingly to RFC1327
We apply RFC1327 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
The implementation of a Mail-11 - RFC822 gateway was faced by many software developers independently, and was included in many mail products which were running on both 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 RFC822 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 RFC822, having complex ones producing all sort of quite strange results.
Allocchio [Page 16]
RFC 1405 Mail-11 Mapping January 1993
On the other hand, the mapping of an RFC822 address in Mail-11 was quite straightforward, resulting in a common definition which uses "Mail-11 foreign mail protocol" to design an RFC822 address:
A considerable number of de-facto implementations of Mail-11/RFC822 gateways is existing. As said in the introduction, the mapping of RFC822 addresses in Mail-11 is accomplished using the foreign mail protocol syntax and is thus unique.
On the other hand, Mail-11 addresses are encoded in RFC822 syntax in various ways. Here are the most common ones:
a) "node::user"@gateway-address b) user%node@gateway-address c) user@node.decnet.domains d) user%node.dnet@gateway-address
Let's have a quick look to these different choices.
a - This form simply encloses as quoted Left Hand Side string the original Mail-11 address into the RFC822 address of the Mail-11/RFC822 gateway. This method is fully conformant with RFC822 syntax, and the Mail-11 address is left untouched; thus no encoding rules need to applied to it.
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.
Allocchio [Page 17]
RFC 1405 Mail-11 Mapping January 1993
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.
RFC822 foresee a canonical form for representing non-RFC822 addresses: put the foreign address in local part (Left Hand Side, LHS) is a form as similar as possible to its original syntax. Thus the suggested mapping is:
"Mail-11-address"@gateway-address
This format assures also the return path via the appropriate gateway.
A standard way of mapping Mail-11 addresses into RFC822 and vice versa is feasible. A suggestion is thus made to unify all existing and future implementations. It should be noted, however, that 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.
Allocchio [Page 18]
RFC 1405 Mail-11 Mapping January 1993
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
[1] CCITT, "CCITT Recommendations X.400-X.430", Message Handling Systems: Red Book, October 1984.
[2] CCITT, "CCITT Recommendations X.400-X.420", Message Handling Systems: Blue Book, November 1988.
[3] Crocker, D., "Standard of the Format of ARPA Internet Text Messages", STD 11, RFC 822, UDel, August 1982.
[4] Kille, S., "Mapping Between X.400 and RFC 822", UK Academic Community Report (MG.19) / RFC 987, June 1986.
[5] Kille, S., "Mapping Between X.400(1988) / ISO 10021 and RFC 822", RFC 1327, March 1992.
[6] Digital Equipment Corp.;, "VAX/VMS Mail Utility".
[7] Joiner Associates Inc., "Jnet User's Manual".
[8] 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