summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1405.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1405.txt')
-rw-r--r--doc/rfc/rfc1405.txt1067
1 files changed, 1067 insertions, 0 deletions
diff --git a/doc/rfc/rfc1405.txt b/doc/rfc/rfc1405.txt
new file mode 100644
index 0000000..286803b
--- /dev/null
+++ b/doc/rfc/rfc1405.txt
@@ -0,0 +1,1067 @@
+
+
+
+
+
+
+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:
+
+ - 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'
+
+
+
+
+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.
+
+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:
+
+ - 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
+
+
+
+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:
+
+ - 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;
+
+
+
+
+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.
+
+ - 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.
+
+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]
+ \ No newline at end of file