From ZaInternetHistory
1 swf 9 73; sj y MAIL013
RHODES UNIVERSITY COMPUTING CENTRE
----------------------------------
UCT Addressing Issue
--------------------
PROVISIONAL
-----------
14 March 1989
-------------
Introduction
------------
The University of Cape Town and Rhodes University are working
towards effecting an email link between the UCT HP computer and
the RU Tower. Both computers run Unix, and therefore the
protocol that will be used is uucp.
This email link will make UCT accessible to the RSCS network
that exists at the moment. RU will act as a gateway for UCT.
When UCT find other methods of linking into the RSA email
network, the situation will be reviewed.
The RSCS Network Address Space
------------------------------
The current RSCS email address space is very simple. All that
is required to send mail is to know the mailbox name and the
name of the host where the mailbox resides. The route taken by
the message is totally hidden from the sender. A Network
Controller sets this up when he installs the RSCS package.
Some examples are:-
Person Email Address
------ -------------
Vic Shaw x034601@csirvm
Philip Welman rkdpdbw@pukvm1
Mike Lawrie ccml@rures
It is desireable (if not essential) to make the addressing style
consistent within any network. This is emphasized in RFC 886
(Messager Header Munging). So, the UCT address space as seen
from an RSCS host (eg CSIRVM) should be of the form:-
user@host
The UUCP Address Space
----------------------
Within the Unix world, addresses are specified in the form of a
path, where each host in the path is mentioned explicitly. The
sender must know (and specify) the route that the message takes.
Also, the order is reversed, the basic form being:-
host!user
Suppose that a message must travel from host UCTCS via UCTHP to
USER at RUTOWER. The address that the sender specifies would
be:-
ucthp!rutower!user
Because of this format, these addresses are called 'bang path'
addresses. (The "!" is known as a bang, presumably from bang!)
Assumed Network Configuration
-----------------------------
In order to give some specific examples, it is assumed that the
network looks like this:-
+-------+ +-------+ +-------+ +-------+
| | | | | | | |
| UCT01 |<----->| UCTCS |<----->| UCTHP |<----->|RUTOWER|
| | | | | | | |
+-------+ +-------+ +-------+ +-------+
A
|
UUCP World |
= = = = = = = = = = = = = = = = = = = = = = = = = = | = = = = = =
RSCS World |
V
########## +-------+
# RSCS # | |
# Network #<---->| RURES |
# # | |
########## +-------+
Addressing a UCT User from the RSCS World
-----------------------------------------
The only way that the VM Notes system appears to be able to
address a mailbox is to use the form:-
user@host {Typed as 'user at host'}
Therefore, at all of the RSCS hosts, a user on any of the UCT
hosts must be addressed in this form.
The RSCS routing tables on all RSCS hosts must be updated to
show that all of the UCT hosts lie 'beyond' the Rhodes host
known as RURES. This will cause all UCT mail to accumulate at
RURES. RURES will then forward the email to RUTOWER, which will
convert the address to be the correct bang path. A table of the
UCT configuration will be stored in RUTOWER.
A similar procedure is working on RURES at the moment, using the
Fidonet link. There is therefore no major adaptation of any
software, nor any process that needs to be proven.
Addressing an RSCS User from a UCT Host
---------------------------------------
The view from any UCT host is that the RSCS user is one hop
further on from RUTOWER. Thus, at host UCT01, the address of
Vic Shaw would be
uctcs!ucthp!rutower!csirvm!x034601
For each UCT host 'closer' to RUTOWER, so the corresponding path
is shorter. From UCTHP, that address becomes:-
rutower!csirvm!x034601
The conversion from the bang path to the domain style will be
done in RUTOWER before the email is forwarded to RURES.
Natural Extensions
------------------
This gateway is readily extended to include any other Unix
hosts. All that need be done is to adjust the tables in
RUTOWER. The comms link used by RUTOWER is X.28, via a Micom
PAD. This is driven by a script, to cause it to establish a
connection with UCTHP. There should be very little trouble to
make it connect to any other X.28 number.
1 Points for Clarification
------------------------
1. The RU Tower will in all likelihood be called RUCS01, not
RUTOWER.
2. What will the UCT hosts be called?
3. Can RUTOWER do a scripted logon to the Cyber, and transfer
email from the Cyber relay area to itself, and do the transfer
in the opposite direction and issue batch MAIL commands?
4. Should the addressing as specified by a UCT user be
uctcs!ucthp!rutower!csirvm!x034601
or
uctcs!ucthp!rutower!rures!csirvm!x034601
This latter might allow a later consistency (Jacot, please
expand on this). The former is shorter to type, and is quite
unabiguous.