Network Working Group U. Eppenberger
Request for Comments: 1465 SWITCH
May 1993
Routing Coordination for X.400 MHS Services
Within a Multi Protocol / Multi Network Environment
Table Format V3 for Static Routing
Status of this Memo
This memo defines an Experimental Protocol for the Internet
community. Discussion and suggestions for improvement are requested.
Please refer to the current edition of the "IAB Official Protocol
Standards" for the standardization state and status of this protocol.
Distribution of this memo is unlimited.
1. Introduction
The usage of the X.400 Message Handling System (MHS) is growing
rapidly, especially in the commercial world but much interest can
also be found in the academic and research community. New networks
and new addresses come into use each and every day. The underlying
technology for different X.400 networks can vary depending on the
transport network and the X.400 MHS implementations used. As a large
number of X.400 implementations now support multiple stacks, this
offers the chance of implementing a world wide message handling
service using the same electronic mail standard and, therefore,
without the need of gateways with service reduction and without the
restriction to a single common transport network. This, however,
leads to several problems for the MHS manager, two of which are:
- Where do I route new X.400 addresses and
- How do I connect to a MHS domain that uses an underlying
technology that I do not support.
This document proposes short term solutions to these problems. It
proposes a strategy for maintaining and distributing routing
information and shows how messages can travel over different networks
by using multi stack MTAs as relays. Document formats and
coordination procedures bridge the gap until an X.500 directory
service is ready to store the needed connectivity and routing
information. The format has been designed to allow the information
to be stored in an X.500 directory service while managers without
directory service access may still use a table based approach.
The routing structure proposed can be applied to a global MHS service
Eppenberger [Page 1]
RFC 1465 Routing Coordination for X.400 Services May 1993
but may also be used at a national level or even within an
organisation.
Many experts from IETF X.400-Operations Group and RARE Working Group
1 on Message Handling Systems have read drafts of this document and
contributed ideas and solutions. I would especially like to thank
Harald Alvestrand, Erik Huizer, Marko Kaittola, Allan Cargille and
Paul-Andre Pays.
This is the third version of a table format. The first one was in
use within COSINE-MHS for about two years. A second version with
major enhancements was then proposed which has been in use for the
past year. The third version will probably be the last one before it
will be possible to switch to dynamic, directory service based
routing.
2. Terminology
MHS community
One or more MHS domains form an MHS community. Mail exchange
between these MHS domains is defined by the coordination
procedures within this document. Examples of such communities are
the Global Open MHS service GO-MHS and the COSINE-MHS service.
MHS domain
One or more MHS subtrees form an MHS domain. This is a purely
administrative grouping of MHS subtrees. It is helpful, if
someone is responsible for several MHS subtrees, to refer to an
MHS domain instead of listing all the subtrees.
MHS subtree
An MHS subtree consists of the total of the mailboxes addressable
within a subtree of the X.400 OR address space.
Example: O=SWITCH; P=SWITCH; A=ARCOM; C=CH;
MHS domain of SWITCH in Switzerland, consisting of all
mailboxes with O=SWITCH; P=SWITCH; A=ARCOM; C=CH; in the OR
address.
RELAY-MTA
An X.400 MTA serving one or several MHS domains. Note that the
term WEP -Well Known Entry Point- has been used since the early
X.400ies (1987/88) until now, giving the wrong impression of a
Eppenberger [Page 2]
RFC 1465 Routing Coordination for X.400 Services May 1993
single entry point (and therefore a single point of failure).
This document proposes to use the term RELAY-MTA, reflecting more
clearly the functionality of the MTA.
COSINE-MHS
The COSINE-MHS community is mainly formed by European X.400
service providers from the academic and research area, each of
which is a member of RARE. The COSINE-MHS community is used in
the annex as an example for the usage of this document in a
multinational environment.
3. Requirements
X.400 MTAs can communicate using different transport and network
protocol stacks. For this document the stacks used in a WAN
environment need to be considered:
Stack 1 Stack 2 Stack 3 Stack 4
Transport Layer 4 TP0 TP4 RFC1006 TP0
Networkservice 1-3 X.25 CLNS TCP/IP CONS
A common protocol stack is not the only requirement to enable
communication between two MTAs. The networks to which the MTAs
belong need to be interconnected. Some well known networks are
listed together with the stacks they use.
Network Stack Abbreviation
Public Switched Packet Data Networks 1 Public-X.25
International X.25 Infrastructure EMPB 1,4 EMPB-X.25
US and European connectionless pilot 2 Int-CLNS
Internet 2,3 Internet
Note that several stacks may be supported over a single network.
However communication between MTAs is only possible if the MTAs share
at least a common stack AND a common network.
Unlike SMTP/TCP/IP systems, there is no directory service available
which would allow an MTA to look up the next MTA to which it should
submit a message. Routing within X.400 will continue to be table
based until a solution using X.500 directory services is available.
Furthermore it is not generally allowed to connect to any MTA even on
the same network without being registered on the destination MTA.
These restrictions require a large coordination effort and carefully
configured and updated systems.
Eppenberger [Page 3]
RFC 1465 Routing Coordination for X.400 Services May 1993
4. Outline of the proposal
This proposal offers a solution for describing information about
X.400 message routing within an MHS community in RELAY-MTA and DOMAIN
documents. Basic information on the MHS community is documented in
the corresponding COMMUNITY document. All contact persons and
RELAY-MTA administrators can be found in PERSON documents. A future
X.500 based solution may need extended information to overcome still
unsolved problems like optimal routing or traffic optimization for
messages with multiple recipients. The information collected for the
intermediate solution however is very basic. All established
coordination procedures will help and even speed up the future
introduction of an X.500 based solution.
4.1 The COMMUNITY document
For each MHS community there exists one single COMMUNITY document
containing basic information. First the contact information for the
central coordination point can be found together with the addresses
for the file server where all the documents are stored. It also
lists network names and stacks to be used in the RELAY-MTA and DOMAIN
documents. An MHS community must agree on its own set of mandatory
and optional networks and stacks.
4.2 The RELAY-MTA document
Every MHS domain in the community may designate one or more MTAs as
RELAY-MTAs. These RELAY-MTAs accept incoming connections from the
RELAY-MTAs of the other MHS domains and in return are allowed to send
messages to these RELAY-MTAs. A RELAY-MTA is documented with all the
necessary connection information in the corresponding RELAY-MTA
document.
4.3 The DOMAIN document
An MHS domain has a responsible person who sets up the routing
entries for the domain in the DOMAIN document. The primary RELAY-
MTAs listed in the DOMAIN document as serving this MHS domain must,
TOGETHER, offer at least connectivity to all networks and stacks
listed as mandatory in the COMMUNITY document. Optional RELAY-MTAs
may be added, generally with higher priority, to allow more precise
routing.
An MHS domain may also decide not to operate a RELAY-MTA. It will
then only need agreements with one or more RELAY-MTAs from other MHS
services which will relay for this domain. The domain itself,
however, must either create its own DOMAIN document or document its
MHS subtrees jointly with another MHS domain.
Eppenberger [Page 4]
RFC 1465 Routing Coordination for X.400 Services May 1993
The structure of the DOMAIN document is very straightforward. It
starts off with one or more MHS subtrees, each on its own line.
After the domains follows a line indicating the responsible person
for the MHS subtrees mentioned. Finally the responsible RELAY-MTA(s)
are listed with appropriate priorities.
4.4 The PERSON document
All administrators and responsible persons are documented in PERSON
documents. The RELAY-MTA and DOMAIN documents contain just keys
pointing to a PERSON document. If such a person can already be found
in an X.500 directory service, then the key consists of a
Distinguished Name, else the key is just its OR address.
4.5 Coordination
This approach requires an identified coordination point. It is up to
the MHS community to decide on the level of coordination and support
to be provided and on the funding mechanisms for such activities.
Basic information can be found in the COMMUNITY document. The
following list of support activities is considered mandatory for an
operational service:
- New RELAY-MTAs joining the service are tested and support is
given to create the RELAY-MTA document.
- New MHS domains joining the MHS community get assistance to set
up RELAY-MTA(s) and/or find appropriate RELAY-MTA(s) and to
create DOMAIN documents.
- Updated documents are announced to the RELAY-MTA managers and
responsible persons for the DOMAIN documents unless automatic
distribution is used.
- All the RELAY-MTA, DOMAIN and PERSON documents are made
available on a file server together with the COMMUNITY document.
The file server must at least be reachable via email. MHS
communities with a big number of documents may consider
additional access methods like ftp and FTAM.
- Tools should be made available to manage routing tables for the
X.400 software used on the RELAY-MTAs or to fill in and check
the documents. The format of the documents has specifically
been chosen to enable the use of automated tools.
The RELAY-MTA managers must be aware that a large number of RELAY-
MTAs in an MHS community may require significant operational
resources to keep the local routing tables up-to-date and to
Eppenberger [Page 5]
RFC 1465 Routing Coordination for X.400 Services May 1993
constantly monitor the correct functioning of the connections. On
the other hand more than one RELAY-MTA with a good connectivity to an
MHS domain improves the overall robustness of the domain and thus the
QOS.
MHS communities may decide on additional mandatory requirements for
the operation of a RELAY-MTA. These may include a hot line, echo
services, exchange of statistics, response time to problem reports,
uptime of the RELAY-MTA, etc. This will ensure a certain quality of
service for the end users.
4.6 Routing
The proposal addresses MHS communities spanning several
organisations. But it may also be used to manage routing within a
single organisation or even a global MHS community.
Two kinds of mail relays are defined, the primary RELAY-MTAs and the
secondary RELAY-MTAs. A primary or secondary RELAY-MTA must allow
incoming connections from all other primary and secondary RELAY-MTAs
with a common stack. Primary RELAY-MTAs must be able to connect to
all other primary RELAY-MTAs which share a common stack. A secondary
RELAY-MTA must connect to at least one primary RELAY-MTA.
Each MHS community must define update procedures for the routing
based on the documentation. Automated update has to be studied
carefully.
An MHS community should also define procedures for new RELAY-MTAs and
MHS domains joining the service. Since the usage of X.400 is growing
rapidly a flexible but well coordinated way of integrating new
members into an MHS community is needed. The proposed documentation
format supports this by allowing primary and secondary RELAY-MTAs.
All RELAY-MTAs accept incoming connections from each other. Sending
messages can be done by using the primary RELAY-MTAs only. This
allows new RELAY-MTAs to join the community as secondary and to get
primary status when traffic flow increases. Secondary RELAY-MTAs may
also require a longer testing period.
5. The documents
The definition is given in BNF-like syntax. The following
conventions are used:
| means choice
\ is used for continuation of a definition over several lines
Eppenberger [Page 6]
RFC 1465 Routing Coordination for X.400 Services May 1993
[] means optional
{} means repeated one or more times
() is used to group choices
\" is used for double quotes in a text string
is a Carriage Return and means that the next section starts
on its own line.
The definition is complete only to a certain level of detail. Below
this level, all expressions are to be replaced with text strings.
Expressions without more detailed definition are marked with single
quotes '. The format and semantics should be clear from the names of
the expressions and the comments given.
Wherever the BNF definition requires a single blank, multiple blanks
may be used to increase the readability. Please note that for some
field values the number of spaces is significant.
Lines exceeding 80 characters should be wrapped at any convenient
blank except at blanks which are significant. The line is continued
with at least one leading blank.
Comments may be placed anywhere in the document but only on separate
lines and without splitting wrapped lines. Such a comment line must
either start with a '#' sign followed by white space and the comment
or consist of a single '#' on a single line.
The documents must follow the case of the strings defined in BNF.
Note that some values, especially connection parameters like TSEL or
MTA password are case dependant too.
The BNF definitions are ordered top-down. See Appendix B for an
alphabetically sorted list.
A set of one COMMUNITY document and several RELAY-MTA, DOMAIN and
PERSON documents belong together. The detailed definitions can be
found in the following chapters.
::= \
\
{ } \
{ } \
{ }
Eppenberger [Page 7]
RFC 1465 Routing Coordination for X.400 Services May 1993
5.1 Common Definitions
::= 'Distinguished Name'
The string representation of a Distinguished Name is
defined in the RFCxxxx. If a Distinguished Name is
used as a key in the documents, then the information
can be fetched from the directory instead of checking
the appropriate document. But as long as not all
managers in the same community have directory access,
the same information must also be present in a
document. Note that Distinguished Names in the context
of the routing documents are just used as key strings
to point to other documents.
::= "Community: " \
('community name' | )
The 'community name' is a string identifying the MHS
community to be used in the first line of all
documents.
::= (([ "P=" 'PRMDname' "; " ] \
["A=" 'ADMDname' "; " ] \
"C=" "; " \
"MTAname=" 'MTAname')
| )
A unique key is needed to identify the RELAY-MTA. In
addition to the MTA name itself, it is proposed to use
OR address attributes of the management domain where
the RELAY-MTA resides. ADMD and PRMD fields are both
optional and may be used to guarantee uniqueness of the
key. The values used are irrelevant. Even non-
printable characters like @ or ! are acceptable. The
result is not an address but a key string. A
Distinguished Name may be used instead.
::= ( | )
A unique key is necessary to make the links from the
documents where a responsible person or an
administrator is needed, to the PERSON documents. It
is either the OR address of the person or a
Distinguished Name (if the person is already registered
in the directory).
::= 'Two Character Country Code ISO-3166'
::= 'OR address, ISO 10021-2 Annex F'
It has been used consequently all over the document.
This explains also the syntax of the
Eppenberger [Page 8]
RFC 1465 Routing Coordination for X.400 Services May 1993
and the . Examples:
S=user; O=org ltd.; OU1=sect1; P=org; A=rel400; C=aq;
DDA:RFC-822=we(a)sell.it; P=internet; A= ; C=xx;
G=john; I=w; S=doe; P=org; A=rel400; C=aq;
::= "Address: " ::= [{"; " }]
::= {"+" " " \
[" x" ]}
This syntax follows the attribute syntax of the X.500
directory based on CCITT E.123.
::= 'international prefix'
::= 'national telephone number'
A national number may be written with spaces and
hyphens to group the figures.
::= 'local extension'
::= "Phone: "
One or more phone numbers
::= "Fax: "
One or more FAX numbers
::= "Mail: " 'postal address information'
The items of the postal address are separated by ' /'
wherever the next item goes onto the next line for a
printed address label. If the document is for an
international community, the address should include the
person's country.
Example:
Mail: SWITCH Head Office / Urs Eppenberger /
Limmatquai 138 / CH-8001 Zurich / Switzerland
results in the following mailing label:
SWITCH Head Office
Urs Eppenberger
Limmatquai 138
CH-8001 Zurich
Switzerland
::= "Update: FORMAT=V3; DATE=" 'yymmdd' \
"; START=" 'yymmdd' \
["; END=" 'yymmdd']
The contains also the format identifier.
Eppenberger [Page 9]
RFC 1465 Routing Coordination for X.400 Services May 1993
The date of the last update of a document is given in
the form 'yymmdd'.
A start date must be set. A document can be published
this way before the information in it is valid. (This
is especially useful in absence of automated tools.
RELAY-MTA managers get more time to prepare their
systems.)
An end date is used to set an expiration date for the
document.
::= 'String encoded Presentation Address'
The format of this string follows RFC1278, A string
encoding of Presentation Address and RFC1277, Encoding
Network Addresses to support operation over non-OSI
layers. See chapter 5.2 about the usage of macros in a
Presentation Address.
::= "/" \
"/" \
The service type consists of a string with three parts
concatenated with a "/": Network-name/Network-
service/Transport-Protocol.
::= 'Name of a network'
The network-name string identifies a network. A well
known key word should be chosen. (No '/' character is
allowed.)
Examples: Public-X.25, Internet, EMPB-X.25, Int-CLNS,
WIN, Janet,
::= 'Name of a network service'
Examples: X.25, CONS, CLNS, TCP
::= 'Name of a transport protocol'
Examples: TP0, TP2, TP4, RFC1006
Since network and stack information forms one string,
it identifies in an easy way a connection possibility
between two RELAY-MTAs. The COMMUNITY document defines
the strings to be used in the RELAY-MTA and DOMAIN
documents. Some examples:
Internet/TCP/RFC1006
Public-X.25/X.25/TP0
RARE-IXI/CONS/TP0
RARE-CLNS/CLNS/TP4
(It is probably important to mention here that this
string has nothing to do with the format of a
Eppenberger [Page 10]
RFC 1465 Routing Coordination for X.400 Services May 1993
presentation address as defined by Steve Hardcastle-
Kille in RFC1278. The problem of networks using the
same address structure (X.121 DTEs, 4 Byte Internet
addresses) but not being connected is not addressed in
RFC1278 but solved by using the proposed service
identifier above in addition to the presentation
address. As long as there are network islands, there
is no other way than the addition of an 'island'-
identifier.
::= ["O=" 'Organization-name' "; "] \
["OU1="'OrganizationalUnit'"; "\
["OU2=" 'OrganizationalUnit' "; " \
["OU3=" 'OrganizationalUnit' "; " \
["OU4=" 'OrganizationalUnit' "; "]]]] \
["P=" 'PRMDname' "; "] \
"A=" 'ADMDname' "; " \
"C=" ";"
::= "Reachable: " {
