Internet DRAFT - draft-ietf-x400ops-mapsmail
draft-ietf-x400ops-mapsmail
HTTP/1.1 200 OK
Date: Tue, 09 Apr 2002 09:09:39 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Wed, 09 Dec 1992 04:39:00 GMT
ETag: "3dde41-8b86-2b257864"
Accept-Ranges: bytes
Content-Length: 35718
Connection: close
Content-Type: text/plain
COSINE S2.2 Claudio Allocchio
Draft v2.3 I.N.F.N. - Italy
August 22, 1992
Allocchio@elettra.trieste.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
RFC1327 and its updates.
This document provides an experimental standard definition, and
is expected to be revised after an initial test period.
Distribution is unlimited.
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted
by other documents at any time. It is not appropriate to use
Internet Drafts as reference material or to cite them other than
as a "working draft" or "work in progress."
Please check the I-D abstract listing contained in each Internet
Draft directory to learn the current status of this or any other
Internet Draft.
Document Expiration Date
This document was submitted on September 23rd, 1992 and its
validity will expire on March 23rd 1993.
(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
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.
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).
The se 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 RFC1327 and
their updates will be used, producing an RFC822-like header.
2.2. Mail-11 service elements
All envelope (P1) and header (P2) Mail-11 service
elements are supported in the conversion to X.400. Note that
Mail-11 P1 is solely composed by P1.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.
2.3. X.400 service elements
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'
- 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.
- the new message is delivered separately.
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.
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 RFC1327.
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 = <printablestring - <" " and HTAB>>
for-protocol = (f-pref f-sep <">f-address<">)
f-pref = *(ALPHA/DIGIT)
f-sep = "%" / "::"
f-address = printablestring / rfc822-address / X400-text-address
X400-text-address = <textual representation of an X.400 O/R addr>
Please note that in 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. 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' attribute. 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.
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:
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 '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 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;
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 RFC1327, 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 dividing 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 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 - RFC 822 side. The most important
among these de facto standards are discussed in Appendix A,
jointly with a Mail-11 - RFC 822 mapping scheme which covers
this side of the triangle.
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
or 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 RFC1327 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 RFC1327 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
RFC1327 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 RFC1327
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 RFC1327 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 RFC822 gateway recognise the x400-text-address,
then the address becomes, accordingly to RFC1327
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
RFC1327 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 RFC1327
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 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 'local part'.
an example:
Paul.Smith@cs.UCL.AC.UK
maps accordingly to RFC1327 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 RFC1327 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 RFC1327
"/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 RFC1327
gateway.
Appendix A Mail-11 - RFC 822 mapping
A.1 Introduction
The implementation of a Mail-11 - RFC 822 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
RFC 822 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
RFC 822, having complex ones producing all sort of quite strange
results.
On the other hand, the mapping of an RFC 822 address in
Mail-11 was quite straightforward, resulting in a common
definition which uses "Mail-11 foreign mail protocol" to design
an RFC 822 address:
[[node::][node::]...]prot%"rfc-822-address"
or
[node::][node::]...]::"rfc-822-address"
A.2 De-facto implementations
A considerable number of de-facto implementations of
Mail-11 / RFC822 gateways is existing. As said in the
introduction, the mapping of RFC 822 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 RFC 822
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 RFC 822 address of the
Mail-11 / RFC822 gateway. This method is fully conformant with
RFC 822 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.
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.
A.3 Recommended mappings
From the examples seen in the previous paragraphs we
can derive a canonical form for representing the mapping between
Mail-11 and RFC822.
A3.1 RFC822 mapped in Mail-11
The mapping of an RFC 822 address in Mail-11 is
straightforward, using the "Mail-11 foreign mail protocol"
syntax. The two possible variants are:
[[node::][node::]...]prot%"rfc-822-address"
or
[node::][node::]...]::"rfc-822-address"
A3.2 Mail-11 mapped in RFC822
RFC822 foresee a canonical form for representing
non-RFC822 addresses: put the foreign address in local part
(Left Hand Side, LHS) is a form as similar as possible to its
original syntax. Thus the suggested mapping is:
"Mail-11-address"@gateway-address
This format assures also the return path via the appropriate
gateway.
A.4 Conclusions
A standard way of mapping Mail-11 addresses into
RFC 822 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.
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 and IETF X.400
ops group members and S. Hardcastle-Kille.
Author's address
Claudio Allocchio Phone: +39 40 3758523
Cosine S2.2 Fax: +30 49 226338
Sincrotrone Trieste e-mail: allocchio@elettra.trieste.it
c/o Area di Ricerca
Padriciano 99
I 34012 Trieste (TS)
Italy
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 1327, March 1992.
Digital Equipment Corp.;, "VAX/VMS Mail Utility"
Joiner Associates Inc., "Jnet User's Manual"
PMDF User's Guide.
Document Expiration Date
This document was submitted on September 23rd, 1992 and its
validity will expire on March 23rd 1993.
