⟦7347488d3⟧

TextFile

\chapter {Setting up X.400 Links}

This chapter shows how to go about setting up X.400 interconnection
with other sites.

Information on X.400 routing and connection establishment is entirely
table driven. There is no standardised support by the Message
Directory Service. This section describes how to setup the \file{or}
routing tables, and the tables needed for bilaterally agreed linkage.

To set up an X.400 connection, information about the Remote Site
needs to be obtained and an entry needs to be inserted in the PP tables.

\section {Remote Site information}

Obtain the information below prior to setting up an X.400 link.

\label {lab.remoteinfo}
\begin {tabular}{l l p{0.5\textwidth}}
\tt&	Technical Contact:&	The person you contact if things go wrong.\\
\tt&	Telephone:&		Telephone Number of the Technical Contact.\\
\tt*&	O/R Address:&		Address of a Contact Person.\\
\tt*&	MTA Name:&		Name by which the Remote Site identifies itself.\\
\tt*&	MTA Password:&		Password by which the Remote Site identifies itself.\\
\tt*&	Transport Selector:&	A port identifier at the transport level.\\
\tt&	Network Address:&	The X.25 DTE and/or IP address of the Remote Site.\\
\tt*&	X.25 Protocol ID:&	A port identifier at the X.25 level.\\
\tt*&	ManagementDomains:&	Any Management Domain/s (MD) that 
			the Remote Site provides a connection to.\\
\end{tabular}

Any information pre-fixed with an "*" may be optional.

Examples of the format are shown in Tables~\ref{remoteinfo.example1}
and~\ref{remoteinfo.example2}.

\tagtable[hbpt]{x400info1}{Example X.400 information for
NASA}{remoteinfo.example1}

\tagtable[hbpt]{x400info2}{Example X.400 information for UCL}{remoteinfo.example2}


\subsection{Conventions}
These are some of the conventions that PP uses for X.400 links. These
need not be followed strictly but make a good starting point.

\begin{itemize}
\item ISODE uses a transport selector. This should be ASCII encoded
and should be all numeric (to conform to X.400(1984)). The value "591"
is often used.

\item The MTA Name is usually an appropriate domain. In the UK this 
is in NRS (i.e big endian domain) order.

\item The MTA Password is usually a single space.
\end{itemize}

\section {Setting up the Routing Tables}

The following steps need to be taken to set up the X.400 routing
tables.  

\subsection{Routing and mapping tables}
First, a number of mapping tables need to be installed. If
you don't have a copy of them, you will need to get one. Copies should be
obtained from University College London (see Appendix~\ref{app:tables}
for details).

\begin{describe}
\item[\verb|or|:] The O/R Table (See Figure~\ref{lab.or.tbl1} below and
section~\ref{sect:ortables}) 
\item[\verb|rfc2or|:] The RFC 822 to O/R Table (See
Figure~\ref{example:rfc2or}) 
\item[\verb|or2rfc|:] The O/R to RFC 822 Table (See
Figure~\ref{example:or2rfc})
\item[\verb|rfc1148gate|:] The rfc1148 known gateways file.
\end{describe}

The \file{rfc2or} and \file{or2rfc} are the RFC 987/RFC 1148 tables.
Incorporate these RFC 987 tables in the Table directory.

\subsection{Editing the O/R Table}

Replace the \verb|_DEFAULT_MTA_| occurrences with appropriate remote
site names. These are the names by which the sites are internally
identifiable within PP.  The choice of name is up to the PP
administrator, and is used for identification purposes only.

Local information should be prepended to this table, and will override
later entries.

When observing the Example O/R Tables on pages \pageref{lab.or.tbl1}
and \pageref{lab.or.tbl2} please note that:

\begin{itemize}
\item The O/R skeleton table in figure~\ref{lab.or.tbl1} on
page~\pageref{lab.or.tbl1} is a truncated example of the {\em
retrieved} UCL O/R Master Table.

