From ZaInternetHistory

                    Mail flows at Rhodes University
                              16 June 1989
     This document gives an overview of how the algorithms operate
     in the various mail systems at Rhodes University. Detail is
     deliberately left out.
     1. Sources of Mail.
     There are four distinct sources of mail at Rhodes: 
     Local mail
     RSCS mail
     International mail via Fido
     'Departmental' mail to computers connected via local links.
     HANG ON! The heading here is 'Sources of Mail', so it must be
     ...FROM computers..., not ...TO computers...
     2. Local Mail
     This is an interactive process. Mail flow in this case is very
     Mail can be addressed to USER or USER@NODENAME.
     Switch according to the address.
     Case USER or (USER@NODENAME .and. NODENAME='rures'): 
           Mail is to be delivered locally. A check is made on the
           specified username, if it exists, the mail is delivered
           otherwise the sender is informed that the user name does
           not exist.
           A comparison is made with nodenames stored in NODEFIL.
           IF (the nodename does not occur in NODEFIL)
                it is assumed that the mail is destined for the
                international Fido gateway and is delivered to user
                name RELAY,
                a further check is made to see whether or not it is
                an RSCS node.
                IF (it is an RSCS node)
                     the mail is transferred using NJEF.
                     it is delivered to the user name associated
                     with the nodename in NODEFIL. This user name
                     is normally the same as the nodename.
     End of Case.
     3. RSCS Mail.
     The term 'store and forward' is used to describe the process
     used by the RSCS protocol to route a file from one node
     through any number of intermediate nodes until it reaches the
     final node. Files that are stored and forwareded are not
     accessed by any mailing process at the nodes.
     The term 'relay' applies to mail files that arrive at a node,
     whether or not by the RSCS protocol, and are then processed by
     mail-forwarding programs.
     The only RSCS mail dealt with by the RURES mail system has
     specifically been sent to node RURES. All other 'store and
     forward' mail items are transient and are dealt with by NJEF.
     Mail destined for a registered user on RURES is queued
     differently to that destined for a non-registered user or for
     further relaying. In both cases, however, the queued file is
     visible to user name MAILER where the mail processing programs
     are active. A program scans the queue at regular (two minute)
     intervals and attempts to convert the queued file to a local
     file that may be processed by the munger. The only information
     from the RSCS headers that is used is a flag indicating
     whether or not the file is a 'note' or a data file from an IBM
     VM system.
     The munger inspects the contents of the local file looking for
     RFC822 headers. Notes from IBM VM systems are recognised, and
     a transformation is done so that the To: and From: headers
     conform to rudimentary RFC822 standards.
     The contents of the From: field are scanned to generate a return path
     and to extract the originating node name.
     The contents of the RFC822 To: field are broken down into a node
     name and a 'user' field. The nodename is then checked against the
     contents of NODEFIL. If the node exists, then the message is delivered
     by the appropriate means to that node. If it does not exist, it is
     assumed to be for the international gateway. The contents of the
     NODEFIL indicate that the originating node is allowed international
     access, it is delivered to user name RELAY, otherwise it is
     marked as undeliverable and returned to the originator.
     If the mail is intended for a local non-RSCS node, it is delivered to
     the appropriate user name.
     -------Mike Lawrie's comments are below----------------------
     The above is not clear, and may have some failings. How about
     this approach.
     Switch according to the USER in the RSCS header.
     Case (Registered User): 
           Switch according to USER.
           Case (MAILER): 
                {Here we have the code for mail that has been sent
                at the RSCS level to MAILER@RURES, and in the To: 
                line there is the necessary information to identify
                where the mail must go.}
                {Eureka! Someone out there has installed an RFC822
                {For those monkeys who have not, the To: line
                itself will have MAILER as the recipient. We then
                look for an X-To: or an X-Forward: orsome such
                keyword <similar to Fidonet ^AINTL line> to find
                out the recipient. The sender on VM NOTE entered
                this line by means of his choice.}
                {Mail could go to a local RURES user, or it could
                go to the RELAY for Fidonet, or to RUCS1 or
                similar. It could also be relayed to another RSCS
                host, but this is badly routed mail, as it should
                not have been sent to RURES at the RSCS level, but
                rather directly to that other RSCS host. But we
                could cater for it at this point, should we wish to
                - it does no harm}
                {Here we simply deliver it to the user. It would be
                munged etc, the VM NOTE pathetic format would be
                grunged into pseudo RFC822 etc, but there is no
                explicit examination of the contents of the To: 
                field. X-To: or X-Forward or whatever is ignored}
           End of Case.
     Case (Non-registered user): 
           {This is to be discouraged, but we must cater for it. I
           assume that JNET is the one that does this to us, and we
           should look into ways to stop this from happening. I
           just do not believe that Bitnet allows this, it is
           {If the mail is not to RFC822 standards, we should
           reject it}
           {If the mail is to RFC822 standards, then munge and
           deliver or relay it, according to the To: line}
     End of Case.
     4. International Mail.
     Mail and other items destined for users not on a 'point' are
     munged on the Fido PC and queued for delivery to the RES
     Cyber. At regular intervals, this mail is transferred to the
     Cyber where it is processed by a 'pre' munger, which converts
     it into the same format as mail items delivered by RSCS.
     Processing is then identical to RSCS processing.
     Is this processing by the same program as the RSCS program? It
     seems to be that it falls into the category that I have
     described for RSCS mail that meets RFC822 standards and has
     been sent to the user called MAILER at RURES. If this is so,
     we should spell it out more clearly here.
     Non-RSCS mail.
     Mail is processed identically to incoming International mail.
     This sounds wrong, somehow. If mail arrives from the Fidonet
     PC and it is addressed to an international address (ie
     destined to go straight back out via Fidonet) then we should
     stop and look. But if mail from RUBIS is destined for an
     international address, that's fine and we do not stop. I need
     to reason this one out, perhaps, but there must be SOME
     differences, surely?