summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2162.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2162.txt')
-rw-r--r--doc/rfc/rfc2162.txt1907
1 files changed, 1907 insertions, 0 deletions
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 <root@SURFnet.nl>
+ 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 <root@SURFnet.nl>
+ 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 <root@SURFnet.nl>
+ 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 = <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 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]
+