From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc2162.txt | 1907 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1907 insertions(+) create mode 100644 doc/rfc/rfc2162.txt (limited to 'doc/rfc/rfc2162.txt') diff --git a/doc/rfc/rfc2162.txt b/doc/rfc/rfc2162.txt new file mode 100644 index 0000000..c205cc6 --- /dev/null +++ b/doc/rfc/rfc2162.txt @@ -0,0 +1,1907 @@ + + + + + + +Network Working Group C. Allocchio +Request for Comments: 2162 I.N.F.N. - Italy +Obsoletes: 1405 January 1998 +Category: Experimental + + + MaXIM-11 - Mapping between X.400 / Internet mail + and + Mail-11 mail + +Status of this Memo + + This memo defines an Experimental Protocol for the Internet + community. It does not specify an Internet standard of any kind. + Discussion and suggestions for improvement are requested. + Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (1998). All Rights Reserved. + +Abstract + + This document describes a set of mappings which will enable inter + working between systems operating the ISO/IEC 10021 - CCITT (now ITU) + X.400 Recommendations on Message Handling Systems, and systems + running the Mail-11 (also known as DECnet mail or VMSmail) protocol. + The specifications are valid both within DECnet Phase IV and + DECnet/OSI addressing and routing scheme. + + The complete scenario of X.400 / MIME / Mail-11 is also considered, + in order to cover the possible complex cases arising in multiple + gateway translations. + + This document covers mainly the X.400 O/R address to/from Mail-11 + address mapping and the RFC822 to/from Mail-11 ones; other mappings + are based on MIXER specifications. Bodypart mappings are not + specified in this document: MIXER and MIME-MHS specifications can be + applied to map bodyparts between X.400, MIME and Mail-11, too. In + fact MIME encoding can be used without modifications within Mail-11 + text bodyparts. + + This document obsoletes RFC 1405, which was a combined effort of + TERENA Working Group on Messaging, and the IETF X.400 Ops Working + Group. This update was prepared by IETF MIXER working group. + + + + + + +Allocchio Experimental [Page 1] + +RFC 2162 MaXIM-11 January 1998 + + +Chapter 1 - Introduction + +1.1. X.400 + + The standard referred shortly into this document as "X.400" relates + to the ISO/IEC 10021 - CCITT 1984, 1988 and 1992 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 and DECnet/OSI (CLNS) + networking protocols. + +1.3. RFC822 / MIME + + 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. MIME specifications allows transport of non-textual + information into RFC822 messages. Their mapping with X.400 is fully + described in MIXER and MIME-MHS. In this document we will consider + their relations with Mail-11, too. + +1.4. The user community + + The community using MIME or 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 and with + MIME based systems. Among these large DECnet based networks we can + include the High Energy Physics network (HEPnet) and the Space + Physics Analysis Network (SPAN). + + Many other local communities actively use internally Mail-11 mailing + protocols. As any other "non standard" mail protocol, using non + standard mapping techniques between Mail-11 and standard mail systems + can produce unpredictable results. + + For these reasons a set of rules covering conversion between Mail-11 + and X.400 or MIME is described in this document. + + + + + + +Allocchio Experimental [Page 2] + +RFC 2162 MaXIM-11 January 1998 + + + 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 and RFC822/MIME + specifications support a complex and large amount of service + elements. Considering the case where a message is relayed between + two X.400 MHS or MIME Message Transport System (MTS) via a Mail-11 + messaging system this could result in a nearly complete loss of + information. + + To minimise the inconvenience, any of the X.400 or MIME service + elements which do not map directly into Mail-11 equivalent ones + accordingly to this specification, will be included into Mail-11 text + body parts as an additional RFC822-like header; this additional + header will be inserted between the Mail-11 P2 headers (From:, To:, + CC:, Subj:) and the other Mail-11 bodyparts. In particular, X.400 + elements will also be at first converted into textual representation + before insertion. + + An example, where a multimedia message has been encoded into mail-11 + after having crossed also a MIME-MHS (MIXER conformant) gateway: + + From: smtp%"Admin@SURFnet.nl" "Erik" 18-OCT-1994 13:55:00.49 + To: ALLOCCHIO + CC: smtp%"netman@MailFLOW.dante.net" + Subj: enjoy this nice picture! + + X400-Originator: root@sun3.SURFnet.nl + X400-Recipients: Allocchio@elettra.ts.it, netman@MailFLOW.dante.net + Sender: Erik Newmann + Organisation: SURFnet bv + Mime-Version: 1.0 + Content-Type: multipart/mixed; boundary="----- =_aaaaaa0" + Content-ID: <21223.78342785@SURFnet.nl> + + ------- =_aaaaaa0 + Content-Type: text/plain; charset="us-ascii" + Content-ID: <21223.78342785@SURFnet.nl> + + look... you never saw this one!! + I just include the picture in the next bodypart + and I hope you get it fine. + + + +Allocchio Experimental [Page 3] + +RFC 2162 MaXIM-11 January 1998 + + + regards, + + Erik (continues...) + + ------- =_aaaaaa0 (continued...) + Content-Type: image/gif + Content-ID: <21223.78342785@SURFnet.nl> + Content-Description: a nice snapshot! + Content-Transfer-Encoding: base64 + + RAV8372FAASD83D721NSHDHD3ASDFJKHWEHKJHCBASDFA829CA8SDB29B132RBAKDFA + 9KSJ2KJAA0SDFNAL20DDKFALJ20AJDLFB239B9SC9B29BA9BDFADSDF03998ASDFASD + + ------- =_aaaaaa0 + + We need, in fact, to consider also the case when a message originates + from a network implementing RFC822/MIME protocols and is relayed via + Mail-11 to an X.400 MHS, or vice versa. + + Whenever any X.400 element not covered in this specification needs to + be converted into textual representation (to be included into a + Mail-11 RFC822-like header or text bodypart) we will apply the rules + specified in MIXER (X.400 to RFC822/MIME sections). + + Vice versa, MIXER specification (RFC822/MIME to X.400 sections) also + gives the correct rules to convert from textual representations + contained into Mail-11 RFC822-like header or bodyparts into X.400 + elements. + + On the other hand, RFC822/MIME headers not covered by this + specification are included 'as they are' into Mail-11 RFC822-like + header and bodyparts. The way back from Mail-11 to RFC822/MIME + structure becomes thus straightforward. + + The above methods assures maximum transparency and minimal or null + loss of information also when Mail-11 is involved. + + + + + + + + + + + + + + + +Allocchio Experimental [Page 4] + +RFC 2162 MaXIM-11 January 1998 + + +2.2. Mail-11 service elements to X.400 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-11.From and P1-11.To, and any other Mail-11 element + belongs to Mail-11 P2: + + - P1-11.From + maps to P1.Originator + + - P1-11.To + maps to P1.Primary Recipient + + - P2-11.'From:' + usually maps to P2.Originator (see section 2.6) + + - P2-11.'To:' + maps to P2.Primary Recipient + + - P2-11.'CC:' + maps to P2.Copy Recipient + + - P2-11.Date + maps to P2.Submission Time Stamp + + - P2-11.'Subj:' + maps to P2.Subject + + Any eventual RFC822-like text header in Mail-11 body part will be + interpreted as specified into MIXER. + +2.3. X.400 service elements to Mail-11 service elements + + The following X.400 service elements are supported directly into + Mail-11 conversion: + + - P1.Originator + maps to P1-11.'From:' + + - P1.Primary Recipients + maps to P1-11.'To:' + + - P2.Originator + usually maps to P2-11.'From:' (see section 2.6) + + - P2.Primary Recipients + maps to P2-11.'To:' + + + + +Allocchio Experimental [Page 5] + +RFC 2162 MaXIM-11 January 1998 + + + - P2.Copy Recipients + maps to P2-11.'CC:' + + - P2.Submission Time Stamp + maps to P2-11.Date + + - P2.Subject + maps to P2-11.'Subj:' + + The following X.400 service element is partially supported into + Mail-11 conversion: + + - P2.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 MIXER + including the mapped element into the RFC822-like header into Mail-11 + body part. + +2.4. Mail-11 service elements to RFC822/MIME service elements. + + All envelope (P1) and header (P2) Mail-11 service elements are + supported in the conversion to RFC822/MIME: + + - P1-11.From + maps to 822-MTS.Originator + + - P1-11.To + maps to 822-MTS.Primary Recipient + + - P2-11.'From:' + usually maps to 822.'From:' (see section 2.6) + + - P2-11.'To:' + maps to 822.'To:' + + - P2-11.'CC:' + maps to 822.'Cc:' + + + +Allocchio Experimental [Page 6] + +RFC 2162 MaXIM-11 January 1998 + + + - P2-11.Date + maps to 822.'Date:' + + - P2-11.'Subj:' + maps to 822.'Subject:' + + Any eventual RFC822-like text header in Mail-11 body part will be + re-inserted into RFC822/MIME message 'as it is'. + +2.5. RFC822/MIME service elements to Mail-11 service elements + + The following RFC822 service elements are supported directly into + Mail-11 conversion: + + - 822-MTS.Originator + maps to P1-11.From + + - 822-MTS.Primary Recipients + maps to P1-11.To + + - 822.'From:' + usually maps to P2-11.'From:' (see section 2.5) + + - 822.'To:' + maps to P2-11.'To:' + + - 822.'Cc:' + maps to P2-11.'CC:' + + - 822.'Date:' + maps to P2-11.Date + + - 822.'Subject:' + maps to P2-11.'Subj:' + + + + + + + + + + + + + + + + + +Allocchio Experimental [Page 7] + +RFC 2162 MaXIM-11 January 1998 + + + The following RFC822 service element is partially supported into + Mail-11 conversion: + + - 822.'Bcc:' + 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 RFC822/MIME service element support is done simply + including the element 'as it is' into the RFC822-like header and into + a Mail-11 body part. + +2.6. Rules to define the Mail-11 P2-11.'From:' element + + Mail-11 User Agents (usually VMSmail) uses the P2-11.'From:' element + as destination in case the REPLY command is issued, ignoring any + other specification like 'Sender:' 'Reply-To:' 'Return-Path:' etc. + Also a number of automatic responders uses this field only to address + their messages. + + Is it thus essential to insert into this field the correct + information, i.e. the correct address where, according to X.400 or + RFC822 rules the REPLY command or any automatically generated message + should go. + + The rules specified in RFC822, section 4.4.4 should be used as a + selection criterion to define the content of this field. + + In particular, in case the P2-11.'From:' element is not generated + from the P2.Originator (X.400) or from the 822.'From:' (RFC822), it + is essential to preserve into a 'From:' record of the RFC822-like + header the original information contained into the P2.Originator or + 822.'From:' fields. + + + + + + + + + + +Allocchio Experimental [Page 8] + +RFC 2162 MaXIM-11 January 1998 + + + Vice versa, when converting from Mail-11 into X.400 or RFC822/MIME + the information contained into the 'From:' field of the RFC822-like + header (if present) will supersede the one contained into the Mail-11 + P2-11.'From:'. An example: + + From: smtp%"Admin@SURFnet.nl" "Erik" 18-OCT-1994 13:55:00.49 + To: ALLOCCHIO + CC: smtp%"netman@MailFLOW.dante.net" + Subj: enjoy this nice picture! + + From: Erik Newmann + Reply-To: Admin@SURFnet.nl + Organisation: SURFnet bv + Message-Id: <21235.25442281@SURFnet.nl> + + when converting back into RFC822 the header will be: + + From: Erik Newmann + Reply-To: Admin@SURFnet.nl + To: Allocchio@elettra.ts.it + Cc: netman@MailFLOW.dante.net + Subject: enjoy this nice picture! + Organisation: SURFnet bv + Message-Id: <21235.25442281@SURFnet.nl> + + The described method, although violating canonical conversion + principles, assures the maximum functionality to the users, and + provides consistency in case of multiple conversions for a single + message. + +Chapter 3 - Basic Mappings + + The basic mappings indicated in MIXER and its updates should be fully + used. + + A special consideration must be used for encoding RFC822 addresses + containing quotes '"' into Mail-11. In fact Mail-11 addresses cannot + contain that special character, as it is reserved to delimit "quoted + strings" themselves, as when using the Mail-11 foreign mail protocol. + An example: + + "John Poe"@Mixergw.local.ca.us (RFC822) + + cannot be included in a Mail-11 foreign mail protocol address 'as + is', due to the quotes in the LHS section. Quotes must thus be + encoded. MIXER specifies exactly how to encode quotes and other + characters when translating RFC822 addresses into X.400. Mail-11 + addresses are not limited to printablestring, as for X.400, but a + + + +Allocchio Experimental [Page 9] + +RFC 2162 MaXIM-11 January 1998 + + + subset of the MIXER encoding can be used for the quotes character, + and, as a direct consequence, for open and closed round brackets '(' + and ')': + + smtp%"(q)John Poe(q)@Mixergw.local.ca.us" + +Chapter 4 - Addressing - Mail-11 / X.400 + +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 RFC1685 and CCITT F.401, Annex B. + +4.3. Mail-11 address components + + Let us start defining the different parts composing a Mail-11 + address. Mail-11 addresses syntax is slightly different between Phase + IV and DECnet/OSI cases: + + - Phase IV: we consider a Mail-11 address as composed by 3 parts: + + [route] [node::] local-part + + where 'route' and 'node' are optional and only 'local-part' is + compulsory. + + - DECnet/OSI: we consider a Mail-11 address as composed by 3 parts: + + [net:] [node-clns::] local-part + + where 'net and 'node-clns' are optional and only 'local-part' is + compulsory. + + Here comes a formal definition of these elements + + node = *(ALPHA/DIGIT) / *DIGIT / *DIGIT "." *DIGIT + + route = *(node "::") + + subdomain = *(ALPHA/DIGIT) + + + +Allocchio Experimental [Page 10] + +RFC 2162 MaXIM-11 January 1998 + + + node-clns = *("." subdomain) + + net = *(ALPHA/DIGIT) + + local-part = username / nickname / for-protocol + + username = *(ALPHA/DIGIT) + + nickname = > + + 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 = + + Please note that in x400-text-address both the ";" notation and the + "/" notation are equivalent and allowed (see examples in different + sect.) + + Some examples (Phase IV): + + 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" + + + + + + + + + +Allocchio Experimental [Page 11] + +RFC 2162 MaXIM-11 January 1998 + + + Some examples (DECnet/OSI): + + net node local-part + ----------------------------------------------------------- + USER47 + .IT.MYDOM1.MYNODE::BETTY + OMNI:.US.GOV.LB.GOOFY1::MARY34 + IN%"M.P.Tracy@Dicdum.cc.edu" + NET1:.SALES.ADM.MVAX93::MRGATE::"MBOX1::MBX34::MYC3::BOB" + .FR.LYON.MIAMI2::George.Rosenthal + .AU.ABXY2W.VS3100::Jnet%"IAB3425@IBAX23L" + MRGATE::"C=xx::A=bbb::P=ppp::S=Joe" + INT:.GB.3LABV56.MAINV::IN%"path1!path2!user%dom" + GWX400::gw%"C=xx;ADMD=aaa;PRMD=ppp;S=Lee;" + smtp%"postmast@nodeb.bitnet" + OMNI:.DE.TEST.V1.GWY32::GX409A::x400%"/C=xx/A=aaa/P=ppp/S=Lee" + + Note that also in DECnet/OSI there can be Phase IV like node names, + the so called "Phase IV compatibility node names", but no 'route' + term is allowed in front of them. In case the address consists of a + DECnet/OSI 'net' and/or 'node' specification, plus an old Phase IV + node address (like the last one in above examples) we consider the + old Phese IV node name (GX409A) as 'local-part'. + +Chapter 5 - Mapping - Mail-11 / X.400 + +5.1. Mapping scheme + + DECnet phase IV address field is somehow a 'flat land' with some + obliged routes to reach some hidden areas. Thus a truly hierarchical + mapping scheme using mapping rules as suitable for RFC822 is not the + appropriate solution. A fixed set of encoding rules using DDAs + support is defined in order to define the mapping. + + DECnet/OSI address field is, on the other hand, hyerarchical, + implementing a real domain style organization, resembling very + closely the RFC822 domain addresses. However also in DECnet/OSI + networks the old Phase IV flat addresing schema remains valid, + expecially for the so called 'Phase IV short aliases'. For this + reason, and to keep mapping as simple as possible, the same set of + fixed rules usind DDAs encoding will be used both for Phase IV and + DECnet/OSI addresses. + + + + + + + + + +Allocchio Experimental [Page 12] + +RFC 2162 MaXIM-11 January 1998 + + + Another important aspect of the problem is the coexistence in DECnet + phase IV of many disjoint 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. In DECnet/OSI this + aspect is more canonically approached, introducing the concept of + 'net', a unique name identifying the single internally fully + interconnected DECnet network sharing the same DECnet/OSI name space. + + To identify uniquely each DECnet Phase IV network we will thus extend + the concept of DECnet/OSI 'net' also to this case. We define as 'net' + in Phase IV a unique ASCII string identifying the DECnet network we + are connected to. If the Phase IV network is already migrating and + thus interconnected to DECnet/OSI areas, the 'net' identifier already + used in the DECnet/OSI areas is automatically extended to the whole + DECnet community. + + If the network still uses Phase IV protocols only, a 'net' identifier + must be chosen. In this case the 'net' element will identify the + DECnet community being served, but it could also differ from the + actual official network name. It is reccommended that the same 'net' + identifier will be adopted unmodified when the eventual migration to + DECnet/OSI will take place within that DECnet community. + + Aliases are allowed for the 'net' identifier. Some well known + identifiers and aliases: + + net = 'OMNI' the High Energy Physics & Space Physics + DECnet network; + + aliases: + + net = 'HEPnet' alias for 'OMNI' + net = 'SPAN' alias for 'OMNI' + + 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. + + + + + + + + + + + +Allocchio Experimental [Page 13] + +RFC 2162 MaXIM-11 January 1998 + + + A registry of 'net' attributes to insure uniqueness of names must be + established: this registry is the same one created for migration to + DECnet/OSI. A simple table coupling 'net' and the gateway address is + also used, in a syntax similar to the 'gate1' and 'gate2' tables used + in MIXER. An example: + + OMNI#OU$Cosine-gw.O$@.PRMD$infn.ADMD$garr.C$IT# + OMNI#O$ESRIN1.PRMD$esa.ADMD$Master400.C$it# + HEPnet#OU$Cosine-gw.O$@.PRMD$infn.ADMD$garr.C$IT# + HEPnet#O$ESRIN1.PRMD$esa.ADMD$Master400.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 the specified gateways, or try them all in + cyclic order to obtain better performances. + + Note that aliases are established using this gate table, too: simply + add equivalent entries into the table, like the 'HEPnet' and 'SPAN' + entries. Aliases, however, must be used only to enable users to use + commonly used names, but any gateway implementing this specification + must generate addresses with official 'net' names, only ('OMNI' for + the above table). + + The Mail-11 gateways table, however, just constitutes the list of the + the appropriate MIXER address translation) RFC822 world. Any other + gateway implementing this specification (and the related ones) should + use its local name as first choice for the Mail-11 'net' it can + reach, and use the official Mail-11 gateway table to reach only the + non connected ones. This list of Mail-11 gateway entries is supposed + to contain the list of 'net' tags and their aliases; as this list is + usually small, currently we do not take into account distribution + mechanisms for this information different from a static table. + + In order to keep the mapping rules very simple, avoiding the need to + analyse Mail-11 addresses to distinguish the 'route', 'node', and + Attributes (DDAs) 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 + + + + + + +Allocchio Experimental [Page 14] + +RFC 2162 MaXIM-11 January 1998 + + + We thus define the Mail-11 Phase IV 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; + + Meanwhile we define the mapping rule for Mail-11 DECnet/OSI: + + net:node-clns::localpart + + maps into + + C=xx; ADMD=yyy; PRMD=zzz; O=ooo; OU=uuu; DD.Dnet=net; + DD.Mail-11=node-clns::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., OMNI, 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' (or 'node-clns') is missing and we are mapping the Mail-11 + originator (From) then 'node' (or 'node-clns') defaults to the DECnet + node name of the gateway (gwnode); + + if 'node' (or 'node-clns') is missing and we are mapping the Mail-11 + recipient (To, Cc) then 'node' (or 'node-clns') defaults to the + DECnet node name of the 'From' address. + + if '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. + + + + +Allocchio Experimental [Page 15] + +RFC 2162 MaXIM-11 January 1998 + + + The 'node' syntax (DECnet/OSI or Phase IV) depends on the DECnet + protocol implemented and on the value of a system parameter (usually + the MAIL$SYSTEM_FLAGS one) on the gateway host. + + 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 'OMNI'; + - the DECnet node name of the gateway (gwnode) is '.IT.DM.X4TDEC' + alias 'X4TDEC' in Phase IV; + - 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=OMNI; DD.Mail-11=.IT.DM.X4TDEC::USER47; + + MYNODE::BETTY + C=it; ADMD=garr; DD.Dnet=OMNI; DD.Mail-11=MYNODE::BETTY; + + BOSTON::GOOFY1::MARY34 + C=it; ADMD=garr; DD.Dnet=OMNI; DD.Mail-11=BOSTON::GOOFY1::MARY34; + + .DE.UNI-BN.PHYS.NODE18::MARY34 + C=it; ADMD=garr; DD.Dnet=OMNI; + DD.Mail-11=.DE.UNI-BN.PHYS.NODE18::MARY34; + + UCLA13::MVAX93::MRGATE::"MBOX1::MBX34:MYC3::BOB" + C=it; ADMD=garr; DD.Dnet=OMNI; + DD.Mail-11=UCLA13::MVAX93::MRGATE::(q)MBOX1::MBX34::MYC3::BOB(q) + + ENET:.US.CENTRAL.MIAMI2::George.Rosenthal + C=it; ADMD=garr; DD.Dnet=ENET; + DD.Mail-11=.US.CENTRAL.MIAMI2::George.Rosenthal; + + MRGATE::"C=xx::A=bbb::P=ppp::S=Joe" + C=it; ADMD=garr; DD.Dnet=OMNI; + DD.Mail-11=X4TDEC::MRGATE::(q)C=xx::A=bbb::P=ppp::S=Joe(q) + + + + + + +Allocchio Experimental [Page 16] + +RFC 2162 MaXIM-11 January 1998 + + + MAINVX::In%"path1!path2!user%dom" + C=it; ADMD=garr; DD.Dnet=OMNI; + 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 + + and for DECnet/OSI addresses + + C=xx; ADMD=yyy; PRMD=zzz; O=ooo; OU=uuu; DD.Dnet=net; + DD.Mail-11=node-clns::localpart; + + maps into + + net:node-clns::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;" + + + + + + + + + + +Allocchio Experimental [Page 17] + +RFC 2162 MaXIM-11 January 1998 + + + Again for DECnet/OSI addresses: + + C=xx; ADMD=yyy; PRMD=www; DD.Dnet=net; + DD.Mail-11=node-clns::localpart; + + maps into + + gwnode::gw%"C=xx;ADMD=yyy;PRMD=www;DD.Dnet=net; + DD.Mail-11=node-clns::localpart;" + + +5.3.1. Examples + + Let us suppose that: + + - the DECnet network name (net) is 'OMNI'; + - the DECnet node name of the gateway (gwnode) is '.IT.DM.X4TDEC'; + alias 'X4TDEC' in Phase IV; + - 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=OMNI; + 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 .IT.DM.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 MIXER, and including this as 'f-address'. A 'f-pref' and a the + DECnet node name of the gateway. + + + + + + + + + + + +Allocchio Experimental [Page 18] + +RFC 2162 MaXIM-11 January 1998 + + + 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 '.IT.DM.X4TDEC' + alias 'X4TDEC' in Phase IV, and 'net' is 'OMNI' + + Thus + + C=gb; ADMD=G400; PRMD=AC.UK; O=ucl; S=Clay; + + will be encoded like + + X4TDEC::gw%"/C=gb/A=G400/P=AC.UK/O=ucl/S=Clay" + + or its equivalent with the ";" notation and DECnet/OSI 'node' + + OMNI:.IT.DM.X4TDEC::gw%"C=gb;ADMD=G400;PRMD=AC.UK;O=ucl;S=Clay;" + +5.5. Mail-11 encoding of X.400 --> X.400 + + It can happen 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: + + + + + + + + + + + + + + + +Allocchio Experimental [Page 19] + +RFC 2162 MaXIM-11 January 1998 + + + - 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" + + or (for DECnet/OSI) + + net: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); + + and (for DECnet/OSI) + + net:gwnode::gw%"x400-text-address" + + maps into + + C=xx; ADMD=yyy; DD.Dnet=net; + DD.Mail-11=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. + + + + + + + + + + + + +Allocchio Experimental [Page 20] + +RFC 2162 MaXIM-11 January 1998 + + +5.5.1. Examples + + Let us suppose that: + + - the DECnet network name (net) is 'OMNI'; + - the DECnet node name of the gateway (gwnode) is '.IT.DM.X4TDEC' + alias 'X4TDEC' in Phase IV; + - 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=OMNI; + 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 - Mapping - Mail-11 / RFC822 + +6.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 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 chapter 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. In case DECnet/OSI + Mail-11 addresses are involved we must also notice that only one + mapping method can be used from/to RFC822 addresses. + + + + + + + + + + + +Allocchio Experimental [Page 21] + +RFC 2162 MaXIM-11 January 1998 + + + 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::]...]prot::"rfc-822-address" + + or again for DECnet/OSI addresses + + [net:][node-clns::]prot%"rfc-822-address" + + or + + [net:][node-clns::]prot::"rfc-822-addres" + +6.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. This method applies also + easily to DECnet/OSI Mail-11 addresses. + + 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. + + + + +Allocchio Experimental [Page 22] + +RFC 2162 MaXIM-11 January 1998 + + + 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. + + Note the only methods a) can be successfully used for DECnet/OSI + Mail-11 addresses, while the other cases are already too complex to + encode in a unique way such addresses in RFC822. + +6.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. + +6.3.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 + for Phase IV are: + + [[node::][node::]...]prot%"rfc-822-address" + + or + + [node::][node::]...]prot::"rfc-822-address" + + The equivalent two possible variants for DECnet/OSI are: + + [net:][node-clns::]prot%"rfc-822-address" + + or + + [net:][node-clns::]prot::"rfc-822-address" + + + + + + + +Allocchio Experimental [Page 23] + +RFC 2162 MaXIM-11 January 1998 + + +6.3.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 both for Phase IV and DECnet/OSI is: + + "Mail-11-address"@gateway-address + + This format assures also the return path via the appropriate gateway. + +6.3.3 Mail-11 (foreign mail protocol) mapped in RFC822 + + A Mail-11 address containing a foreign mail protocol syntax can also + contain the percent '%' character as a separator between the foreign + protocol name and the actual address itself. In some cases the + address part can also be an unquoted string. Some examples: + + deliver%swan + myprot%root.owner + listserv%my-private.list.A1 + + If these addresses are encoded into an RFC822 address using the + "natural" method described in 6.3.2, they will result in something + which can be easily mismatched with an address using the percent hack + in LHS for source routing. + + "myprot%root.owner"@lohost.mydom.edu (Mail-11 address) + + "LISTSERV%IBMB.BITnet"@bitgate.anu.edu (% routing address) + + The percent hack is strongly deprecated, and thus should be avoided; + the second address above shoud be expressed as: + + @bitgate.anu.edu:"LISTSERV@IBMB.BITnet" + + However, in order to assure maximum functionality and avoid problems, + it is recommended to encode Mail-11 addresses containing the foreign + protocol specification in RFC822 syntax using the DD.Mail-11 and + DD.dnet qualifiers, i.e. + + "/DD.Mail-11=myprot%root.owner/DD.dnet=OMNI"@lohost.mydom.edu + + The DD.dnet defaults as indicated in the similar cases for the Mail- + 11 / X.400 mappings. This encoding method can, of course, also be + used to map any other Mail-11 address in RFC822, and is the only one + which enable to specify the network name ('OMNI' in the above + example) for DECnet Phase IV Mail-11 addresse. The method is fully + + + +Allocchio Experimental [Page 24] + +RFC 2162 MaXIM-11 January 1998 + + + compatible with the results also produced by gateways following the + MIXER specification for Mail-11 addresses encoded in X.400 and then + translated into RFC822. + +Chapter 7 - Complex mapping - X.400 / Mail-11 / RFC822 + +7.1. The protocol triangle + + The bilateral mappings described in chapters 5 and 6 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 MIXER, and the previous + chapters in this document cover the Mail-11 - X.400 side and the + Mail-11 - RFC822 one. + +7.2. RFC822 mapped in Mail-11 + + The 'RFC822-address' is usually included in 'local-part' as + + route::gwnode::gw%"rfc822-address" + + or the equivalent in DECnet/OSI: + + net:gwnode::gw%"rfc822-address" + + An example in Phase IV + + NVXA23::SMTPGW::in%"M.T.Rose@CS.UCLA.edu" + + and another one in DECnet/OSI + + OMNI:.FR.INET.LABOL.SMTPGW::in%"M.T.Rose@CS.UCLA.edu" + +7.3. Mail-11 mapped in RFC822 + + There are different styles in mapping a Mail-11 address in RFC822; + let's have a short summary of what was traditionally done in some + implementations. + + + + + +Allocchio Experimental [Page 25] + +RFC 2162 MaXIM-11 January 1998 + + +7.3.1 Mail-11 address encoded in "Left Hand Side" (LHS) of RFC822 + address, using "%" syntax or "::" syntax + + route::node::localpart (Phase IV) + + maps to + + localpart%node%route@gw-domains + + or + + "route::node::localpart"@gw-domains + + Again, let's consider the DECnet/OSI case: + + net:node-clns::localpart (DECnet/OSI) + + maps to + + "net:node-clns::localpart"@gw-domains + + (note that "%" encoding does not exist for this case) + + where 'gw-domains' identify uniquely the Mail-11 / RFC822 gateway. + +7.3.2 Mail-11 address maps partly to LHS and partly to 'domain' part of + RFC822 address + + node::localpart + + maps to + + localpart@node.gw-domains + + note that this kind of mapping does not exists with DECnet/OSI Mail- + 11 addresses. + +7.3.3 Mail-11 address is completely hidden by a mapping table + + In this case the resultant RFC822 address contains no trace at all of + the original Mail-11 address. + + + + + + + + + + +Allocchio Experimental [Page 26] + +RFC 2162 MaXIM-11 January 1998 + + +7.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. + +7.4.1. X.400 --> RFC822 --> Mail-11 + + We apply the MIXER 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 7.2. + + an example: + + C=gb; ADMD=Gold 400; PRMD=AC.UK; O=UCL; OU=cs; G=Jim; S=Clay; + + maps accordingly to MIXER to + + Jim.Clay@cs.UCL.AC.UK + + and finally becomes + + SMTPGW::In%"Jim.Clay@cs.UCL.AC.UK" + + and finally becomes + + SMTPGW::In%"Jim.Clay@cs.UCL.AC.UK" + + where 'SMTPGW' is the DECnet Phase IV node name of the machine + running the RFC822 to Mail-11 gateway. Again, in case the machine + running the RFC822 to Mail-11 gateway is a DECnet/OSI one (like + OMNI:.US.VA.CENTRL) we would get + + OMNI:.US.VA.CENTRL::In%"Jim.Clay@cs.UCL.AC.UK" + +7.4.2. Mail-11 --> RFC822 --> X.400 + + Some of the possible mapping described in section 7.3 for Phase IV + apply to the Mail-11 address, hiding completely its origin. The MIXER + apply on the last step. + + + + + + + + +Allocchio Experimental [Page 27] + +RFC 2162 MaXIM-11 January 1998 + + + an example: + + RELAY::MYNODE::BETTY + + could map into RFC822 as + + BETTY%MYNODE@RELAY.dnet.gw1.it + + and accordingly to MIXER + + 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. + +7.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' + nto the Mail-11 address, then it applies MIXER to it, and encodes + header. Otherwise it applies the rules described in 7.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 MIXER + + Jim.Clay@cs.UCL.AC.UK + + 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 + + The case with DECnet/OSI Mail-11 is conceptually identical. + + + + + + +Allocchio Experimental [Page 28] + +RFC 2162 MaXIM-11 January 1998 + + +7.4.4. RFC822 --> Mail-11 --> X.400 + + The RFC822 address is encoded in Mail-11 f-address element as + described in sect. 7.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 MIXER 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 MIXER + + 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) + + Again, the case for DECnet/OSI Mail-11 addresses, is conceptually + identical. + +7.4.5. RFC822 --> X.400 --> Mail-11 + + We apply MIXER 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. + + + + + + + + + + + + + + +Allocchio Experimental [Page 29] + +RFC 2162 MaXIM-11 January 1998 + + + an example: + + Jim.Clay@cs.UCL.AC.UK + + maps accordingly to MIXER to + + 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 Phase IV node name of the machine + running the X.400 to Mail-11 gateway. No differences also for + DECnet/OSI Mail-11 addresses. + +7.4.6. Mail-11 --> X.400 --> RFC822 + + The Mail-11 address is encoded as specified in sections 5.2 and 5.5; + then MIXER is used to convert the address in RFC822. + + an example: + + RELAY::MYNODE::BETTY + + maps into X.400 as + + C=it; ADMD=garr; DD.Dnet=OMNI; DD.Mail-11=RELAY::MYNODE::BETTY; + + and accordingly to MIXER + + "/C=it/A=garr/DD.Dnet=OMNI/DD.Mail-11=RELAY::MYNODE::BETTY"@gw2.it + + where 'gw2.it' is the domain of the machine running the MIXER + gateway. + +7.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 it + could be impossible (in case of DECnet Phase IV) to specify in these + mappings the name of the decnet community owning the encoded address, + as it can be always done for X.400; thus the implementation of the + 'intelligent' gateway in this case could result impossible. + + + + + + +Allocchio Experimental [Page 30] + +RFC 2162 MaXIM-11 January 1998 + + +Chapter 8 - Notifications and Probes + +8.1. Overview + + Mail-11 is a real time protocol, i.e. connection is established + directly to the destination node. This makes possible some level of + services like verification of an address, and delivery confirmation. + + However, Mail-11 User Agents ususally do not support notification or + probe services, whereas it is possible to deliver the result of a + notification or a probe to Mail-11. In this section we will briefly + describe the level of service which can be obtained on these services + when Mail-11 is involved. + +8.2. Delivery of Notifications via Mail-11 + + As described in the previous chapters, it is possible to transport + also in Mail-11 with minimal loss of information complex information. + This also includes Notifications. In fact Notifications in + RFC822/MIME are encoded as MIME multipart messages: there are thus no + problems in transporting these messages in Mail-11 as any other MIME + message. Also X.400 Notifications can be transported and delivered + via Mail-11: MIXER describes in fact how to convert them into MIME + multipart messages, taking the problem back to the previous + situation. + + Even when Mail-11 is just an intermediate step for a Notification + message, this consideration just enable support for the service. + +8.3. Generation of Notifications and Probes from Mail-11 + + Although Mail-11 does not support Notification or Probe, the service + could also be supported at gateway level. In fact, due to real time + nature of Mail-11 protocol, the gateway could be reasonably sure that + delivery until the other end of the Mail-11 path was successful or + unsuccessful (and try to verify the feasibility of a delivery in case + a Probe as requested). However, Mail-11 could just be an intermediate + relay service, vanishing the value of the information. + + Implementation of this kind of service at gateway level is thus + questionable, and if done, should clearly state the situation where + it was generated, and the "confidence level" it conveys. + +Security Considerations + + Security issues are not discussed in this memo. + + + + + +Allocchio Experimental [Page 31] + +RFC 2162 MaXIM-11 January 1998 + + +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. E. Kille. + + Thanks also to a number of implementors (among which Ned Freed, + Julian Onions, The Hebrew University of Tel Aviv - Pine VMS support + team), to the HEPnet Mail Technical Committee and to all my Mail-11 + "end users", in particular Enzo Valente, for their suggestions and + wishes which helped me really a lot to prepare this revision of + former RFC1405. + +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] CCITT/ISO, "CCITT Recommendations X.400/ ISO IS 10021-1," + Message Handling: System and Service Overview , December 1992. + + [4] Crocker D., "Standard of the Format of ARPA Internet Text + Messages", STD 11, RFC 822, UDel, August 1982. + + [5] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): + Mapping between X.400 and RFC 822/MIME", RFC 2156, January + 1998. + + [6] Alvestrand H., Kille S., Miles R., Rose M., and Thompson S., + (MIME-MHS) "Mapping between X.400 and RFC-822 Message Bodies," + RFC 1495, Aug 1993. + + [7] Digital Equipment Corp., "VMS Mail Utility". + + [8] Joiner Associates Inc., "Jnet User's Manual". + + [9] PMDF User's Guide. + + [10] Alvestrand, H. "Writing X.400 O/R Names", UNINETT / RFC1685, + August 1994. + + [11] CCITT, "F.401 CCITT Message Handling Services - Operations and + Definitions of Service - Naming and Addressing for Public + Message Handling Services, Annex B (08/92)", August 1992. + + + +Allocchio Experimental [Page 32] + +RFC 2162 MaXIM-11 January 1998 + + +Author's Address + + Claudio Allocchio + Sincrotrone Trieste + SS 14 Km 163.5 Basovizza + I 34012 Trieste + Italy + + Phone: +39 40 3758523 + Fax: +39 40 3758565 + EMail: Claudio.Allocchio@elettra.Trieste.it + C=it; A=garr; P=Trieste; O=Elettra; S=Allocchio; G=Claudio; + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Allocchio Experimental [Page 33] + +RFC 2162 MaXIM-11 January 1998 + + +Full Copyright Statement + + Copyright (C) The Internet Society (1998). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + + + + + + + + + + + + + + + + + + + + + +Allocchio Experimental [Page 34] + -- cgit v1.2.3