\item The O/R skeleton table in figure~\ref{lab.or.tbl2} on
page~\pageref{lab.or.tbl2}, is a truncated example of an {\em edited}
UCL O/R Master Table.
\end{itemize}

\tagrind[hbtp]{exampleortbl}{Example of an O/R table to edit}{lab.or.tbl1}

\tagrind[hbtp]{exampleortbl2}{O/R table after editing}{lab.or.tbl2}

\subsubsection{X.400 Outbound Procedures}

A Brief Description of how the X.400 Outbound Table is used within PP.

\begin{itemize}
\item PP connects to a Remote Site using its specified Network Address 
(in the \verb|rpsap| field).  If it cannot connect, because the Remote
Site's X.25 or IP listener is not running for some reason, and if more
than one address is specified, then all addresses are tried
sequentially, until either failure occurs or a connection is made.

\item When the connection is requested, PP gives its local MTA Name 
and Password as identification.

\item The Remote Site {\em either} accepts connection and returns 
its own MTA Name and Password {\em or} it rejects the connection and
gives as its reason "Validation failure".

\item If the Remote Site rejects the connection, PP terminates 
the X.400 connection.

\item If the Remote Site has accepted the connection, PP 
matches the returned MTA Name and Password against the values held for
the Remote Site, in the X.400 Outbound Table (i.e the \verb|rmta| and
\verb|rpass| fields).

\item If the Remote Site's MTA Name and Password matches up,
PP starts to transmit a message, otherwise PP terminates the X.400
connection.
\end{itemize}
 
\subsection{Editing the X.400 Outbound Table} 

Insert a default entry in the X.400 Outbound Table if it does not
exist, where the key has the value "default" with the following fields
set.  These are the default values by which the the local PP
identifies itself to a Remote Site, when an outgoing X.400 connection
is made.  Refer to the X.400 Outbound Table on page
\pageref{lab.x400out.tbl} when doing this.
\begin{describe}
\item[\verb|lmta|:] Local MTA Name 
\item[\verb|lpass|:] Local Password
\item[\verb|lpsap|:] Local Network Address (same format as \verb|rpsap|)
\end{describe}

When the O/R Table was previously edited, the Remote Site Names that
were chosen by the PP administrator, should have been carefully
recorded. These are the names that are now used to "key" into the
X.400 Outbound Table.  In addition to this, the information below is
also required (refer to page \pageref{lab.remoteinfo}).
\begin{itemize}
\item MTA Name and Password (both optional).
\item Network Address (mandatory)
\item Transport Selector (optional)
\item Protocol ID or pid (optional).
\end{itemize}

If a Remote Site has more than one Network Address then the PP
administrator will need to decide:
\begin{itemize}
\item Which Network Address should be always tried first.
\item Whether all the Network Addresses should be entered (maximum 4).
\end{itemize}
If all Network Addresses are entered, then the one that is always
used, is specified first in the \verb|rpsap| field whose formats are
described on page \pageref{lab.x400out.tbl}.

Insert an entry in the X.400 Outbound Table, 
where the Remote Site Information maps into the following fields. 
Refer to the X.400 Outbound Table on page \pageref{lab.x400out.tbl} 
when doing this.

\begin{itemize}
\item Remote Site Name - \verb|key|.
\item MTA Name - \verb|rmta|.
\item Password - \verb|rpass|.
\item Network Address, TSAP and pid - \verb|rpsap|.
\end{itemize}



\subsection*{NOTE}

\begin{itemize}

\item All keys in the X.400 Outbound Table must be unique.

\item One or more of the "default" fields (\verb|lmta|, \verb|lpass|, 
\verb|lpsap|) are only set within a Remote
Site entry when they are to possess values different to those of the
\verb|default|.  If these values are set within a Remote Site entry
then, when a connection is requested to that particular Remote Site,
the local PP will identify itself differently to normal.  This is only
set in very rare cases, for example, if a Remote Site cannot cope with
a special character in the \verb|lpass| field.

