From ZaInternetHistory
1 MAIL015
R H O D E S U N I V E R S I T Y
---------------------------------
C O M P U T I N G C E N T R E
-------------------------------
Connecting a COMPUTER to the RURES Mailer
-----------------------------------------
P R O V I S I O N A L
---------------------
27 June 1989
------------
+--------------------------------------------------------------+
| N O T E N O T E N O T E N O T E N O T E |
| ================================================ |
| |
| |
| |
This is a specification put out to form a basis for creating
ideas. It is not set in concrete. It is very likely that the
person who ends up coding this lot will have some ideas. Those
ideas must be forthcoming, and must be discussed with a view to
incorporating them in this document. When coding is done,
however, it must meet the specifications of this document. If
it does not, one of two things must happen - the code gets
re-written or the specifications get re-written. The changes to
the specifications need to be directed to Mike Lawrie.
{ccml@rures}
{ccml.rures@f19.n490.z2.fidonet.org}
Technical discussions, ideas and calls for help should be
directed in the first instance to Francois Jacot-Guillarmod,
(alias Jacot).
{ccfj@rures}
{ccfj.rures@f19.n490.z2.fidonet.org}
| |
| |
+--------------------------------------------------------------+
1 Contents
--------
1. Introduction
1.1 Purpose of Document
1.2 Intended Audience
1.3 Definitions
1.4 Pre-Conditions
2. File transfer
2.1 From RURES to the COMPUTER
2.2 From the COMPUTER to RURES
3. Structure of Composite Mail Files
4. Block diagram of existing mail links
5. Variations from RFC 822 Standards
5.1 Source routing
5.2 Line length
5.3 Non-print characters
5.4 Host names and mailbox names
5.5 Postmaster
5.6 Omissions
6. The format of the To: line sent to RURES by the COMPUTER
6.1 For delivery to an RSA host
6.2 For delivery to an international address
7. The format of the To: line sent by RURES to the COMPUTER
8. The Address of the COMPUTER from Various Networks
8.1 From a Host on the RSA RSCS Network
8.2 From another Interfaced COMPUTER
8.3 From an International Host
9. Applying for a Connection
10. Procedures for Testing
10.1 Mail from RURES
10.2 Mail to RURES
Appendix A: Application Form
Appendix B: Some Technical Issues
Appendix C: Node Definitions 1989 April 27
1 1. Introduction
---------------
With the increasing popularity of and email, and the
international link available at Rhodes University, it has become
necessary to produce a set of guidelines for linking computers
to the Rhodes University mail network. These computers could be
stand-alone multiuser computers in a department, or a PC, or a
computer beyond the confines of Rhodes University.
The Rhodes mail network presently consists of 3 separate zones,
namely:
* mail destined for users on computers situated at Rhodes or
capable of being connected to a computer at Rhodes
* mail destined for computers connected to the South African
Universities network via RSCS links
* mail for users of international email networks
It is intended that a computer that connects to the RURES mailer
will be able to send mail to, and receive mail from, all three
of these zones.
1.1 Purpose of Document
-----------------------
This document endeavours to spell out the procedures to be
followed and the standards to be met in order to connect another
computer to the Rhodes RURES mailer, using the interface
designed at Rhodes. This specification may well be incomplete,
and it should not be assumed that meeting this specification is
sufficient, although it will be necessary.
COMPUTERs that are connected to RURES will allow their users to
send mail via the Rhodes gateway into the networks of the
research world. This mail must satisfy the standards that are
necessary for those networks. Bad mail sent into the world's
networks will put a great number of people to a great deal of
trouble in tracking down the problem, and clearing up the mess.
Every effort must be made to avoid this situation.
In the end, it must be assumed that these networks operate on
trust, and on good intent. Thorough error checking is not
possible at all levels - users of the network must work
correctly, in good faith, and with a liberal sprinkling of
social conscience.
1 1.2 Intended Audience
---------------------
This document could end up being distributed to an audience well
beyond Rhodes. Indeed, that is one of its purposes. The reader
is expected to know about email generally, but needs to know
precious little about the Rhodes Cyber.
Anyone who wishes to connect their computer to this interface
will find the job very much easier if they have:-
* - good knowledge of RFC 822 for interchange of text messages
* - knowledge of RFC 886 for message header munging. (Advice on
how to get copies of these RFCs can be obtained from the
Computing Centre)
* - sound technical knowledge of their own computer and its mail
system
* - familiarity with the facilities provided on a mainframe
interactive computer.
1.3 Definitions
---------------
Unless it is clearly otherwise from the context, meanings will
be attributed to certain words as follows:-
RURES
-----
The CDC Cyber at the hub of the mail system at Rhodes University
The RURES mailer
----------------
The process that operates on RURES to cause mail to be created,
sent, received, forwarded to other mailing systems on other
computers.
The COMPUTER (NB: all capitals)
-------------------------------
The computer that is being connected to the RURES mailer for the
purpose of linking to the RURES mailer.
Upload, download
----------------
These terms carry no meaning whatsoever unless the direction of
upload/download is explicitly stated in the context. Please
point out any errors that we might have made in this regard.
1 Username
--------
The term used in the Cyber literature instead of the commonly
accepted term 'user-id'. Treat as synonymous with user-id.
Nodename
--------
The name associated with the COMPUTER, in order that the
COMPUTER can be uniquely identified on the networks.
The Rhodes co-ordinator
-----------------------
The person designated by the Director, Computing Services,
Rhodes University to co-ordinate the connection of the COMPUTER
to the RURES mailer.
The remote co-ordinator
-----------------------
The person at the COMPUTER who is doing the technical
implementation of the linkup.
1.4 Pre-Conditions
------------------
The following pre-conditions must be met before the Computing
Centre will proceed with the linkup:-
* - the process of interfacing the mail system on the COMPUTER
has been accepted as the responsibility of the person who
controls the COMPUTER.
* - a suitable nodename has been assigned to the COMPUTER.
Approval of the name is needed by the Rhodes University
Computing Centre. As at time of writing, the naming convention
for computers on the RSA networks is being reviewed, so it is
possible that any agreed nodename might have to be changed in
the not too distant future.
* - a username corresponding to the nodename of the COMPUTER
must be registered on the Cyber. This registration will be
initiated by the Computing Centre.
* - the COMPUTER must have a serial port that can be connected
to RURES. This connection need not be on a dedicated link, but
could operate on a V22 bis dialup modem (1200/2400 async) or via
an X.28 connection.
* - the COMPUTER must have a mailing system that generates mail
to RFC 822 standards.
1 2. File transfer
-----------------
The COMPUTER should be capable of using Kermit, Xmodem or the
CDC Connect file transfer protocol for interchanging Ascii files
over an asyncronous data link. It should also support a script
facility that allows the logon and logoff processes to run
automatically, as well as conditional execution of commands to
the RURES mailer.
There are two separate (but similar) processes involved, namely
the transfer of mail from RURES to the COMPUTER, and the
transfer of mail from the COMPUTER for forwarding by RURES.
These two processes can be initiated at separate times. The
COMPUTER (not RURES) will always initiate mail interchange
between the COMPUTER and RURES.
2.1 From RURES to the COMPUTER
------------------------------
The COMPUTER initiates this process by logging on to RURES. A
tailored script file is used. Once logon is complete, the
script file initiates the mail reading program (MAILR). This
process creates a file of messages that are destined for the
COMPUTER (or a file that contains a null message). This file of
messages must be transferred to the COMPUTER. The COMPUTER then
logs off.
The format of this file of messages is described in the section
entitled 'Structure of Composite Mail Files', below.
1 2.2 From the COMPUTER to RURES
------------------------------
If there is no incoming mail, the process is not started. This
is because the COMPUTER will know that it has no mail to send
via the RURES link, so there is no need to log in to RURES.
Mail to be sent via RURES must be correctly formatted by the
COMPUTER before the file is transferred. The individual
messages must be to RFC 822 standards, and the set of messages
to be sent to RURES must be stored in a composite mail file of
the correct format (see the section on 'Structure of Composite
Mail Files' below). It is this latter file that is transferred
to RURES.
It is the responsibility of the sending system to ensure that
this standard is met. If a mail file is sent to RURES and it
does not meet this standard, then the effect is undefined.
There is no acknowledgement by RURES that the standard was met.
This file is then transferred to RURES in a very similar way to
the process that operates in the other direction. In fact there
are only two differences in the processing, namely that the file
is first transferred then, instead of a mail reading process
taking place, a mail separation, analysis and delivery takes
place. This last can is carried out by a batch job that uses as
input data the file that has been transferred. Again, this
process of logon, file transfer, and initiate batch job is
carried out under the control of a script file.
3. Structure of Composite Mail Files
-------------------------------------
A mail file to be transferred between the COMPUTER and RURES (in
either direction) has the following format:-
RFC 822 Headers
blank line
message body
. (ie a line with a single full stop)
This individual message structure may be repeated for as many
messages as are to be transferred in the batch. Note that a '.'
in column one of the message body must be converted to a '..'
(ie two full stops).
For example:-
Mail text Transmitted text
--------- ----------------
. ..
.. ...
.Hello ..Hello]
1 4. Block diagram of existing mail links
----------------------------------------
RUCC NJEF NETWORK HOST CONFIGURATION - 1989 APRIL 27.
Definition for node RURES
-------------------------
+---------+ +---------+ +---------+
| The | | NODE-5 | | Fido |
| COMPUTER| | TEST | | Inter- |
| (eg | | | | national|
| RUCS01 | | | | Gateway |
| RUBIS) | |LID = TST| | 2:490/19|
+---------+ +---------+ +---------+
\ | /
\ | /
---------------- |/| ---------------
\ | /
\ | /
+-----------+
+---------+ |+---------+| +---------+
| NODE-1 | LINE-22 || NODE-2 || LINE-01 | NODE-3 |
| RUPLA |---------/ || RURES ||---------/ | RUPHYS |
| CDC | /---------|| CDC || /---------| VAX |
| | (9600 bd ded.) || || (9600 bd ded.) | |
|LID = NJA| ||LID = NJB|| |LID = VX1|
+---------+ |+---------+| +---------+
+-----------+
|
|
|/|LINE-02 (2400 bd dialup)
|
|
+---------+
| NODE-4 |
| PUKVM1 |
| IBM |
| |
|LID = PUK|
+---------+
|
|
|
= = = = = = = = = = = = = = = = = = = |/| = = = = = = = = = = = = = = = =
|
|
+---------+
There is no detailed info |.WITSVMA | Visible through PUKVM1
about the network topology. | NBS |
|.UPVM2 |
|.CSIRVM |
| DNO |
| JES2 |
| UNIS |
| UZNOS |
| CCWRVM |
+---------+
|.RGNVM1 | Visible through UPVM2 (?)
+---------+
1 5. Variations from RFC 822 Standards
------------------------------------
The Rhodes University Computing Centre wishes to abide by
standards as much as possible. However, for various reasons, as
at the date of this document the following limitations and
variations of RFC 822 are imposed on any mail passing to,
through or from RURES.
5.1 Source routing
------------------
Any source routing that might be required must be specified in
the form
a%b%c@d
in order to route mail to user A on host B where the path must
be from RURES to host D and hence to host C before it reaches
host B.
5.2 Line length
---------------
The maximum length of a line is 150 ASCII characters. Lines
longer that this will have an undefined effect. Because this
limit applies to the RFC 822 header lines as well, writers of
mailing systems must ensure that long header lines are folded
well before this limit is reached - a limit of 80 characters is
strongly recommended as the maximum for any messages.
5.3 Non-print characters
------------------------
The only non-print characters that may be sent through RURES are
the pair CRLF, in that order and always in that sequence. The
effect of anything else is undefined, and may change without
notice.
5.4 Host names and mailbox names
--------------------------------
There is currently a limit of 8 characters imposed on each of
these. Longer names may not be used until there is more
stability in the RSA networks.
It is forseen that the Uninet Control Board may impose a limit
of 6 or maybe even 5 characters on the host name. Hosts may
well have to be renamed. The structure of the UCB hostnames
will consist of a 3 (or 2) character site name plus a 3
character host name.
It is likely that the 8 character restriction on mailbox names
will be lifted, but it is difficult to forsee when this might
occur.
1 5.5 Postmaster
--------------
Mail addressed to POSTMAST (case-insensitive) must be handled in
the same way as that for the RFC 822 Postmaster.
5.6 Omissions
-------------
There may well be omissions. It would be very sensible to keep
the interface as flexible as possible. Any mail that is likely
to cause a problem to any of the networks that are reachable
from RURES will have to be stopped instantly until the problem
is cleared.
A COMPUTER that generates problem mail will be summarily
disconnected, whether or not there was an omission from this
specification.
The intent is to get mailing to work, and to work reliably.
There is no objective to go around disconnecting COMPUTERs for
the pure fun of doing so.
1 6. The format of the To: line sent to RURES by the COMPUTER
-----------------------------------------------------------
The contents of the RFC 822 header 'To:' line in the
'.'-formatted file of messages must be as follows. (Refer to
the section on the Structure of COMPUTER Mail Files above):-
6.1 For delivery to an RSA host
-------------------------------
This includes mail for users on RURES, RUPLA, RUPHYS, RUBIS,
PUKVM1, WITSVMA, CSIRVM, UCTITS etc
Mail destined to USER at HOST shall contain
To: user@host
This is to RFC 822 format specifications. The case of
'user@host' is dependent on the receiving host.
The host will be one of the hosts within the RSA, reachable from
RURES. This host could be any of the hosts on the RSCS network,
or another connected COMPUTER using this type of mail interface.
Source-routing to an RSA host is expressly forbidden.
(ie the form To: user%host@relay may not be used).
6.2 For delivery to an international address
--------------------------------------------
Mail destined for international delivery shall contain a 'To:'
line of the following form (where user, domain, relay etc are
ALL international names):-
To: user@domain
or
To: user%domain@relay
or
To: user%domain%relay2@relay1
or similar. Bang paths are not accepted - the COMPUTER must
'unbang' them so that they are presented in a domain format.
As at time of writing, all mail that is not destined to an RSA
host is sent out on the international network, without further
validation. An incorrectly spelt address of an RSA host will be
treated this way, and it will 'bounce' back to the sender.
There will thus be a double charge for this mail, and in the end
it will not have been delivered and the sender will have wasted
his time.
It is the responsibility of the COMPUTER to vet any such mail
before it is forwarded to RURES. No reliance should be placed
on the checking that is or is not done by RURES. Incorrectly
addressed mail is likely to bounce, and thus incur a double cost
(for the outgoing and for the return paths).
1 7. The format of the To: line sent by RURES to the COMPUTER
-----------------------------------------------------------
The 'To:' line of the message will be munged by RURES according
to RFC 886 standards. Mail that has been addressed to be
relayed through a COMPUTER will be forwarded as if that COMPUTER
is a relay. RURES will not be concerned about the computers
that are connected to the COMPUTER. However, certain mailing
operations might not be carried out for unrecognised computers.
It is the responsibility of the COMPUTER to deal with any mail
that has been directed by the sender for relaying via the
COMPUTER. For example, the mail could be returned to the
sender, or sent to the Postmaster on the COMPUTER for handling
manually, or forwared as specified by the sender.
8. The Address of the COMPUTER from Various Networks
----------------------------------------------------
In order to receive mail on the COMPUTER (ie the one that has
now been interfaced to the RURES mailer), an address must be
specified. This section describes that address, as seen from
the various networks that are connected to RURES.
In all cases, the examples show the address for a user called
'user' on the COMPUTER called 'host'.
8.1 From a Host on the RSA RSCS Network
---------------------------------------
Eg from WITSVMA, CSIRVM, RURES. Use the address form:-
user@host
or
user at host (from a VMNOTE computer)
8.2 From another Interfaced COMPUTER
------------------------------------
Eg from another COMPUTER that has been connected to the
interface to the RURES mailer. Use the address form:-
user@host
(or similar, according to how the sending mailer requires it to
be expressed).
1 8.3 From an International Host
------------------------------
This would apply to hosts on the Internet (eg any host that has
a name that ends with '.edu'), or a Bitnet host, or a host on
any major or minor overseas network. The sender must use the
form that they would use to address a site on the Internet, but
the address is:-
user.host@f19.n490.z2.fidonet.org
9. Applying for a Connection
----------------------------
Application to connect must be approved by the Director,
Computing Services, Rhodes University, before any work will be
undertaken by the Rhodes co-ordinator. See appendix A for the
form to use in order to apply for a connection.
All work done by Rhodes to establish this connection will be on
a best effort basis. Rhodes University will not be held liable
for any failure whatsoever either to complete the connection or
to maintain it in good order.
The remote site must pay the cost of the connection between the
COMPUTER and the RURES mailer, unless otherwise agreed to by
Rhodes. This includes, but is not necessarily limited to, the
cost of the data communication links. There may well be further
charges for international email.
1 10. Procedures for Testing
--------------------------
The first thing to do is to establish a form of communication
between the Rhodes co-ordinator and the remote co-ordinator.
(NB Here, the term 'co-ordinator' is a person, not a piece of
equipment). This communication ideally should be via the
network, if necessary via a limited facility - eg a mailbox on
RURES that the remote co-ordinators uses for logging into RURES
(eg via X.28, via dial-up modem or whatever method the Rhodes
co-ordinator finds to be satisfactory)
The absolute minimum that is required before any work will be
done is the establishment of a reliable two-way communication
link between the COMPUTER and RURES. The staff at RURES will do
their best to help with this process.
The first testing will be the receiving of mail from RURES by
the COMPUTER. Failures here will do the least amount of damage
to the mail networks.
10.1 Mail from RURES
--------------------
Rhodes co-ordinator shall send messages to at least three
different mailboxes on the COMPUTER. These messages are to be
returned to him in the exact form that they were delivered to
the user, and possibly in any intermediate form if so requested.
10.2 Mail to RURES
------------------
Under strict guidance by the Rhodes co-ordinator, the remote
site will send messages for delivery to
a special test user on RURES
the Rhodes co-ordinator
specific users at RURES
specific users on the RSA RSCS network
specific users on overseas networks
All of these messages will be trapped by the Rhodes co-ordinator,
and will be vetted for meeting the necessary standards as
understood by Rhodes. Liaision will take place with the remote
co-ordinator in order to bring the mail up to standard.
All being well, the Rhodes co-ordinator will require the remote
co-ordinator to send some test messages to nominated users, and
will arrange for some inter-network mail to be sent to the
COMPUTER.
Given that this is satisfactory, the remote computer is then
connected to the networks.
1 Appendix A: Application Form
----------------------------
This is not funtional as per date of this document, but if and
when it is ever put into service, it will probably look like
this:-
In order to apply to have a computer connected, this form must
be completed and returned to the Director, Computing Services,
Rhodes University, P O Box 94, Grahamstown 6140.
Template form:-
name of responsible person - ie authoritative
name of controlling person - ie technical
(or an alternate for the responsible person)
addresses, telephones, faxes, network addresses, etc
namespace of connecting computer
format of mailbox names on connecting computer
type or name or whatever of the mailer
method for file transfer (eg Kermit, Xmodem etc)
.......
1 Appendix B: Some Technical Issues
---------------------------------
Technical issues for the attention of the Rhodes University
Computing Centre, and of possible interest to others.
* - the nodename is set up as a synonym (family) of the node
RURES in the NJEF configuration file. This ensures visibility
of the COMPUTER throughout the RSCS network.
* - an entry is set up in NODEFIL/UN=MAILER with a flag
indicating that this is a COMPUTER that needs an associated
username for successful mail delivery. This username will be
unique for the COMPUTER, and will be of the form GWxxxxx, where
'xxxxx' is at least three characters.
* - a username corresponding to the nodename of the COMPUTER
must be registered on the Cyber. This is necessary to filter
the mail items destined for a series of similarly connected
COMPUTERs.
* - mail from VMNOTES on the RSA RSCS network does not meet RFC
822 standards. RURES will endeavour to munge what it can, but
certain standards (yet to be laid down) will have to be met in
order for this to happen.
* - mail destined for the COMPUTER wil have been delivered by
whatever process to the mailbox GWxxxxx@RURES.
* - the mail format standard is that of RFC822 (as varied by
this document), and possibly a restricted form of VMNOTE. Other
mail formats will have an undefined effect. Note that PROFs
messages remain in the RURES system queue. It is not possible
to detect whether such a file is a PROFs message or is data, so
they are never treated as mail, and they will eventually die.
1 Appendix C: Node Definitions 1989 April 27
------------------------------------------
This probably has no interest beyond the confines of Rodes
University.
The definitive version of the list of COMPUTERs, nodes, etc is
stored in NODEFIL/UN=MAILER.
col 1-10 : node name
col 11 : flag indicating 'permitted' node
A '+' indicates that the node is permitted to send
and to receive international email.
Blank indicates the the node may send or receive mail
only to other nodes that appear in NODEFIL.
col 12 : flag indicating departmental node
Blank indicates that the node is a directly-connected
computer using the RSCS protocol.
A 'U' indicates that the node is connected as a COMPUTER
using a GWxxxxx username.
col 13 : spare
col 14-21 : associated user name if flag indicates COMPUTER
col 22-37 : description of hardware/software at COMPUTER
col 38-80 : description of the organisation
00000000011111111112222222222333333333344444444445555555555
12345678901234567890123456789012345678901234567890123456789
CCWRVM IBM/VM Water Research, Pieter
CSIRVM IBM/VM CSIR
DNO IBM/VM GOVNET Dept National E
JES2 IBM/TSO CSIR
NBS IBM/TSO-E GOVNET Network Control
PUKVM1 IBM/VM Potch University
RGNVM1 IBM/VM Human Sciences Researc
RUBIS +U RUBIS ADDS Mentor Rhodes University BIS
RUCS01 +U CCFJ NCR Tower Rhodes University Comp
RUPHYS + Vax 11/730 Rhodes University Phys
RUPLA + Cyber 170/825 Rhodes University Comp.
RURES + Cyber 170/825 Rhodes University Comp
TEST Dummy Node for testing
TESTID U CCID test ccid node for ccid to use f
TESTUCT U CCFJ Test uucp Synonym for RURES
TESTUND U CCML Test uucp Synonym for RURES
UCTITS U CCFJ NCR Tower University of Cape Tow
UNIS IBM/TSO University of South Af
UPVM1 IBM/VM University of Pretoria
UPVM2 IBM/VM University of Pretoria
UZNOS Cyber 170/810 University of Zululand
WITSVMA IBM/VM Wits University
WITSVMB IBM/VM Wits University
12345678901234567890123456789012345678901234567890123456789
00000000011111111112222222222333333333344444444445555555555
1 MAIL015 swf 9 73; sj y
----------------------
MAIL015 ends