From ZaInternetHistory
1 M A I L 0 0 0
-------------
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
-------------------------------
Specifications for Action to be taken
-------------------------------------
by the Mailing System
---------------------
1 March 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.
| |
| |
+--------------------------------------------------------------+
1 Contents
--------
1. Purpose
2. Standards
3. The Mailboxes on the Cybers
3.1 The MAILPOI File
3.2 The MAILMES File
3.3 Format of Messages in the MAILMES File
4. Mailing within the same Cyber Node
4.1 Example of a Message
4.2 A Suggested Minimum Mailnames File
4.3 Initial Maintenance of the Mailnames Files
5. Mailing beyond the Cyber
5.1 Mailing within the RSA University Network
5.1.1 The RSCS Sending Process on RURES, RUPLA and RUPHYS
5.1.2 The RSCS Store-and-Forward Process on RURES and RUPLA
5.1.3 The RSCS Receiving Process on RURES and RUPLA
5.1.3.1 Example of a Message received via RSCS
5.1.4 Future Extension to Present Delivery Mechanism
5.1.5 Example of Return Path and Received
5.2 Mailing beyond the RSA University Network
5.2.1 Generating Mail on RURES, RUPLA and RUPHYS
5.2.2 Example of addressing
5.2.3 User Aliases
5.2.4 Action by the RUPLA MAIL Command
5.2.5 Example: International Address from the RUPLA Cyber
5.2.6 Action by the RURES MAIL Command
5.2.7 Example: International Address from the RURES Cyber
5.3 The Sending Process on other Hosts via RSCS
5.3.1 Example: International Address from the RUPHYS Vax
6. Action by the RURES RSCS Receiving Process
6.1 Example of Incoming Mail for User RELAY on RURES
7. Forwarding from RELAY on RURES
7.1 External NOS mail interface
7.1.1 Assumed data file format
7.1.2 Creation of outgoing mail file
7.1.3 Processing of an incoming mail file
7.1.4 General Considerations
7.2 Transfers between RURES and the Fidonet PC
7.2.1 From RURES to the Fidonet PC
7.2.2 From the Fidonet PC to RURES
7.3 Munging the Message Header by the PC
7.4 Example of a Message Exchanged from RURES to the Fidonet PC
7.5 Example Message Created on Fidonet using MSGED
7.6 Example of a Cyber Message in the Fidonet Out Queue
8. Relaying Incoming Mail from Fidonet
8.1 Munging by the PC
8.2 The RURES Process
8.3 Sample Received File from the Internet
9. NOS to FIDO Mail Munging
10. FIDO to NOS Mail Munging
Appendix A: Mail Flows at RUPHYS
Appendix B: Mail Flows at RUPLA
Appendix C: Mail Flows at RURES
Appendix D: RUCC NJEF NETWORK HOST CONFIGURATION - 10 Jan 1989
Appendix E: Mail Flows with Fidonet
1 1. Purpose
----------
This document specifies how mail operations are to take place at
Rhodes University.
While directed primarily at the host computers controlled by the
Computing Centre, the specifications are to be taken more
widely. Various departmental computers should meet these
standards, as well as PC mail systems.
It is unlikely that mail systems that do not conform to these
specifications will be able to access international networks.
2. Standards
------------
It is highly desireable that the mailing systems be brought into
line with the Internet standards. These are described in
various RFCs published by SRI-NIC, and available at Rhodes
University (GET,RFCxxx/UN=CCML on RURES). In particular, anyone
working on the mailing system should have some knowledge of the
contents of RFC 821 (SMTP), RFC 822 (Standard for the Format of
ARPA Internet Text Messages) and RFC 886 (Proposed Standard for
Message Header Munging).
Where standards are not spelt out in this document, the RFC 822
standards are to be used.
In due course, X.400 standards will become available. There is
no doubt that the RFC 822 standard will form the basis of this,
as so much of the world's email meets this standard. Transition
to new standards from a well-established standard will be much
easier than from a conglomeration of differing standards.
The very beginning (section 1.1) of RFC 822 spells out that the
scope of RFC 822 is to describe how mail is to be formatted
when it is interchanged between mail systems, and that nothing
is laid down how any system is to handle mail internally.
Because the original Rhodes mail system is close to these
standards for internal storage, the differences will be
removed, and mail will be stored in the mail files in the very
format that RFC 822 lays down for interchange.
This internal standard will be used when mail is generated and
stored. The final delivery to the reader may, in due course,
have some extensions. Also, an internal encryption system
might be introduced, or other extensions made. But in essence,
it must be taken that any legitimate extract from the Cyber
mail files will produce a message 'ready to roll' in exact RFC
822 format. Similarly, any message given to the Cyber mail
system must be in such a format.
1 3. The Mailboxes on the Cybers
------------------------------
This section describes how the mailing system works on the
Cybers. Clearly, programs written to process mail must know
this structure. However, programs and systems that do not need
to access these files directly should operate at a higher level,
and should use mail utility program to store and to read mail.
This allows for the fundamental mailbox structure to change
without major disruption.
All mail that is readable by a user resides in a single set of
files, that are common to all users. The user is identified by
his NOS username. In due course, this will change, and users
will have mailbox names that look like their real-life names.
Messages are given message id's when they are stored in the mail
system. A tidyup process might cause these message ids to
change from time to time.
There are two files involved, a pointer file (MAILPOI) and a
message file (MAILMES). These files are index sequential.
The pointer file is indexed by the username. Each user who has
(or had) received some mail will have a (possibly empty) list of
message ids. The list will be empty if the user has read all
mail, and a tidyup process has not been run. The pointer file
has a tag field associated with each message id. This indicates
whether the user has read the message, and so it is a candidate
for the tidyup process. During the tidyup process, users with
empty lists are removed from the mail system.
Given a message id, the message text is retrieved by reading
consecutive line numbers from the message file. The key used
for this retrieval is the message id plus line number. Line
number zero has control information for the message.
A future change to be introduced will be to have the message
lines of variable length. Thus there will be a length count.
Mail systems must be capable of exchanging message lines of at
least 1000 ASCII characters (ANY ASCII character, including
control characters). This does not necessarily mean that the
system must store lines in this way, but the system must forward
(possibly by re-creating) such lines. It makes sense to store
the lines as received, and filter at the reading stage, if this
is necessary. The mail system at present guarantees to store
lines of 150 characters, (300 Control Data 6/12 characters), but
control characters are removed.
Note that the system currently (Jan 89) implemented at Rhodes
allows for a message to be readable by more than one user.
Multiple users may have a pointer to the same message id.
The following diagrams of the pointer file and the corresponding
message file should help to clarify the concepts. In this
example, user CCML has two messages still to be read, viz
message ids 5 and 29. User GLAB has no unread messages left,
having read all messages that were received for this username.
User ZZQR has one message to be read.
1 3.1 The MAILPOI File
--------------------
Username Count Message Ids (max 50)
<---Key--> <---> <--------------------->
+----------+-----+-----+-----+-----+-...-+
| CCML | 2 | 5 | 29 | | |
+----------+-----+-----+-----+-----+-...-+
| GLAB | 0 |(13) | | | |
+----------+-----+-----+-----+-----+-...-+
| ZZQR | 1 | 7 | | | |
+----------+-----+-----+-----+-----+-...-+
3.2 The MAILMES File
--------------------
Msg Line Message lines
Id Num
<---> <---> <----------------------------------->
<---Key--->
+=====+=====+=================================...=+
| 5 | 0 | Date rec'd, Number of lines |
+-----+-----+---------------------------------...-+
| 5 | 1 | Lines of message |
+-----+-----+ for CCML, in RFC 822 |
| 5 | 2 | format. |
. . . .
. . . Uses CDC 6/12 display code. .
| 5 | n | |
+=====+=====+=================================...=+
| 7 | 0 | Date rec'd, Number of lines |
+-----+-----+---------------------------------...-+
| 7 | 1 | Lines of message for |
+-----+-----+ ZZQR, in RFC 822 |
| | | format. |
. . . .
. . . Uses CDC 6/12 display code. .
| 7 | m | |
+=====+=====+=================================...=+
| 13 | 0 | Date rec'd, Number of lines |
+-----+-----+---------------------------------...-+
| 13 | 1 | Lines of message for |
+-----+-----+ GLAB, in RFC 822 |
| | | format, already read but |
. . . not yet removed by the .
. . . tidy up process. .
. . . .
. . . Uses CDC 6/12 display code. .
| 13 | j | |
+=====+=====+=================================...=+
| 29 | 0 | Date rec'd, Number of lines |
+-----+-----+---------------------------------...-+
| 29 | 1 | Lines of message |
+-----+-----+ for CCML, in RFC 822 |
| 29 | 2 | format. |
. . . .
. . . Uses CDC 6/12 display code. .
. . . .
| 29 | k | |
+=====+=====+=================================...=+
1 3.3 Format of Messages in the MAILMES File
------------------------------------------
When messages are stored in the MAILMES file, they should be in
the form as spelt out in RFC 822 for the format for the
interchange of messages. There is therefore no need to make any
changes when storing or extracting these messages.
The message starts at line 1 of the MAILMES file. Line zero is
used to hold control information, and thus bears the same
relationship to the message as the 'envelope concept' of RFC 822
- in essence, it is not part of the message at all, and it might
or might not be displayed to the user. Its main use is for such
things as monitoring the size of the message, its age, and
perhaps some other housekeeping information. Line zero is not
part of the message, and it is not forwarded to any other
computer.
It must be taken that any legitimate extract from the Cyber mail
files will produce a message 'ready to roll' in exact RFC 822
format. Similarly, any message given to the Cyber mail system
must be in such a format.
4. Mailing within the same Cyber Node
-------------------------------------
The process involved when mail is sent between users on the same
Cyber is as follows:-
The sender issues a MAIL command, identifying the receiver by
his username. There may be (but need not be) the name of the
host computer specified. (Eg CCML or CCML@RURES will both work
to send mail to CCML by a user logged into host RURES.) In due
course the mail system will be extended to allow more
personalised naming of recipients (eg MLawrie instead of CCML).
There will then be a lookup to substitute the sender's mailname
in place of username.
The mailing program generates the header lines, consisting of
the following fields in this sequence:-
Date: {automatic}
From: {automatic}
Subject: {user-typed}
To: {user-typed}
The next line is blank, and then the body of the message
follows. The body may be generated in various ways (eg typed
line by line, taken from a local disk file, or generated via
FSE).
In due course, the user will be able to provide the additional
header lines of RFC 822 (eg 'Cc:', 'Keywords:',
'Encrypted:'etc). These will be the first lines of the message,
in a sub-header followed by a blank line. However, the mail
generation process will form a proper header as per RFC 822.
The message is then stored in the message and pointer files.
Line zero of the message is set to have the date and time that
the message was stored. (NB This is not part of the message,
which starts at line 1). Information from line zero could be
displayed at message reading time if this made sense, eg the
number of lines in the message.
1 4.1 Example of a Message
------------------------
Here is what is generated by the MAIL command, with line numbers
added purely for illustration. The message was mailed on RURES
by CCFJ to CCDW.
<-- Contents of message --------------------....->
1 Date: Wed, 04 Jan 89 09:22:20 +0200 (SAST)
2 From: <CCFJ@RURES>
3 Subject: TEST
4 To: CCDW
5
6 TEST
7
The components of this message are
Header:- Lines 1-4
Separator:- Line 5
Body:- Lines 6-7
4.2 A Suggested Minimum Mailnames File
--------------------------------------
A suggested minimum layout for this file is as follows:-
<------Key #1------><-------Key #2----->
| | 1|1 1 1 1 1 1 1 1|1 1|2 2 2 2 2 2 2 2 2 2//4|
|1 2 3 4 5 6 7|8 9 0|1 2 3 4 5 6 7 8|9 0|1 2 3 4 5 6 7 6 7 8//0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-//-+
| NOS username|Bl | Upper case |Bl | Upper/lower case // |
| | a | form of the | a | form ofthe // |
| | nk| mailname | nk| mailname // |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-//-+
|C C M L | |M L A W R I E | |M L ^ A ^ W ^ R ^ I// |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-//-+
|C C I D | |I A N - D O R E| |I ^ A ^ N - D ^ O ^// |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-//-+
|Z Z Q R | |Z Z Q R | |Z Z Q R // |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-//-+
The above shows that CCML has mailname 'MLawrie', that CCID has
mailname 'Ian-Dore', and that ZZQR has the default mailname of
'ZZQR' (ie ZZQR has not yet chosen a 'good' mailname).
Given a mailname in upper/lower case, convert it to upper case
solely for the purpose of forming a key, and then extract the
username. Given a username, use its upper case form as a key
to extract the upper/lower case form of the mailname.
The mailname itself may contain uppercase and lowercase
letters, numbers and minuses, but must start with a letter and
end with a letter or a number.
1 4.3 Initial Maintenance of the Mailnames Files
----------------------------------------------
In order to get this off the ground, and to allow for the lack
of lower-case on the MDS data capture process, the mailnames
file will be maintained in keeping with the following outline.
The Computing Centre Secretary will maintain a PC-Planner file
with these fields:-
Field Name Size Comment
---------- ---- -------
Username 7 Upper case only
Blank 3
Mailname 8 Upper and/or lower case
Blank 3
Flag 1 'M' if allowed to mail.
The Secretary must intercept username application forms, and
keep the PC file in good order. There are a number of side
benefits in this, particularly when she assigns new usernames,
as she can now readily look up all existing usernames in any
convenient order.
From this file, an ASCII file is formed by printing to disk.
This print file is then transferred to the Cyber mailname
system, using an automated keypress file. A job is intitiated
to process this ASCII file on the Cyber. This takes place under
username CCSEC, who must have write-mode privileges to the
necessary files under username MAILER. Note that the ASCII file
might have some extra lines, as it is formatted as a PC print
file - suggestions for improvement are welcomed.
The processing on the Cyber should follow these steps:-
* - Allow for the ASCII file to be in any order, and thus
must do any necessary sorting.
* - Check that there are no lower-case letter in the username
in the ASCII file. Don't proceed if this check fails.
* - Balance exactly the username fields from the ASCII file
against the list of actual usernames in file USERFIL. If an
error occurs, report it to the CCSEC (who should still be logged
in), and fail safe. Provide information to the Secretary on
what might be wrong.
* - Check that the mailname field has at most 8 characters
in ASCII form.
* - For all of the ASCII records that have the flag M, set up
the index-sequential file MAILISF with alternate key file
MAILNDX. This file will have the fields as laid out in the
section entitled "A Suggested Minimum Mailnames File" above.
Note that the upper-case form of the mailname must be generated
on the Cyber from the ASCII mailname.
* - Print a simple and short report on the success of the run.
At this stage, no provision has been made for special mailnames
such as POSTMASTER. This may well be done by an extra flag in
the PC-Planner file. Ideas are called for.
1 5. Mailing beyond the Cyber
---------------------------
There are two types of destinations. These are:-
within the RSA university network
outside the RSA university network
5.1 Mailing within the RSA University Network
---------------------------------------------
This is based on the IBM RSCS forwarding protocol. Each host on
the network is known to every other host, and each host has a
routing table that permits it to reach every other host.
Senders do not need to know anything about the routes taken by
the mail. Each host has a unique RSCS node name.
The physical routes will vary from time to time. For the sake
of illustration only, this document assumes the following data
lines:-
+---------+
| |
| RUPHYS |
| |
+---------+
A
|
V
+---------+ +---------+ +--------+
| | | | | |
| RUPLA |<--->| RURES |<=====>| PUKVM1 |<= Etc =>
| | | | | |
+---------+ +----+----+ +--------+
A
|
V
+---------+
| |
| Fidonet |
| |
+---------+
<----------- Rhodes -------> <--Potch-->
5.1.1 The RSCS Sending Process on RURES, RUPLA and RUPHYS
---------------------------------------------------------
Mail created by any of these hosts that is destined for the RSA
university network is generated in the same way as for local
delivery, with the only difference being that the recipient host
must be identified. The identification is done in the 'To:'
line when the message is created.
The Cyber mail program and the Vax JNET package treat the host
name of the recipient as the RSCS node name, and then cause the
mailing system package to send the mail item into the RSA
network.
The mail files to users on the sender node are not affected at
all by this process. They do not use the RSCS system.
1 5.1.2 The RSCS Store-and-Forward Process on RURES and RUPLA
-----------------------------------------------------------
The RSCS protocol is not a mail relay in the sense of RFC 886.
Rather, it is a store and forward system. No changes are made
to any file that RSCS 'relays'.
Storing and forwarding within the Rhodes RSCS network is done
by both of RURES and RUPLA. (RUPHYS is not called upon to do
this, onlbecause of how the topology is laid out. All RSCS
packages have the capability to store and forward.)
Mail that passes through, rather than to, the Cyber is not
processed by any user-written programs that run on the Cyber.
Mail is received by the CDC NJEF package, and put into the
appropriate queue for transmission to the next host according to
the routing information held by the NJEF package on the Cyber.
It might be possible to examine the messages while they are in
the queues, but this is considered to be undesireable, and
indeed forbidden except under crisis conditions. Also, the
forwarding operation is normally very fast. Mail forwarding
using RSCS protocols needs no interference by any non-system
program. No locally-written programs access this mail in order
to make the forwarding work on the RSCS network, as it is part
of the protocol. Therefore, nothing is altered in the messages
that are forwardedon this network.
For all intents and purposes, such mail might have been created
on the intermediate machine, and addressed to a remote user.
However, the RSCS header carried through is that set up by the
originating host.
5.1.3 The RSCS Receiving Process on RURES and RUPLA
---------------------------------------------------
Incoming mail is received by the CDC NJEF package. It is
stored in the Cyber's queued files, with an appropriate set of
control information that is external to the file. This control
information has various types of information about the file.
In particular, it shows the NOS username for whom the file is
intended. This recipient NOS username may or may not be that
for a registered NOS user.
Apart from the recipient NOS username, the NJEF package on the
Cybers is set up to allow username MAILER to access the queued
files. Thus jobs run under username MAILER can distinguish
whether or not the recipient username is that of a registered
NOS user.
Rather than wait for the recipient to do a QGET of the file,
and possibly do something funny to it, a program runs
periodically on the Cyber, under this special username
(MAILER). This program looks for queued message files received
by NJEF, does any conversion that might be necessary, extracts
information from the control fields, and runs the delivery part
of the Cyber MAIL program (called MUNGER in MA10).
Queued data files are left untouched.
1 5.1.3.1 Example of a Message received via RSCS
----------------------------------------------
This message was sent from RUPLA by CCFJ to CCDW on the RURES
host.
<------- RSCS Control Information -------->
+-------------------------------------------+
| Sending node = RUPLA |
| Sending username = CCFJ |
| Receivng node = RURES |
| Receivng username = CCDW |
| Date and time stamps |
| Message class |
| |
| Various other info, as described in |
| CDC manual NJEF Reference Manual |
| publication No. 15190129 E (06-10-87) |
| appendix B. |
+-------------------------------------------+
<-- Contents of queued file ----------------....->
1 Date: Wed, 04 Jan 89 09:22:20 +0200 (SAST)
2 From: <CCFJ@RUPLA>
3 Subject: TEST
4 To: CCDW@RURES
5
6 TEST
7
1 5.1.4 Future Extension to Present Delivery Mechanism
----------------------------------------------------
In due course, the contents of the file are to be altered in
accordance with the following (modified) extract from RFC 821:-
---Start of Extract---
"When the receiver[] accepts a message [] for final delivery it
inserts at the beginning of the [body] a time stamp line. The
time stamp line indicates the identity of the host that sent the
message, and the identity of the host that received the message
(and is inserting this time stamp), and the date and time the
message was received. [ ]
"When the receiver[] makes the "final delivery" of a message it
inserts at the beginning of the mail data a return path line.
The return path line preserves the information in the
<reverse-path> from the [control information]. Here, final
delivery means the message leaves the [RSCS] world. Normally,
this would mean it has been delivered to the destination user,
but in some cases it may be further processed and transmitted by
another mail system.
"It is possible for the mailbox in the return path be different
from the actual sender's mailbox, for example, if error
responses are to be delivered a special error handling mailbox
rather than the message senders.
"The preceding two paragraphs imply that the final mail data
[body] will begin with a return path line, followed by one or
more time stamp lines. These lines will be followed by the mail
data header and body []."
---End of Extract---
The specifications for the return-path and time-stamp line are
found in RFC 822, paras 4.3.1 RETURN-PATH and 4.3.2 RECEIVED
resp.
1 5.1.5 Example of Return Path and Received
-----------------------------------------
Given the following incoming message via the RSCS package:-
<-- Contents of message --------------------....->
1 Date: Wed, 04 Jan 89 09:22:20 +0200 (SAST)
2 From: <CCFJ@RUPLA>
3 Subject: TEST
4 To: CCDW@RURES
5
6 TEST
7
When it is stored in the Cyber mail files, it will look
something like this:-
<-- Contents of message --------------------....->
1 Return-Path: <CCFJ@RUPLA>
2 Received: from RUPLA by RURES ;
3 Wed, 04 Jan 89 09:23:44
4 Date: Wed, 04 Jan 89 09:22:20 +0200 (SAST)
5 From: <CCFJ@RUPLA>
6 Subject: TEST
7 To: CCDW@RURES
8
9 TEST
10
Note that the 'Received:' line may contain considerably more
information than that shown in the example. The description in
RFC 822 should be used to get the specifications of what may be
included, an the format that is to be used.
1 5.2 Mailing beyond the RSA University Network
---------------------------------------------
As at the time of writing, there is a distinct possibility that
Rhodes will be able to send mail via Fidonet, a PC based mailing
system. Because Fidonet can access the other major networks,
there is every reason to get this link up and going. But at the
same time, Fidonet is not necessarily the only way that such
mail might be sent. Therefore, the design must allow for future
(as yet unknown) methods of handling this sort of mail.
5.2.1 Generating Mail on RURES, RUPLA and RUPHYS
------------------------------------------------
The relay host to the international networks is RURES. Hence,
senders must address their mail to be relayed through RURES.
Sending mail from RURES does not require this, but it may be
done if the user chooses. The RURES mail generating program
must recognise that the address is not for the RSA network, and
must therefore treat it as mail to be relayed.
For the RUPLA and RUPHYS hosts, the rule for forming the address
is:-
1. Replace the '@' in the international address with a '%'.
NOTE: If the international address has no '@', or has more than
one '@', it is invalid and cannot be mailed.
2. Suffix the characters '@rures' to the international address.
For the RURES host, the rule for forming the address is:-
1. Use the address unmodified. (The RUPLA form will work, but
it is not a recommended way of forming the address, and it may
not work in future).
5.2.2 Example of addressing
---------------------------
To send mail to the address 'anyuser@some.host', the 'To:' line
would become:-
On RUPLA (optionally for RURES)
To: anyuser%some.host@rures
On RURES
To: anyuser@some.host
On RUPHYS
To: JNET%"anyuser%some.host@rures"
1 5.2.3 User Aliases
------------------
It may well be that the address line is fairly complex. The
simplest form is similar to that for the RSA network. In more
complex forms it might have various oddball symbols such as
periods, percents, bangs (ie exclamations) and others. This is
not of our concern, and such addresses must be used as provided
by the sender.
In due course an alias method will be set up, so that users can
predefine commonly used network addresses with a shorthand
notation of their choice.
No matter how the address is generated, the action taken by the
MAIL command depends on the Cyber.
5.2.4 Action by the RUPLA MAIL Command
--------------------------------------
The RUPLA MAIL command will do the following:-
1. Parse the contents of the 'To:' field for the user-field and
an optional '@' followed by the host-field. Do a syntax check
on these fields, particularly for the presence of at most only
one host-field. Abort on error.
2. If the user host-field is RUPLA, remove this field and its
preceeding '@', and replace in the user-field from the right the
first (if any) '%' with an '@'.
3. If at this stage there is no '@', attempt to deliver the
mail to the specified mailbox on RUPLA. Exit.
4. If there is a '%' in the field, use NJROUTE to send the
message to user RELAY on RURES. Exit.
5. The field must now be of the form 'user@host'. Identify
the host-field that now follows the '@'. If it is on the RSCS
network, then mail it using NJROUTE. Use the first characters
of the user-field (to a maximum of 8) as the RSCS username.
Exit.
6. The mail is undeliverable. Inform the user.
1 5.2.5 Example: International Address from the RUPLA Cyber
----------------------------------------------------------
Suppose that user CCML logged into RUPLA wishes to send a
message to JIM.JONES%MIT.EDU@RELAY.CS.NET. The submission of
the message would produce this:-
RHODES UNIVERSITY MAILING SYSTEM
Version 3.0
There are no messages for you.
S)end...Q)uit..s
To: jim.jones%mit.edu%relay.cs.net@rures
Subject: Test message
Type in a message terminated with TWO blank lines
or specify a filename preceded with '@'
or press ENTER to use FSE to create the message.
> Testing the mail system
>
>>
<<Sending...>>
The message file that is generated would look like this:-
<-- Contents of message --------------------....->
1 Date: Wed, 04 Jan 89 09:22:20 +0200 (SAST)
2 From: <CCML@RUPLA>
3 Subject: Test message
4 To: jim.jones%mit.edu%relay.cs.net@rures
5
6 Testing the mail system
7
This would be mailed by the RUPLA MAIL system to the user called
RELAY on RURES. The way that it will be handled by the relaying
process is described in a later section.
5.2.6 Action by the RURES MAIL Command
--------------------------------------
The RURES MAIL command will do the following:-
1. Parse the contents of the 'To:' field for the user-field and
an optional '@' followed by the host-field. Do a syntax check
on these fields, particularly for the presence of at most only
one host-field. Abort on error.
2. If the user host-field is RURES, remove this field and its
preceeding '@', and replace in the user-field from the right the
first (if any) '%' with an '@'.
3. If at this stage there is no '@', attempt to deliver the
mail to the specified mailbox on RURES. Exit.
4. Identify the host-field that now follows the '@'. If it is
on the RSCS network, then mail it via NJEF. Exit.
5. Assume that the mail is destined for an international
address. Mail the message to RELAY on the RURES mail system.
1 5.2.7 Example: International Address from the RURES Cyber
----------------------------------------------------------
Suppose that user CCML logged into RURES wishes to send a
message to JIM.JONES%MIT.EDU@RELAY.CS.NET. The submission of
the message would produce this:-
RHODES UNIVERSITY MAILING SYSTEM
Version 3.0
There are no messages for you.
S)end...Q)uit..s
To: jim.jones%mit.edu@relay.cs.net
Subject: Test message
Type in a message terminated with TWO blank lines
or specify a filename preceded with '@'
or press ENTER to use FS* to create the message.
> Testing the mail system
>
>>
<<Sending...>>
The message file that is generated would look like this:-
<-- Contents of message --------------------....->
1 Date: Wed, 04 Jan 89 09:22:20 +0200 (SAST)
2 From: <CCML@RURES>
3 Subject: Test message
4 To: jim.jones%mit.edu@relay.cs.net
5
7 Testing the mail system
8
Because the RURES mail system does not recognise the node name
'relay.cs.net', this would be mailed by the RURES MAIL system to
the user called RELAY (on RURES), and the message file would
contain the message in the above format.
1 5.3 The Sending Process on other Hosts via RSCS
-----------------------------------------------
Messages must be sent to the RURES mail system with the
international address slightly modified. The modification rule
is:-
1. Replace the '@' sign with a '%' sign. (There must have been
exactly one '@' sign in the address.)
2. Suffix the characters
@rures
to the address.
Messages must conform to RFC 822 standards. There must be a
header followed by a blank line separator followed by the body.
The effect of this is to get all mail that is to be relayed
beyond the confines of the RSA university sytem to arrive at
RURES in an RFC 822 standard format.
5.3.1 Example: International Address from the RUPHYS Vax
---------------------------------------------------------
To send mail to the address JIM.JONES%MIT.EDU@RELAY.CS.NET, a
user on RUPHYS would respond to the 'To:' prompt with:-
JNET%"jim.jones%mit.edu%relay.cs.net@rures"
The RSCS system will deliver this as is to RURES, where the
MAILER will remove the '@rures', and change the rightmost '%' to
an '@', to get the 'To:' line to become:-
To: jim.jones%mit.edu@relay.cs.net
This will be delivered to the mailbox of user RELAY, which will
cause the message to be sent to the user.
1 6. Action by the RURES RSCS Receiving Process
---------------------------------------------
The RURES receiving system must recognise mail that is addressed
to an unrecognised user. Mail for recognised users must be
delivered to the local mail files, with appropriate processing
as per RFC 822 etc.
Note: The RSCS control field might indicate that the first 8
characters of the user-field are a non-existant user on RURES.
It could just happen that this (truncated to eight chars) field
matches a username at RURES, purely by co-incidence. The
recieving program must not rely on this RSCS control field to
identify the receiver - the program must search through the
header of the message itself for the 'To:' line, and use what it
finds there to identify the receiver.
The 'unrecognised user' mail that can be relayed via Fidonet
will have the message header 'To:' line with an address
consisting of a user-field pepperred with '%' signs (at least
one), an '@' separator, and the word RURES.
When a message is identified (by the contents of the 'To:' line)
as having to be relayed via the Fidonet PC, then the process to
be followed is:-
1. Identify the sender's host computer, by examining the RSCS
header and/or the 'From:' line. Any mail that did not originate
on a Rhodes host is to be treated as undeliverable.
3. Munge the header 'To:' line by discarding the '@RURES'
string, and replace the rightmost (possibly the only) '%' with
an '@'. If there is no '%', the message is to be treated as
undeliverable.
3. Replace or insert as appropriate a 'Return-path:' line into
the message, in accordance with RFC 822.
4. Add a 'Received:' line, as a relay process should. See, for
example, RFC 821 page 21, copied (slightly modified) below:-
---Start of Extract---
"When the receiver [] accepts a message either for relaying or
for final delivery it inserts at the beginning of the mail data
a time stamp line. The time stamp line indicates the identity
of the host that sent the message, and the identity of the host
that received the message (and is inserting this time stamp),
and the date and time the message was received. Relayed
messages will have multiple time stamp lines."
---End of Extract---
Here is an extract from RFC 822:-
---Start of Extract---
Note: Due to an artifact of the notational conventions, the
syntax indicates that, when present, some fields, must be in a
1 particular order. Header fields are NOT required to occur in
any particular order, except that the message body must occur
AFTER the headers. It is recommended that, if present, headers
be sent in the order "Return-path", "Received", "Date", "From",
"Subject", "Sender", "To", "cc", etc.
---End of Extract---
5. Place the munged message in the RURES MAIL system for user
RELAY.
6.1 Example of Incoming Mail for User RELAY on RURES
----------------------------------------------------
Suppose that the following mail is received by the RSCS receiver
program on RURES. This mail could have been generated by any
particular host, and the method of how it got to RURES is not
specified, except that it arrived via the RSCS port.
<-Contents of incoming message prior to munging->
1 Date: Wed, 04 Jan 89 09:22:20 +0200 (SAST)
2 From: <CCML@RUPLA>
3 Subject: Test message
4 To: jim.jones%mit.edu%relay.cs.net@rures
5
6 Testing the mail system
7
This message must be stored in the RURES mail system for user
RELAY in the following form:-
<-- Contents of message after munging ------->
1 Return-path: <CCML@RUPLA>
2 Received: from RUPLA by RURES ;
3 Wed, 04 Jan 89 09:23:44
4 Date: Wed, 04 Jan 89 09:22:20 +0200 (SAST)
5 From: <CCML@RUPLA>
6 Subject: Test message
7 To: jim.jones%mit.edu@relay.cs.net
8
9 Testing the mail system
10
This is now in a similar form to a message created on RURES
itself, destined for an international address.
A point to note in the above.
For a typical message sent to A%B%C@D from Z@Y, host D would
forward as being 'To: A%B@C' 'From: Z%Y@D'. However, in the
case whereby hosts Y is directly addressable from host D, the
'From:' line shows Z@Y. This is the case for the RSCS network.
All that mail from outside of the RSCS network has to do (eg
mail coming in via Fidonet or PCs or whatever) is to address
the mail to the user at the appropriate host, and not to have
an address like 'user%witsvma%pukvm1@rures'. Therefore be wary
as to how the 'To:' and 'From:' fields are munged.
1 7. Forwarding from RELAY on RURES
---------------------------------
The above specifications cause messages to accumulate for user
RELAY on RURES. These messages are stored in a form identical
to that used for RFC 822 message interchanges.
The Fidonet PC will be permanently connected to a dedicated
async port either on the NPU or on CDCNET.
At a time convenient to the Fidonet PC, the PC interacts with
the Cyber. Username RELAY is used. A special form of the MAIL
program is used to get messages in RFC 822 format. Possibly
using line zero information from MAILMES, the PC makes copies of
all messages stored for user RELAY in the Cyber MAIL files.
Processing each message in turn, and using some method (eg an
interlock file) to guard against interruptions (eg power
failures), the file is transferred using a reliable protocol to
a holding area on the PC.
With each and every file transferred, in as foolproof a way as
possible, the list of permitted hosts will be transferred from
the appropriate file on the Cyber to the PC. This will be used
to check the 'From:' field when munging takes place.
All processing is to be fully automatic, needing no human
intervention. A schedule file on the PC is to control the times
when transfers are to take place. Scheduling must be possible
for each day of the week, and any number of sessions per day
must be possible.
Note that once the message has been read from the Cyber mail
files, it must be deleted before the next message can be read.
This process is due for changing in the future, and provision
should be made for an explicit command to delete mail from
RELAY's mailbox.
Any number of (or no) messages might be transferred from the
Cyber to the PC. All messages in the RELAY mailbox that need to
go to the PC should normally be transferred before the PC
proceeds with its next stage.
The Cyber might not respond to the attempted transfer. This
process must time out, causing the PC to go back to its normal
operations. Further, the Cyber might fail once the process has
started, and it may by in any particular state. Both ends of
the link (the Cyber and the PC) must recover gracefully, leaving
all mail intact and un-duplicated.
1 7.1 External NOS mail interface
-------------------------------
The transfer of mail items to and from the Cyber can take place
in many ways. The method about to be described will allow the
transfer of mail using an asynchronous data line and a device
(such as a PC) that will allow the execution of a script file to
initiate an interactive logon and the transfer of a data file
using either CDC Connect, Kermit or Xmodem file transfer
protocols.
7.1.1 Assumed data file format
------------------------------
The data file to be transferred must have the following format
to be correctly processed on the Cyber:
RFC 822 Headers
blank line
message body (including blank lines)
. (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
single '.' in column one of the message body must be converted
to a '..' (ie two full stops).
Both incoming and outgoing data files are assumed to have this
structure.
It is assumed that no logon will be attempted if there are no
incoming messages to upload. However, because the
existence/non-existence of mail on the Cyber cannot be
determined beforehand by the PC, provision is made for a 'null'
outgoing mail package being represented by a single '.'.
7.1.2 Creation of outgoing mail file
------------------------------------
Once the interactive logon process to the applicable user name
is successfully completed, the script file initiates the
interactive reading of mail using a special reading program
(MAILR). This relies on an adaptive script to continue Reading,
Copying, and Killing mail items until no more are found. The
'.' delimiter is inserted automatically in the reading process.
Finally the file is 'packed' to remove any (EOF) delimiters and
a file transfer operation is initiated.
The entity logging on to the Cyber is required to have the
capability of following a sophisticated script, as well as the
capability of transferring an ascii data file.
1 7.1.3 Processing of an incoming mail file
-----------------------------------------
It is assumed that the incoming messages have been correctly
formatted. This file is then uploaded in a very similar way to
the download process. In fact there are only two differences in
the processing, namely that the file is first uploaded and then,
instead of a mail reading process taking place, a mail
separation, analysis and delivery take place. This last can be
most conveniently carried out by a batch job that uses as input
data the file that has been uploaded. Again, this process of
logon, upload, and initiate batch job is carried out under the
control of a script file.
7.1.4 General Considerations
----------------------------
Each external mailing 'node' or gateway is envisaged as having
its own NOS user name. Mail to any given 'node' will be
delivered to the applicable user name using the normal NOS
mailing system.
1 7.2 Transfers between RURES and the Fidonet PC
----------------------------------------------
The following assumptions have been made:-
* - the PC has a second serial port that is connected to CDCNET
during the transfer.
* - outgoing mail destined for the gateway has been delivered by
whatever process to user name RELAY@RURES. The transfer process
makes no assumptions whatsoever about the format of this
outgoing mail. (The sheer fact that it arrived here at all
presupposes that the message has passed some fairly stringent
tests of its conformance to RFC822).
* - the PC will always initiate mail transfer at times
convenient to itself.
* - there are two separate (but similar) processes involved,
namely the download of outgoing mail from the Cyber to Fido, and
the upload of incoming mail for NOS. These two processes can be
initiated at separate times.
* - the incoming mail will have a rudimentary RFC822 standard
headers imposed on it (if necessary) by the munging process on
the PC.
7.2.1 From RURES to the Fidonet PC
----------------------------------
The PC initiates the process using CONNECT 1.2 with a tailored
configuration file (FIDOCFG) and a tailored keypress file
(FIDOKEY).
The file FIDOCFG contains a script file that allows an auto
logon (assisted by a few MODVAL parameters). Once logon is
complete, the script file interacts with execution of the normal
MAILBOX user prolog to initiate an interactive MAIL session,
using a special form of the mail reading program. The process
used to separate the various messages is described below, under
the heading "NOS to FIDO Mail Munging"
If there is mail available, it is read and accumulated into
direct access file MAILFID. When there is no more mail, the
script file quits the interactive MAIL session and the logon
process terminates together with completion of the user prolog.
If no outgoing mail is available, the file MAILFID will contain
only an 'end-of-file' marker, otherwise processing is the same.
Control is now taken by the CONNECT Keypress file. This
initiates a download of the file NODEFIL (for use in vetting
allowed nodes), and then a download of the file MAILFID. On
completion of these two downloads, CONNECT logs out from the
Cyber and finally returns to DOS.
The process of downloading is initiated by the following DOS
command line:
CONNECT FIDOCFG FIDOKEY
1 7.2.2 From the Fidonet PC to RURES
----------------------------------
Superficially, this process is very similar to that of
downloading. A minor change is that the script part of the
config file (NOSCFG) no longer reads mail from the Cyber, even
if some is present. If there is no incoming Fidonet mail, the
process is not started.
If there is some incoming Fidonet mail, the PC logs into the
Cyber. The user prolog fires off a batch run which will wait
for an interlock to clear. On completion of the script file and
user prolog, the keypress file (NOSKEY) takes over. This
initiates the upload of the incoming Fidonet mail file
(MAILNOS), logs out from the Cyber and then returns to DOS.
The interlock holding the batch job will clear when the upload
process logs off. The batch job then processes the incoming
mail in a very similar way to incoming RSCS mail. It is
processed by the same munger, which decides on the best method
of delivery (or return to sender).
The process of uploading is initiated by the following DOS
command line:
CONNECT NOSCFG NOSKEY
1 7.3 Munging the Message Header by the PC
----------------------------------------
When a message is relayed via Fidonet, it is necessary to munge
the header of the message in accordance with RFC 886.
One principle behind this is that the sending process on Fidonet
requires that the message header be scanned, and the necessary
Fidonet fields set up for Fidonet mail, and at the same time any
addresses in the fields specified by RFC 886 must be altered so
that returned mail can be sent using those addresses.
A guideline is that it would be desireable for the Cyber to send
directly on Fidonet, and not require a PC to be in the link. It
is not necessary to do this direct connection at this stage (it
may never be necessary), but when deciding what needs to be done
to any message, and where the relay points are, and who is what
gateway, the PC should be just about transparent. That said,
the PC DOES happen to process the message, so it must leave a
record of this. RFC 886 states that munging agents should do
so. In deciding what processing to do, the guideline is to
suppose that the Cyber linked directly to Fidonet.
The PC will add a 'Received:' line to the start of the body of
the message, to reflect that the message was processed on the
Fidonet PC. See, eg, RFC 821 pg 21, copied below:-
---Start of Extract---
"When the receiver[] accepts a message either for relaying or
for final delivery it inserts at the beginning of the mail data
a time stamp line. The time stamp line indicates the identity
of the host that sent the message, and the identity of the host
that received the message (and is inserting this time stamp),
and the date and time the message was received. Relayed
messages will have multiple time stamp lines."
---End of Extract---
Note. It is highly desireable that the process on the PC treats
mail as being of RFC 822 standard. (The Cyber should have
ensured this). This has many potential applications. Do not
have this transfer do anything that is Fidonet specific.
A check must be carried out for valid 'From:' hosts. A file of
hosts validated to use Fidonet must be consulted. All messages
that fail this validation must be returned to the sender (via
RURES) with an 'undeliverable' message (not 'gateway not
permitted to you').
The PC now runs a 'munging' program, to put the file into the
appropriate format and storage area. The munging process must
modify (at least) the 'From:' field when it is moved into the
correct position for Fidonet. The process requires that the '@'
separator be changed to a space. Thus, for example, if the
'From:' field contains
CCML@RURES
then it must be stored in the Fidonet 'fromUserName' as
CCML RURES (possibly as Ccml Rures)
1 Further munging is to take the contents of the 'To:' line, and
move this to the appropriate place and format for Fidonet to
use. An 'INTL' line must also be generated, in the same form
and position as if the PC program MSGED had created this
message. Fields to be changed are specified in RFC 886.
The munged message is placed into the appropriate PC disk files,
as if it had been generated by a mail generator on the PC. This
causes it to be mailed to the UUCP gateway on Fidonet.
----- NOTE NOTE NOTE -----
This Fidonet that is being set up must not allow mail to be sent
anywhere unless it is generated via the RURES to PC link. In
particular, anyone logging into the Fidonet PC must (a) be
kicked off as politely as reasonable and (b) be barred from
creating and sending mail. This BBS is, in Fido The Book
terminology, a private system.
1 7.4 Example of a Message Exchanged from RURES to the Fidonet PC
---------------------------------------------------------------
<-- Contents of message in RELAY@RURES-----....->
1 Return-path: <CCML@RUPLA>
2 Received: from RUPLA by RURES ;
3 Wed, 04 Jan 89 09:23:44
4 Date: Wed, 04 Jan 89 09:22:20 +0200 (SAST)
5 From: <CCML@RUPLA>
6 Subject: Test message
7 To: jim.jones%mit.edu@relay.cs.net
8
9 Testing the mail system
10
<-- Contents of message to be munged by the PC--...->
1 Return-path: <CCML@RUPLA>
2 Received: from RURES by f19.n490.z2.fidonet.org;
3 Wed, 04 Jan 89 17:05:43 +0200 (SAST)
4 Received: from RUPLA by RURES ;
5 Wed, 04 Jan 89 09:23:44 +0200 (SAST)
6 Date: Wed, 04 Jan 89 09:22:20 +0200 (SAST)
7 From: <CCML@RUPLA>
8 Subject: Test message
9 To: jim.jones%mit.edu@relay.cs.net
10
11 Testing the mail system
12
Having munged the message, the PC now sets up the message for
the Fidonet mailing process. Some of the Fidonet stored message
fields (of Fidonet FSC-0001 pg 4) will be:-
fromUserName: CCML RUPLA {ex RFC 822 'From:'}
toUserName: UUCP {Always this}
Subject: Test message {ex RFC 822 'Subject:'}
dateTime: 04 Jan 89 09:22:20 {ex RFC 822 'Date:'}
text: <-- Contents of text field-------------....->
1 {A}INTL 1:105/6 2:490/19
2 To: jim.jones%mit.edu@relay.cs.net
3 Return-path: <Ccml.Rupla@f19.n490.z2.fidonet.org>
4 Received: from RURES by f19.n490.z2.fidonet.org;
5 Wed, 04 Jan 89 17:05:43 +0200 (SAST)
6 Received: from RUPLA by RURES ;
7 Wed, 04 Jan 89 09:23:44 +0200 (SAST)
8 Date: Wed, 04 Jan 89 09:22:20 +0200 (SAST)
9 From: "CCML@RUPLA"
10 <Ccml.Rupla@f19.n490.z2.fidonet.org>
11 Subject: Test message
12 To: jim.jones%mit.edu@relay.cs.net
13
14 Testing the mail system
15
1 7.5 Example Message Created on Fidonet using MSGED
--------------------------------------------------
The following is an example of a message 'ready to go' from the
Fidonet PC to 'lawrie@vax.oit.udel.edu'. It was created by
Fidonet user Pat Terry, who mailed it to the Fidonet user called
UUCP, and put the Internet 'To:' line as the first line of the
message.
The message text was
line 1
line 2
end line
The Ctlr-A INTL line was added by the Fidonet MSGED.
NOTE: The terminator character of the text portion of the
Fidonet message is an ASCII NUL character. This can be seen in
the second byte of the last line.
50 61 74 20 54 65 72 72-79 00 00 00 00 00 00 00 Pat Terry.......
00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
00 00 00 00 55 55 43 50-00 69 65 00 00 00 00 00 ....UUCP.ie.....
00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00-67 72 65 65 74 69 6E 67 ........greeting
73 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 s...............
00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
32 30 20 4A 61 6E 20 38-39 20 31 30 3A 35 35 3A 20 Jan 89 10:55:
30 33 00 00 00 00 01 00-13 00 00 00 EA 01 02 00 03..........j...
00 00 00 00 00 00 00 00-00 00 01 01 00 00 01 49 ...............I
4E 54 4C 20 31 3A 31 30-35 2F 36 20 32 3A 34 39 NTL 1:105/6 2:49
30 2F 31 39 0D 0A 54 6F-3A 20 6C 61 77 72 69 65 0/19..To: lawrie
40 76 61 78 2E 6F 69 74-2E 75 64 65 6C 2E 65 64 @vax.oit.udel.ed
75 0D 0A 6C 69 6E 65 20-31 0D 0A 6C 69 6E 65 20 u..line 1..line
32 0D 0A 65 6E 64 20 6C-69 6E 65 0D 0A 0D 0A 0D 2..end line.....
0A 00 63 68 61 73 65 64-20 4D 6F 64 62 61 73 65 ..chased Modbase
A
|
|
This is the terminator of the text.
Note that there is some junk left in buffers. It would be
preferable to clear the smaller ones (eg the UUCP is
nul-terminated, but then has a leftover 'ie')
1 7.6 Example of a Cyber Message in the Fidonet Out Queue
-------------------------------------------------------
The following message was created on RUPLA:-
1 To: jim.jones%mit.edu@relay.cs.net
2 Return-path: <Ccml.Rupla@f19.n490.z2.fidonet.org>
3 Received: from RURES by f19.n490.z2.fidonet.org;
4 Wed, 04 Jan 89 17:05:43 +0200 (SAST)
5 Received: from RUPLA by RURES ;
6 Wed, 04 Jan 89 09:23:44 +0200 (SAST)
7 Date: Wed, 04 Jan 89 09:22:20 +0200 (SAST)
8 From: "CCML@RUPLA"
9 <Ccml.Rupla@f19.n490.z2.fidonet.org>
10 Subject: Test message
11 To: jim.jones%mit.edu@relay.cs.net
12
13 Testing the mail system
14
1 When it is in the Fidonet message area, ready to be sent by the
Fidonet mailing system, it has this format:-
43 63 6D 6C 20 52 75 70-6C 61 00 00 00 00 00 00 Ccml Rupla......
00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
00 00 00 00 55 55 43 50-00 00 00 00 00 00 00 00 ....UUCP........
00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00-54 65 73 74 20 6D 65 73 ........Test mes
73 61 67 65 00 00 00 00-00 00 00 00 00 00 00 00 sage............
00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
32 35 20 4A 61 6E 20 38-39 20 31 31 3A 31 39 3A 25 Jan 89 11:19:
30 35 00 00 00 00 06 00-13 00 00 00 EA 01 69 00 05............i.
00 00 00 00 00 00 00 00-00 00 03 01 00 00 01 49 ...............I
4E 54 4C 20 31 3A 31 30-35 2F 36 20 32 3A 34 39 NTL 1:105/6 2:49
30 2F 31 39 0D 0A 54 6F-3A 20 20 20 20 20 20 20 0/19..To:
6A 69 6D 2E 6A 6F 6E 65-73 25 6D 69 74 2E 65 64 jim.jones%mit.ed
75 40 72 65 6C 61 79 2E-63 73 2E 6E 65 74 0D 0A u@relay.cs.net..
52 65 74 75 72 6E 2D 70-61 74 68 3A 20 3C 43 63 Return-path: <Cc
6D 6C 2E 52 75 70 6C 61-40 66 31 39 2E 6E 34 39 ml.Rupla@f19.n49
30 2E 7A 32 2E 66 69 64-6F 6E 65 74 2E 6F 72 67 0.z2.fidonet.org
3E 0D 0A 52 65 63 65 69-76 65 64 3A 20 66 72 6F >..Received: fro
6D 20 52 55 52 45 53 20-62 79 20 66 31 39 2E 6E m RURES by f19.n
34 39 30 2E 7A 32 2E 66-69 64 6F 6E 65 74 2E 6F 490.z2.fidonet.o
72 67 3B 0D 0A 20 20 20-20 20 20 20 20 20 20 57 rg;.. W
65 64 2C 20 30 34 20 4A-61 6E 20 38 39 20 31 37 ed, 04 Jan 89 17
3A 30 35 3A 34 33 20 2B-30 32 30 30 20 28 53 41 :05:43 +0200 (SA
53 54 29 0D 0A 52 65 63-65 69 76 65 64 3A 20 66 ST)..Received: f
72 6F 6D 20 52 55 50 4C-41 20 62 79 20 52 55 52 rom RUPLA by RUR
45 53 20 3B 0D 0A 20 20-20 20 20 20 20 20 20 20 ES ;..
57 65 64 2C 20 30 34 20-4A 61 6E 20 38 39 20 30 Wed, 04 Jan 89 0
39 3A 32 33 3A 34 34 20-2B 30 32 30 30 20 28 53 9:23:44 +0200 (S
41 53 54 29 0D 0A 44 61-74 65 3A 20 20 20 20 20 AST)..Date:
57 65 64 2C 20 30 34 20-4A 61 6E 20 38 39 20 30 Wed, 04 Jan 89 0
39 3A 32 32 3A 32 30 20-2B 30 32 30 30 20 28 53 9:22:20 +0200 (S
41 53 54 29 0D 0A 46 72-6F 6D 3A 20 20 20 20 20 AST)..From:
22 43 43 4D 4C 40 52 55-50 4C 41 22 0D 0A 20 20 "CCML@RUPLA"..
20 20 20 20 20 20 20 20-3C 43 63 6D 6C 2E 52 75 <Ccml.Ru
70 6C 61 40 66 31 39 2E-6E 34 39 30 2E 7A 32 2E pla@f19.n490.z2.
66 69 64 6F 6E 65 74 2E-6F 72 67 3E 0D 0A 53 75 fidonet.org>..Su
62 6A 65 63 74 3A 20 20-54 65 73 74 20 6D 65 73 bject: Test mes
73 61 67 65 0D 0A 54 6F-3A 20 20 20 20 20 20 20 sage..To:
6A 69 6D 2E 6A 6F 6E 65-73 25 6D 69 74 2E 65 64 jim.jones%mit.ed
75 40 72 65 6C 61 79 2E-63 73 2E 6E 65 74 0D 0A u@relay.cs.net..
0D 0A 54 65 73 74 69 6E-67 20 74 68 65 20 6D 61 ..Testing the ma
69 6C 20 73 79 73 74 65-6D 0D 0A 0D 0A 0D 0A 00 il system.......
1 8. Relaying Incoming Mail from Fidonet
--------------------------------------
The Fidonet PC is to be set up initially as a private Fidonet
system, that will not register any users who dial in. No BBS
features will be provided, nor will mail be received from any
other Fidonet PC unless this is specifically allowed. The
potential for a hacker to get into this system is to be regarded
as very high, and international calls are very expensive. In
due course this restriction will be eased, particularly if we
can allow CDCNET passthrough to let campus users get to the BBS.
Also, mailing to and from other Fidonets directly has much to
offer us, so we will work towards this once we have the basic
international traffic operational.
All mail that comes into Fidonet must be processed
automatically, with no need for human intervention. This mail
falls into two classes, viz:-
that destined for the RSCS network,
and
all other mail.
That destined for the RSCS network is to be forwarded to the
RURES host, and the other is to be treated as undeliverable.
Mail destined for the RSCS network is recognised by the Fidonet
'toUserName' field having the form
user host {NB A space is the separator}
The fields 'user' and 'host' are each between 1 and 8 characters
long, as for an RSCS nodename.
All of the RSCS mail must be forwarded to RURES, which will do
any trapping of mail that cannot or should not be delivered,
and will generate the undeliverable replies to the sender.
The timing of the forwarding process must be determined by the
PC. It is desireable to forward the mail as soon as possible
after receipt, consistent with maintaining a very reliable
service on the Fidonet network. Give an awkward decision about
when to do what, the Fidonet system shall be given much more
consideration and sympathy than the RSCS system. The time
schedules, protocol standards etc etc of Fidonet must pre-empt
the RURES connection and operation if necessary. The guideline
is that our Fidonet must be 'well-behaved' and 'socialble' as
far as other Fidonets are concerned, and must not create a
situation whereby it causes grief to other Fidonet nodes.
1 8.1 Munging by the PC
---------------------
The RSCS mail must be munged before it is forwarded to RURES. A
message to RFC 822 standards must be generated as a stand-alone
file on the PC and put into a queue for delivery to RURES. The
munging process is as follows, with the sequence of fields to
be:-
Return-path: {the address to be used by RURES to return the
message should it be undeliverable. Recall that
the Fidonet PC is to be all but invisible to the
process}
Received: by f19.n490.z2.fidonet.org
for 'toUserName'
from origzone : 'origNode' / 'origNet'
with {whatever Fido protocol was used}
with {release level of munging program}
via {story from the INTL line, if present}
; {date-time stamp with PC clock}
Date: {from the Fidonet 'dateTime' field}
From: {same as 'Return-path:' above}
Subject: {from the Fidonet 'subject:' field}
To: {from the Fidonet 'toUserName' field with the
'.' changed to an '@'}
X-cost: {in ASCII text form from the Fidonet 'cost'
field}
Text: {Taken exactly as is from the Fidonet 'text'
field. A blank line separates the text from
the header. The INTL is removed. CRs are
treated as CRLF. Tabs are treated as a single
space. All other control characters are
discarded.}
1 8.2 The RURES Process
---------------------
When RURES receives a message file from the PC, it will add a
'Received:' line similar to this:-
Received: from f19.n490.z2.fidonet.org by RURES
via {Cyber comms port if it can be identified
by the Cyber program}
with {name+release level of Cyber program}
; date-time
It is not necessary to adjust the 'Return-path:' field, as the
PC set this up correctly relative to RURES.
Having got the message this far, RURES now checks against the
file containing the list of hosts permitted to receive mail via
Fidonet. This list will consist initially only of hosts RURES,
RUPLA and RUPHYS. (ie hosts located on the Rhodes campus for
use by Rhodes University). This list must be maintained in a
protected file under user RELAY on RURES. Mail that is received
for other hosts shall be treated as undeliverable, with no hint
whatsoever that a barring process exists.
The Cyber receiving program will then run a process similar to
that used by the RURES MAIL command, and either deliver the
message to the RURES mail files, or send it out on the RSCS
network, as appropriate. Problem messages (eg undeliverables)
are sent to user RELAY with appropriate text for return via
Fidonet.
1 8.3 Sample Received File from the Internet
------------------------------------------
The following message was received by the Fidonet PC, having
been sent from UDEL:-
Sending:-
To: mailer!<ccml.rures%f19.n490.z2.fidonet.org@udel.edu>
Subject: Test to ccml.rures
From: lawrie@vax.oit.udel.edu
Sent to } Five
} lines
ccml.rures%f19.n490.z2.fidonet.org@udel.edu } of
} message
17/01/89 17:10 SAST } text.
Received by Fidonet:-
55 75 63 70 00 00 00 00-00 00 00 00 00 00 00 00 Uucp............
00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
00 00 00 00 43 63 6D 6C-20 52 75 72 65 73 00 00 ....Ccml Rures..
00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00-54 65 73 74 20 74 6F 20 ........Test to
63 63 6D 6C 2E 72 75 72-65 73 00 00 00 00 00 00 ccml.rures......
00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
31 37 20 4A 61 6E 20 38-39 20 30 39 3A 31 33 3A 17 Jan 89 09:13:
31 32 00 00 00 00 13 00-06 00 00 00 69 00 EA 01 12..........i.j.
00 00 00 00 00 00 00 00-00 00 81 00 00 00 01 49 ...............I
4E 54 4C 20 32 3A 34 39-30 2F 31 39 20 31 3A 31 NTL 2:490/19 1:1
30 35 2F 36 0D 46 72 6F-6D 3A 20 6F 72 65 73 6F 05/6.From: oreso
66 74 21 75 75 6E 65 74-21 76 61 78 2E 6F 69 74 ft!uunet!vax.oit
2E 75 64 65 6C 2E 65 64-75 21 6C 61 77 72 69 65 .udel.edu!lawrie
20 28 4D 49 4B 45 20 4C-41 57 52 49 45 29 0D 0A (MIKE LAWRIE)..
54 6F 3A 20 20 20 22 63-63 6D 6C 2E 72 75 72 65 To: "ccml.rure
73 25 66 31 39 2E 6E 34-39 30 2E 7A 32 2E 66 69 s%f19.n490.z2.fi
64 6F 6E 65 74 2E 6F 72-67 22 20 3C 63 63 6D 6C donet.org" <ccml
2E 72 75 72 65 73 25 66-31 39 2E 6E 34 39 30 2E .rures%f19.n490.
7A 32 2E 66 69 64 6F 6E-65 74 2E 6F 72 67 40 55 z2.fidonet.org@U
44 45 4C 2E 45 44 55 3E-0D 0A 44 61 74 65 3A 20 DEL.EDU>..Date:
31 37 20 4A 61 6E 20 38-39 20 31 30 3A 32 30 3A 17 Jan 89 10:20:
30 30 20 45 53 54 0D 0A-0D 0A 20 20 0D 0A 53 65 00 EST.... ..Se
6E 74 20 74 6F 0D 0A 20-20 0D 0A 63 63 6D 6C 2E nt to.. ..ccml.
72 75 72 65 73 25 66 31-39 2E 6E 34 39 30 2E 7A rures%f19.n490.z
32 2E 66 69 64 6F 6E 65-74 2E 6F 72 67 40 75 64 2.fidonet.org@ud
65 6C 2E 65 64 75 0D 0A-20 20 0D 0A 31 37 2F 30 el.edu.. ..17/0
31 2F 38 39 20 31 37 3A-31 30 20 53 41 53 54 0D 1/89 17:10 SAST.
0A 2D 2D 2D 2D 2D 2D 0D-0A 0D 0A 01 56 69 61 20 .------.....Via
44 75 74 63 68 69 65 20-31 3A 31 30 35 2F 36 20 Dutchie 1:105/6
54 75 65 20 4A 61 6E 20-31 37 20 32 33 3A 31 37 Tue Jan 17 23:17
3A 35 33 20 31 39 38 39-20 55 54 43 0D 04 8A F9 :53 1989 UTC...y
EB 02 32 FF 2E 3A 1E 8B-05 76 04 8A D9 EB 02 32 k.2..:...v..Yk.2
DB E8 D4 00 FF 74 14 FF-74 12 FF 74 14 FF 74 12 [hT..t..t..t..t.
26 8F 06 0A 00 26 8F 06-0C 00 33 C0 8E D8 8F 06 &....&....3@.X..
88 00 8F 06 8A 00 52 1E-2E 8E 1E 89 05 BA 80 00 ......R......:..
B4 1A CD 21 1F 5A 2E F6-06 52 05 01 74 26 2E C5 4.M!.Z.v.R..t&.E
36 5D 05 2E C4 3E 4E 05-26 8C 5D 10 4E 4E 89 1C 6]..D>N.&.].NN..
1 9. NOS to FIDO Mail Munging
---------------------------
Introduction:
This process is done by a PC program (NOS2FIDO) which acts on a
mail message file which has been transferred from the RURES
Cyber. It produces single '.MSG' files in the FSC0001-8 format
and places them in the FIDO netmail directory for handling by
the Fido system.
NOS mail file:
The file containing NOS mail messages will be in the '\XFERNOS'
directory, and is named 'MAILFID.TXT'. It is a normal flat
ASCII file, and is read a single character at a time by the
NOS2FIDO program. If the file is empty, no processing will take
place. The format of this file will be as specified in the
document MAIL000 section on Fido message munging. The file may
contain zero, one, or many messages, with each message being
separated by a '.' (fullstop) at the beginning of a text line
(that is, a CRLF followed by a fullstop followed by zero, one,
or many blanks, followed by a CRLF). This is not an RFC 822
requirement, but has been included to enable many messages to be
transferred in one Cyber file.
NOS node file:
When 'MAILFID.TXT' is transferred to the PC, the file
'NODEFIL.TXT' is also transferred. This contains a list of
valid node names. A message will only be munged and forwarded
by NOS2FIDO if the 'from' field contains a valid node name (ie.
one in the latest transferred node file). The format of this
file will be as follows:
111111111122222222223
0123456789012345678901234567890
NODE NAME x<---- text ------- - - - ---->CRLF
with 'x' in column 11 being either blank or a '+' if the
node name is valid (ie. we can forward messages from this
node). Column 12 onwards to the end of the line is ignored.
PC mail files:
The program will add files to the existing set of '.MSG' files
by checking for the highest numbered file, and then creating new
files for each NOS message to be in sequence from that number.
For example, if files '5.MSG', '23.MSG', and '27.MSG' exist, and
there are 2 NOS-origin messages, they will be numbered '28.MSG'
and '29.MSG'. The munged messages will be marked as
'private/crash', which means that only the addressed recipient
may read them, and they will be sent directly to the addressed
node, in this case 1:105/6. The messages will not be
automatically deleted after being sent (at this stage, anyway).
The munging program will place these files in the
'\FIDO\FIDOMSG' directory, which is the netmail area for
FidoNet. 'Gaps' in the message numbers will not be used, as new
message numbers will be generated starting at the highest
existing message number.
1 Addressing:
At this stage, all message files accepted from NOS for
processing by NOS2FIDO will be sent to user 'UUCP' at 1:105/6,
with a generated <CTRL-A>INTL 1:105/6 2:490/19 as the first line
of the text part of message, and a To: with the user-supplied
recipient address as the second line of the text part of the
message, followed by a blank line.
Processing:
The NOS2FIDO program will read the MAILFID.TXT file until it
detects an end-of-message. Header fields are picked up as they
are recognised, with the system not expecting the fields to be
in any particular order. It does expect to find a 'to',
'from' and 'date' field somewhere in the header. It will not
matter if those are the only header fields in the message. Once
these three mandatory fields have been picked up, and the
program has also picked up a blank line, and the next line
does not contain a recognisable header literal, all remaining
lines in the message will be accepted as part of the text of
the message, up to but not including the end-of-message, or
an end-of-file. Remember that end-of-message is indicated by
a fullstop alone at the beginning of a line. The program will
examine the text of the message for lines beginning with two
fullstops, and will remove the extra fullstop. This will be
to ensure transparency of message text.
Once a complete message has been read from the MAILFID.TXT file,
the program will build an amended return-path which includes the
local Fido details, and will also generate a received line
giving details of sender node, receiver node, program name and
version, and date and time. This return-path and received line
will form lines 4, 5 and 6 of the text part of the message.
The complete message will then be written as the appropriate
.MSG file in the NETMAIL directory, and the program will go on
to process the next message in the 'MAILFID.TXT' file. If
end-of-file is encountered, the program simply exits and when
the system returns control to Fido the munged messages are
handled automatically by the Fido system.
1 10. FIDO to NOS Mail Munging
----------------------------
Introduction:
This process is done by a PC program FIDO2NOS, which looks for
messages in the Fido netmail directory '\FIDO\FIDOMSG'. If any
unsent messages are found, the program will, after munging, set
them up for tranfer to the RURES Cyber as the 'MAILNOS.TXT'
file. If there are no new messages for transfer, the system
will set an appropriate ERRORLEVEL value to bypass the connect
and transfer process.
Fido mail files:
These files are in the same FSC0001-8 format as for the previous
process, with fixed length 'from', 'to', 'subject', 'date', and
control fields (attribute, cost, origin net/node, destination
net/node).
The program will flag any processed messages (via the attribute
word) as 'sent' so that they will not be reprocessed the next
time the program is run. All messages that have not been
flagged in this way will be munged and forwarded to the Cyber.
Note that only messages with a destination net/node matching
the Rhodes Fido node will be forwarded. The system will also
ignore any messages that have been sent from RURES to Fido.
Multiple messages are separated in the same way as for the
'MAILFID.TXT' file, that is, they are separated by a single
fullstop at the beginning of a text line. The text of the
message will be examined for single fullstops at the beginning
of lines, and an extra fullstop will be inserted on that line to
ensure message text transparency.
NOS mail file:
The FIDO2NOS program will build up the 'MAILNOS.TXT' file by
appending munged messages to it, with end-of-message separators.
A 'MAILNOS.TXT' file will be built up in the \FIDO\FIDOMSG
directory, and when FIDO2NOS is complete, will be copied to the
\XFERNOS directory for later transfer to the RURES Cyber. It
will not overwrite any existing information in the
\XFERNOS\MAILNOS file - any clearing of this file must be done
after a successful transfer of its contents has taken place.
Addressing:
FIDO2NOS will use the Fido header fields to generate an addition
to the return-path, if one exists, or build a return-path with
these fields if one does not already exist. It will also
generate a received field, with details of origin net/node,
processing node, program name and version, and date and time.
The return-path and generated received will form the first 3
lines of each message in the 'MAILNOS.TXT' file.
The program will examine the first few lines of the body of
the message (up to the first blank line) for an RFC822 type
message header. If found, the 'from' and 'to' and 'return-path'
fields from this header will be used to generate headers to
for the mail message to be transferred to RURES.
1 The 'to' user field is examined for an embedded blank.
If a blank is found, the blank is changed to an '@'. Examples
of this can be found in MAIL000, under section 'Relaying
Incoming Mail from FidoNet'.
Processing:
The text of the message is examined for control characters,
which are removed if present, and the <CTRL-A>INTL line is
removed if it is present. The 'MAILNOS.TXT' file will be placed
in the \XFERNOS directory for later transfer. The text is
also examined for two fullstops at the beginnning of a line,
in which case the extra fullstop will be removed.
1 Appendix A: Mail Flows at RUPHYS
--------------------------------
+==============================================================+
| R U P H Y S |
+==============================================================+
+--------------------------+ +--------------------+
| Addressed to | | Local Mail Files |
+==========================+ +====================+
| Justin |----------->| Justin |
+--------------------------+ +--------------------+
| ccml@rures |-->+ +-->| Justin |
+--------------------------+ V A +--------------------+
| Jim%MIT@rures |-->+ |
+--------------------------+ V |
| ccrs@rupla |-->+ | +--------------------+
+--------------------------+ V | | RSCS from RURES |
| xyz012@witsvma |-->+ | +====================+
+--------------------------+ V +<--| Justin@ruphys |
| +--------------------+
|
|
+--------------------------+ |
| Queued for RURES | |
+==========================+ V
| ccml@rures |<--+
+--------------------------+ V
| Jim%MIT@rures |<--+
+--------------------------+ V
| ccrs@rupla |<--+
+--------------------------+ V
| xyz012@witsvma |<--+
+--------------------------+
1 Appendix B: Mail Flows at RUPLA
-------------------------------
+==============================================================+
| R U P L A |
+==============================================================+
+--------------------------+ +--------------------+
| Addressed to: | | Local Mail |
+==========================+ +====================+
| ccrs |-------->| ccrs |
+--------------------------+ +--------------------+
| ccrs@rupla |-------->| ccrs |
+--------------------------+ +--------------------+
| ccml@rures |-->+ | ccrs |<-+
+--------------------------+ V +--------------------+ A
| Jim%MIT@rures |-->+ |
+--------------------------+ V |
| xyz012@witsvma |-->+ |
+--------------------------+ | |
+<| Justin@ruphys | | |
| +--------------------------+ | |
| | |
| | |
| | |
| +--------------------------+ | |
| | Queued for RURES | | |
| +==========================+ V |
| | ccml@rures |<--+ |
| +--------------------------+ V +--------------------+ |
| | Jim%MIT@rures |<--+ | RSCS from RURES | |
| +--------------------------+ V +====================+ |
| | xyz012@witsvma |<--+ | ccrs@rupla |->+
| +--------------------------+ +--------------------+
| | ccml@rures |<--------| ccml@rures |
| +--------------------------+ +--------------------+
| | Jim%MIT@rures |<--------| Jim%MIT@rures |
| +--------------------------+ +--------------------+
| | xyz012@witsvma |<--------| xyz012@witsvma |
| +--------------------------+ +--------------------+
| | Justin@ruphys |<--------|-Justin@ruphys |
V +--------------------------+ +--------------------+
+>| Justin@ruphys |
+--------------------------+
1 Appendix C: Mail Flows at RURES
-------------------------------
+==============================================================+
| R U R E S |
+==============================================================+
+--------------------+ +--------------------+
| Addressed to | | Local Mail |
+====================+ +====================+
| ccml |------------>| ccml |
+--------------------+ +--------------------+
| ccml@rures |------------>| ccml |
+--------------------+ +--------------------+
| Jim@MIT |------------>| relay |
+--------------------+ +--------------------+
| Justin@ruphys |---->+ | relay |<---+
+--------------------+ | +--------------------+ A
| ccrs@rupla |->+ | | ccml |<---+
+--------------------+ | | +--------------------+ A
+<| xyz012@witsvma | | | | relay |<-+ |
| +--------------------+ | | +--------------------+ A |
| | | | ccml |<-+ |
| | | +--------------------+ A |
| | | +->| ccml | | |
| +--------------------+ | | A +--------------------+ | |
| | Queued for RUPLA | | | | | |
| +====================+ V | | +--------------------+ | |
| | ccrs@rupla |<-+ | | | RSCS from PUKVM1 | | |
| +--------------------+ | | +====================+ | |
| | ccrs@rupla |<----)-+ +<-| ccml@rures | | |
| +--------------------+ | \ +--------------------+ | |
| | ccrs@rupla |<-+ | <---| ccrs@rupla | | |
| +--------------------+ A | +--------------------+ | |
| | | +<--| Justin@ruphys | | |
| +--------------------+ | | | +--------------------+ | |
| | Queued for RUPHYS | | | | | Jim%MIT@rures | | |
| +====================+ | V | +--------------------+ | |
| | Justin@ruphys |<-)--+ | V | |
| +--------------------+ | V **DO NOT DELIVER** | |
| | Justin@ruphys |<-)------+ | |
| +--------------------+ | +--------------------+ | |
| | Justin@ruphys |<-)------+ | RSCS from RUPLA | | |
| +--------------------+ | A +====================+ | |
| | +<--| Justin@ruphys | | |
| +--------------------+ | +--------------------+ | |
| | Queued for PUKVM1 | | | Jim%MIT@rures |->+ |
V +====================+ | +--------------------+ A |
+>| xyz012@witsvma | | | ccml@rures |->+ |
+--------------------+ | +--------------------+ |
| xyz012@witsvma |<-)----------| xyz012@witsvma | |
+--------------------+ | +--------------------+ |
| xyz012@witsvma |<-)------+ |
+--------------------+ | A +--------------------+ |
| | | RSCS from RUPHYS | |
| | +====================+ |
| | | Jim%MIT@rures |--->+
| | +--------------------+ A
| | | ccml@rures |--->+
| | +--------------------+ A
| +<--| xyz012@witsvma |
| +--------------------+
+<---------| ccrs@rupla |
+--------------------+
1 Appendix D: RUCC NJEF NETWORK HOST CONFIGURATION - 10 Jan 1989
--------------------------------------------------------------
Definition for node RURES
-------------------------
+---------+
| NODE-5 |
| TEST |
| |
| |
|LID = TST|
+---------+
|
| expansion
|/| (dialup?)
|
|
+-----------+
+---------+ |+---------+| +---------+
| 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 |
A . implies two way comms |.CSIRVM |
(i.e. mutual configuration)| DNO |
| JES2 |
| UNIS |
| UZNOS |
| CCWRVM |
+---------+
|.RGNVM1 | Visible through UPVM2 (?)
+---------+
1 Appendix E: Mail Flows with Fidonet
-----------------------------------
+-------------------------+ +-------------------------+
| Fidonet receive files | | Fidonet transmit files |
| | | |
+-------------------------+ +-------------------------+
| A
V |
+-------------------------+ +-------------------------+
| Create RFC 822 mail into| | Munge into Fidonet form |
| a holding file |<-------| Reject invalid 'From:'s |
+-------------------------+ +-------------------------+
| A
V |
+-------------------------+ +-------------------------+
| Transfer reliably to | | Add a 'Received:' line |
| RURES | | |
+-------------------------+ +-------------------------+
| A
PC V | PC
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
RURES | A RURES
V |
+-------------------------+ +-------------------------+
| Separate '.'-messages | | Transfer with valid |
| Add a 'Received:' line | | host list to the PC |
+-------------------------+ +-------------------------+
| A
V |
+-------------------------+ +<-------------+
| Validate the host for | A
| permitted list, validate| |
| user if RURES | +-------------------------+ |
+-------------------------+ | RURES MAIL FILES | |
| | | | ---------------- | |
| | V +-------------------------+ |
| | +------------>| For RELAY |>+
| | (undeliverable)| | A
| | +-------------------------+ |
| V | For RURES users | |
| +--------------------->| | |
| (valid users on RURES)+-------------------------+ |
| (MAILNJF) A |
| | |
| +---------->+ |
|(RUPLA) A |
|(RUPHYS) | +-------------------------+ |
V(Maybe others) | | RSCS from all hosts | |
+-------------------------+ | | ------------------- | |
| RSCS using NJROUTE | | +-------------------------+ |
| | +<-| For RURES users | |
+-------------------------+ | | |
A +-------------------------+ |
| | For RELAY from valid |>+
| | hosts. MAILNJF |
| +-------------------------+
+<----------------------| For RURES invalid users |
A ('User unknown') | |
| +-------------------------+
+<----------------------| For RELAY from invalid |
('User unknown') | hosts. Undeliverable. |
+-------------------------+
1 MAIL000 swf 9 73; sj y
----------------------
MAIL000 ends
_