\item If the \verb|rmta| and \verb|rpass| are not specified, this
means that the Remote Site is using {\em EITHER} some other method 
of validation {\em OR} no validation at all.

\item The \verb|rpsap| field has a number of different types of formats, 
some of which may be seen on page \pageref{lab.x400out.tbl}.
The formats depend on whether the Network Address is an X.25 DTE 
or an IP one, and if an X.25 DTE, on whether the pid field is specified. 

\item The \verb|trynext| field is optional, and may be used when there is 
an alternative Remote Site willing to accept mail on behalf of another. 
If this field is used, 2 or more Remote Sites will be tried in 
succession. See section~\ref{tab:X.400(84)out} for more details.
See also page \pageref{lab.x400out.tbl},
for an example of how this field may be used.

\item The \verb|tracing| field is optional, and is only used if trace
compression is required. See section~\ref{tab:X.400(84)out} again for
more details.
\end{itemize}

The X.400 Outbound Table below gives the NASA and UCL entries using
the Remote Site Information specified in Figures~\ref{remoteinfo.example1}
and~\ref{remoteinfo.example2} Some possible \verb|rpsap| formats are also
shown.

\tagrind[hbpt]{chx400out}{Example X.400 outbound table}{lab.x400out.tbl}

\subsection{Channel Table Usage}
The section describes briefly the actions that are taken to validate
an X.400 address.

\begin{enumerate}
\item Parse an address in X.400 style using the \file{rfc2or} and 
\file{or2rfc} tables if necessary to convert from RFC-822 format.

\item Use the \file{or} table to try and locate a Remote Site 
name, through which the address may be relayed 

\item If a Remote Site Name is associated with the address, then 
look at the Channel table to locate the cheapest route by which that
Remote Site may be reached.
\end{enumerate}


\subsection{Edit the Channel Table} 

The Channel Table below gives the NASA and UCL entries using the
Remote Site Information specified on
page~\pageref{remoteinfo.example1} and~\pageref{remoteinfo.example2}. 

\begin{itemize}
\item Note  that the key to this table has the same value as that in
the X.400 Outbound Table on page \pageref{lab.x400out.tbl}.

\item Also, note that the name specified in the rounded brackets is the 
name of the X.400 Outbound Channel, and possesses the same value as
that specified in the \file{tailor} file.
\end{itemize}

\tagrind[hbtp]{chanx400examp}{Example Channel Table}{lab.channel.tbl}

\subsection{X.400 Inbound Procedures}

A Brief Description of how the X.400 Inbound Table is used within PP.

\begin{itemize}
\item A Remote Site requests a connection with the local PP system, 
and within the request its remote Network Address, MTA Name and 
Password are specified. 

\item The local PP uses the remote Network Address as a key into 
the X.400 Inbound Table. 

\item If the key is invalid, then the local PP sends a rejection 
back to the Remote Site, giving "Validation failure" as the reason.

\item If the key is valid, then the Remote Site's MTA Name 
and Password are checked against its {\em rmta} and {\em rpass} 
values specified within the X.400 Inbound Table. 

\item If the values match then the local PP accepts the request
by returning its MTA Name and Password, and begins to get ready 
for remote message transmission.

\item If the values do not match, then the local PP sends a rejection 
back to the Remote Site, giving "Validation failure" as the reason.
\end{itemize}

\bigskip
\noindent{\bf NOTE:} 2 additional fields may be set to facilitate 
X.400 Inbound Connection testing. 

\begin{itemize}

\item {\em info=sloppy} set in the {\em tailor} file, allows the 
acceptance of all incoming connections. All validation checks are 
bypassed. 

\item {\em other=sloppy} set in the {\em X.400 Inbound Table}, 
against a particular Remote Site entry, bypasses the  
validation checks for that site's remote MTA Name and Password.
\end{itemize}

\subsection{Edit the X.400 Inbound Table} 

