mail-11 / rfc822 / x.400 mappings - v2.2 (01 Jul 1992)

[[e-mail]]

Hallo, here is the updated version of my document. As only a few points where 
changed I added change bars to facilitate reading. Appendix A is completely new.
See you all i Boston, Claudio
---------------------------------------

COSINE S2.2					Claudio Allocchio
Draft v2.2						I.N.F.N. - Italy
							March 2nd, 1992
							[e-mail]


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.

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 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).

	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 RFC1327 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 RFC1327 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
|		to ensure the required privacy, when a message contains a BCC
|		address, the following actions occures:
|		- a new message is created, containing the bodyparts;
|		- 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 RFC987, RFC1148, RFC1327 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 
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%"[e-mail]"
        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 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 
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 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 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 importants 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%"[e-mail]"


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

     [e-mail]-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 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

   [e-mail]

and finally becomes

   SMTPGW::In%"[e-mail]"

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

   [e-mail]

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 RFC 822 gateway recognise the x400-text-address, then
the address becomes, accordingly to RFC1327

   [e-mail]

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:

   [e-mail]

will be encoded like

   SMTPGW::In%"[e-mail]"

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:

   [e-mail]

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 developpers indipendently, 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 standardization 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 mappend 
into RFC 822, having complex ones producing all sort of quite strange results.

	On the other hand, the mappig 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 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) [e-mail]
	d) user%node.dnet@gateway-address

As one will immediately notice, the form b) has nothing in it indicating the 
address 
is a Mail-11 one; this makes the encoding indistiguishable from a similar 
encoding 
of RSCS (BITne) addresses used by some IBM VM Mailer systems. It should thus 
be deprecated. All other forms correspond to existing implementations, and it is 
possible to identify the original Mail-11 address from the RFC822 one.

However we should forsee a canonical form for representing non-RFC822 
addresses in RFC822: put the foreign address in local part (Left Hand Side, LHS) 
is 
a form as similar as possible to its original syntax. Thus form a) is the 
reccomended 
one.

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.


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 1990.

  Digital Equipment Corp.;, "VAX/VMS Mail Utility"

  Joiner Associates Inc., "Jnet User's Manual"

  PMDF User's Guide.