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.
        Technical discussions, ideas and calls for help should be
        directed in the first instance to Francois Jacot-Guillarmod,
        (alias Jacot).
        |                                                              |
        |                                                              |
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,
        * 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
        * - 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:-
        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
        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.
        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
                            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
        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
        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
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
        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,
        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
                To: user%domain@relay
                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 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:-
        (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:-
        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
        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
        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
        * - 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
        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
        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
1       MAIL015 swf 9 73; sj y
        MAIL015 ends