Before editing this table the PP administrator needs to:
\begin {itemize}
\item Decide whether or not to be selective over the acceptance 
of Remote Site connections. If ALL Remote Site connections are 
to be accepted, then in the {\em tailor} file the X.400 Inbound
Channel is tailored with {\em info=sloppy}, and NO entries 
need to be registered in this table. If entries are registered, 
they will be bypassed. 

\item Decide whether or not Remote Site MTA Name and Password 
validation checks are to be done, this decision should only 
be taken if {\em info=sloppy} is not set in the {\em tailor} file
for the X.400 Inbound Channel. If no MTA Name and Password 
validation checks are to be carried out, then for that Remote entry 
in the X.400 Inbound Table, set {\em other=sloppy}. 
\end {itemize}

Please note when taking these decisions:  
\begin{itemize}
\item If {\em info=sloppy} is set within the {\em tailor} file for the 
X.400 Inbound Channel, the Network Address of a Remote Site 
is still used as a key into the X.400 Inbound Table, to obtain its 
Remote Site Name ({\em rname}).
If the key is invalid, then the Remote Site Name is set to its 
Network Address. 
This will cause problems, if Delivery Notifications are requested 
by such a Site, as the local PP would be unable to use 
the Remote Site Name to key into the X.400 Outbound Table. 
Therefore {\em info=sloppy} should be set for testing purposes only.

\item That for each Remote Site an X.400 inbound and outbound entry 
should exist.
Otherwise if {\em info=sloppy} is set,
and a Remote Site's Network Address keys successfully into the 
X.400 Inbound Table, if there 
is no corresponding entry in the X.400 Outbound Table, no mail 
will be able to be sent to that site.
\end{itemize}
 
When the X.400 Outbound Table was previously edited, the following 
Remote Site Information should have been obtained: 

\begin{itemize}
\item Remote Site Name (chosen by the PP administrator)
\item MTA Name and Password (both optional)
\item Network Address (mandatory)
\item Transport Selector (optional) 
\end{itemize}

As the X.400 Inbound Table is very similar to the X.400 Outbound 
Table the same information is again required. 
Only this time, instead of making a connection to a Remote Site,
the concern is centered on a Remote Site requesting a local connection. 

The fields in the X.400 Inbound Table (see page \pageref{lab.x400in.tbl})
are very similar to the ones in the X.400 Outbound Table (see page 
\pageref{lab.x400out.tbl}), and should be set 
accordingly, except for 2 main differences:

\begin {itemize}
\item {\em rpsap} - which acts as the table entry key.
\item {\em rname} - an extra parameter which specifies the Remote Site Name.
This should have the same value as the Remote Site {\em key} in the 
X.400 Outbound Table.
\end{itemize}

The X.400 Inbound Table below gives the NASA and 
UCL entries using the Remote Site Information specified on page 
\pageref{remoteinfo.example1} and 
\pageref{remoteinfo.example2}. 

\tagrind[hbtp]{x400in-examp2}{Example X.400 Inbound Table}{lab.x400in.tbl}

In the Figure~\ref{lab.x400in.tbl} above, it can be seen that:

\begin{itemize} 
\item The pid field is {\bf never} used in the \verb|rpsap| key.

\item If a Remote Site has a number of Network Addresses, 
all may be specified in the \verb|rpsap| of the Remote Site's X.400
outbound entry (see page \pageref{lab.x400out.tbl}) {\em but} there
will need to be a number of inbound
\verb|rpsap| entries for each Network Address belonging to that Remote Site.
Though all other details (\verb|rname|, \verb|rmta|, \verb|rpass|)
would be the same.
\end {itemize} 


\subsection {How to Locate a Remote Site making a test connection to you.}

\begin{itemize}
\item Go to the PP Log directory
\item Look at the X.400 incoming log. The log should look like those
in Figure~\ref{examp:log}
\end{itemize}

\tagrind[hbpt]{logx400-examp}{Example X.400 incoming logs}{examp:log}

