GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc1405

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.

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

Allocchio [Page 1] RFC 1405 Mail-11 Mapping January 1993

 among systems implementing the DECnet Phase IV networking protocols.

1.3. RFC822

 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.

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

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:
  1. P1.From

maps to P1.Originator

  1. P1.To

maps to P1.Primary Recipient

  1. P2.From

maps to P2.Originator

  1. P2.To

maps to P2.Primary Recipient

  1. Cc

maps to P2.Copy Recipient

  1. Date

maps to Submission Time Stamp

  1. 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:
  1. P1.Originator

maps to P1.'From'

  1. P1.Primary Recipients

maps to P1.'To'

  1. P2.Originator

maps to P2.'From'

Allocchio [Page 3] RFC 1405 Mail-11 Mapping January 1993

  1. P2.Primary Recipients

maps to P2.'To'

  1. Copy Recipients

maps to 'Cc'

  1. Submission Time Stamp

maps to 'date'

  1. Subject

maps to 'Subj'

 The following X.400 service element is partially supported into
 Mail-11 conversion:
  1. 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.

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.

Allocchio [Page 4] RFC 1405 Mail-11 Mapping January 1993

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

Allocchio [Page 5] RFC 1405 Mail-11 Mapping January 1993

 Some examples:
    route           node    local-part
    -----------------------------------------------------------
                            USER47
                    MYNODE::BETTY
    BOSTON::CLUS02::GOOFY1::MARY34
                            IN%"M.P.Tracy@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"
                            smtp%"postmast@nodeb.bitnet"
            MICKEY::PRFGAT::profs%"NANCY@IBMB"
                            edu%"HU427BD%CSUNIB@abc.acme.edu"

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.,
 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:
      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
 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

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

Allocchio [Page 8] RFC 1405 Mail-11 Mapping January 1993

  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:
  1. 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
  1. 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

Allocchio [Page 9] RFC 1405 Mail-11 Mapping January 1993

   within the X.400 MHS).
   C=it; ADMD=garr; DD.Dnet=HEP;
   DD.Mail-11=X4TDEC::MRGATE::(q)C=ab::A=dsa::P=qwty::OU=mie::S=Cly(q)
     MRGATE::"C=ab::A=dsa::P=qwty::OU=mie::S=Cly"
   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 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=Jim; S=Clay;
 will be encoded like
  X4TDEC::gw%"/C=gb/A=Gold 400/P=AC.UK/O=ucl/OU=cs/G=Jim/S=Clay"
 or its equivalent with the ";" notation
  X4TDEC::gw%"C=gb;ADMD=Gold 400;PRMD=AC.UK;O=ucl;OU=cs;G=Jim;S=Clay;"

Allocchio [Page 10] RFC 1405 Mail-11 Mapping January 1993

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
 informations. In order to assure path reversibility we must then
 distinguish two cases:
  1. 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.
  1. 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;

Allocchio [Page 11] RFC 1405 Mail-11 Mapping January 1993

   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 RFC822 addressing is
 involved, and the following triangular situation occurs:
                                 x.400
                                 /  \
                                /    \
                               /      \
                           Mail-11----RFC822
 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.

6.2. RFC822 mapped in Mail-11

 The 'RFC822-address' is usually included in 'local-part' as
      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 RFC822;
 let's have a short summary.
  1. 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.
  1. Mail-11 address maps partly to LHS and partly to 'domain' part of

RFC822 address:

      node::localpart
 maps to
      localpart@node.gw-domains
  1. 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 –> RFC822 –> Mail-11

 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.
 an example:
    C=gb; ADMD=Gold 400; PRMD=AC.UK; O=UCL; OU=cs; G=Jim; S=Clay;
 maps accordingly to RFC1327 to
    Jim.Clay@cs.UCL.AC.UK

Allocchio [Page 13] RFC 1405 Mail-11 Mapping January 1993

 and finally becomes
    SMTPGW::In%"Jim.Clay@cs.UCL.AC.UK"
 where 'SMTPGW' is the DECnet node name of the machine running the
 RFC822 to Mail-11 gateway.

6.4.2. Mail-11 –> RFC822 –> 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 RFC822 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 RFC822 gateway.

6.4.3. X.400 –> Mail-11 –> RFC822

 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
 an example:
   C=gb; ADMD=Gold 400; PRMD=AC.UK; O=UCL; OU=cs; G=Jim; S=Clay;
 will be encoded like
   X4TDEC::gw%"/C=gb/A=Gold 400/P=AC.UK/O=UCL/OU=cs/G=Jim/S=Clay"
 If the Mail-11 to RFC822 gateway recognise the x400-text-address,
 then the address becomes, accordingly to RFC1327
   Jim.Clay@cs.UCL.AC.UK

Allocchio [Page 14] RFC 1405 Mail-11 Mapping January 1993

 and the following RFC822 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=Jim/S=Clay"@X4TDEC.doms

6.4.4. RFC822 –> Mail-11 –> X.400

 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
    C=gb; ADMD=Gold 400; PRMD=AC.UK; O=UCL; OU=cs; G=Jim; S=Clay;
 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)Jim.Clay(a)cs.UCL.AC.UK(q)

6.4.5. RFC822 –> 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
 an example:
    Jim.Clay@cs.UCL.AC.UK
 maps accordingly to RFC1327 to

Allocchio [Page 15] RFC 1405 Mail-11 Mapping January 1993

    C=gb; ADMD=Gold 400; PRMD=AC.UK; O=UCL; OU=cs; G=Jim; S=Clay;
 and finally becomes
    SMTPGW::gw%"/C=gb/A=Gold 400/P=AC.UK/O=UCL/OU=cs/G=Jim/S=Clay"
 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 –> RFC822

 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 - RFC822 mapping

A.1 Introduction

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

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 RFC822 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 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
 Phone:   +39 40 3758523
 Fax:     +39 40 226338
 EMail:  Claudio.Allocchio@elettra.Trieste.it
         C=it; A=garr; P=Trieste; O=Elettra; S=Allocchio; G=Claudio;

Allocchio [Page 19]

/data/webs/external/dokuwiki/data/pages/rfc/rfc1405.txt · Last modified: 1993/01/20 01:09 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki