From ZaInternetHistory
MAIL016
RHODES UNIVERSITY COMPUTING CENTRE
----------------------------------
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.
{Jacot,
HANG ON! The heading here is 'Sources of Mail', so it must be
...FROM computers..., not ...TO computers...
Mike}
2. Local Mail
=============
This is an interactive process. Mail flow in this case is very
straightforward:
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.
Case USER@NODENAME:
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,
ELSE
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.
ELSE
it is delivered to the user name associated
with the nodename in NODEFIL. This user name
is normally the same as the nodename.
ENDIF
ENDIF
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
mailer!}
{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}
Default:
{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
dangerous.}
{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.
{Jacot,
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.
Mike}
Non-RSCS mail.
--------------
Mail is processed identically to incoming International mail.
{Jacot
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?
Mike}