From this log, the following Remote Site Information may be obtained,
which can then be inserted as two entries in the X.400 Inbound and
Outbound Tables.

\begin{itemize}
\item The TSAP - none for the first entry and "PHL" for the second 

\item The Network Address - 5052334300018 for the first entry and 
302049600717 for the second.

\item The MTAName - "manta.cng.dit.csiro.au" for the first entry and 
"foo" for the second.

\item The Password - " " for the first and "foobar" for the second.
\end{itemize}

However, note that:

\begin{itemize}

\item A Remote Site does not have to be specified in the X.400 Inbound Table,
for a connection to be successful.  If in the \file{tailor} file the
X.400 Inbound Channel is tailored with {\verb|info=sloppy|}, then ALL
remote connections are accepted.

\item If on the other hand MTA name and Password validation is to 
be ignored, then for that Remote entry in the X.400 Inbound Table, 
{\verb|other=sloppy|} is added. 
\end{itemize}

\subsection {How to make a test X.400 connection to a Remote Site.}

\begin{itemize}
\item Go to the Table directory.
\item Put the Remote Site Information in the appropriate tables. 
\item Use the program rtsping84, located in the PP \file{TOOLDIR}, to 
make a RTS connection to the Remote Site. For information on how 
to use rtsping84 see its manual page. In the meantime try running:
\begin{description}
\item rtsping84 -c{\em x400out-channel-name} {\em RemoteSiteName}
\item for example
\begin{quote}\small\begin{verbatim}
rtsping84 -cx400out gb-ucl 
\end{verbatim}\end{quote}
\end{description}

\item Check the PP logs. The failure/success will be recorded there.

\item The following failure reasons may be given:

\begin{description}
\item "Validation failure" - The Remote Site has either got 
an erroneous PP entry in their tables, or they haven't recorded 
your entry at all.

\item "Unacceptable dialogue mode" - Either the Remote Site does not 
support monologue or the RTS ASN.1 encoding is bust.

\item "Connect request refused on this network connection"
- Remote Site is either down or its Network listener is not running.

\item "Busy" - Remote Site is busy, try again later. 

\item "Protocol Error" - Protocol Problems 

\item "Remote system problem" - Remote Site's process has terminated abruptly

\item "Timer expired" - Remote system's process is looping 
\end{description} 

\item If rtsping84 was successful, then  
try transmitting a proper message, using the "mail"
program. If during transmission a protocol error is received then this 
needs to be resolved.
To analyse this problem, it may be necessary to obtain the required 
X.400 information, by turning up the rts, session 
and transport logging in the PP {\em tailor} file, this can be done 
by adding the following 3 entries: 

\begin{description}
\item isodelog rtsaplevel file=rts level=pdus 
\item isodelog ssaplevel file=session level=pdus
\item isodelog tsaplevel file=transport level=pdus 
\end{description}
\end{itemize}

\subsection{A Common X.400 incoming connection problem.}

Sometimes a Remote Site attempts to do a RTS recovery, due to some
transmission failure. PP at the moment, does not support recovery, and
so a "cannotRecover" reason is given. This sometimes does not
terminate the connection due to a bug in the Remote Site's software,
and so it keeps on trying, which leads to much network activity.

The X.400 Incoming logs will look something like: 

\begin{quote}\small\begin{verbatim}
 2/ 8  8:30:31 x400in   01392 (#52     )  
        Starting x400in (via X400(84) inbound)
 2/ 8  8:30:33 x400in   01392 (#52     )  
        RtBInit, [Congestion at RtSAP] 
        rejecting attempted recovery
\end{verbatim}\end{quote}


To get the Network address of the Remote Site attempting the recovery,
look at the ISODE tsapd.log, and then match the Network address
against the X.400 Inbound Table keys.
DataMuseum.dk

DKUUG/EUUG Conference tapes

⟦7347488d3⟧ TextFile

Derivation

TextFile
