From ZaInternetHistory
1 MAIL007
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
-------------------------------
P R O V I S I O N A L
Changes Desired to be made to MAIL 2.2
--------------------------------------
21 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 provisional specification, put out to form a basis for
creating ideas. It is not a final specification, 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. |
| |
+--------------------------------------------------------------+
+--------------------------------------------------------------+
| N O T E N O T E N O T E N O T E N O T E |
| ================================================ |
| |
This document, MAIL007, is intended to be an extract from the |
definitive document MAIL000. The idea is to explain here the |
changes necessary to MAIL 2.2 (ie the program(s) that run when |
the user generates mail on the RURES or the RUPLA Cybers. At |
all times, the document MAIL000 must be the 'superior' |
document. |
| |
It is quite possible that changes specified in MAIL007 conflict|
with the contents of MAIL000. This can happen because (a) |
MAIL007 is in error (b) MAIL000 is in error. Either way, the |
documents must be brought into line. Maintaining MAIL000 is |
not a trivial exercise, as it spawns several other documents, |
but it is important that it is maintained. Please report any |
conflicts that you find. Many thanks. Mike Lawrie. |
| |
| |
+--------------------------------------------------------------+
1 Contents
--------
1. Purpose
2. Priority Classification
3. Review of MAIL 2.2
3.1 Sending Mail
3.2 Receving Mail
4. Changes Needed
4.1 The 'To:' Line
4.1.1 Extended 'To:' Line. Priority A
4.1.2 The 'To:' Line to use Mailnames. Priority B
4.1.3 Aliasing. Priority B
4.1.3.1 Structure of Alias Information
4.1.3.2 Example of a Mail Alias File
4.1.3.3 Maintenance of the Alias File
5. Current Message Read Concept. Priority C
6. Deleting Messages. Priority B
7. Reply Command. Priority C
8. Extra Header Lines. Priority C
8.1 Sender and From. Priority C
9. Adding the Hostname to the 'To:'. Priority B
10. Processing the 'To:' Line. Priority A
10.1 The 'To:' Line on RURES. Priority A
10.2 The 'To:' Line on RUPLA. Priority A
11. Order of Header Fields. Priority B
12. Message Numbering. Priority C
13. Tracing Received Mail. Priority B
1 1. Purpose
----------
This document spells out the changes that are required to be
made to the Cyber mailing system, version 2.2.
2. Priority Classification
--------------------------
The classification of priority for the changes is:-
A to be done in the next release (3.0) urgently,
B include in next release only if it is trivial
to do, otherwise it waits until second change,
C to be done in the final release, possibly in
several stages.
3. Review of MAIL 2.2
---------------------
The mailbox mechanism is spelt out in document MAIL000. Two
files form the kernel of the system, MAILPOI and MAILMES.
3.1 Sending Mail
----------------
The dialog when sending a message is as follows:-
1. /mail
2.
3.
4.
5. RHODES UNIVERSITY MAILING SYSTEM
6. Version 2.2
7.
8. There are no messages for you.
9. S)end...Q)uit..s
10. To: ccml
11. Subject: Testing
12. Type in a message terminated with TWO blank lines
13. or specify a filename preceded with '@'
14. or press ENTER to use FSE to create the message.
15. > Line 1
16. > Line 2
17. > Line 3
18. > Line 4
19. >
20. >>
21. <<Sending...>>
22. YOUR MESSAGE HAS 10 LINES
23. MAIL SENT
24. There is one message for you.
25. R)ead...S)end...Q)uit...q
26. MAIL(X)
27. /
1 The process works as follows:-
----
a) The MAIL command invokes a mail-generator / mail-reading
program. The send option is selected. This generates a PROC
according to
(i) the destination node,
and (ii) the method to be used to create the body of the
message.
b) The header and body of the message are assembled by the
PROC, the message is sent to its destination, and the MAIL
command is invoked with a parameter to prevent the banner text
from being displayed. This gives the impression that the MAIL
command is always being executed.
----
The options for version 2.2 of the MAIL program are
(i) Send mail to the local Cyber (using MAILSND), or
send it via the RSCS network (using NJROUTE).
(ii) Create the body of text by direct input, by using
FSE, or by copying a file.
In whichever way the body of the message is created, it is
stored in the file WWWWBDY, which remains local to the user
after the mail is sent. Almost all other files 'disappear'
behind the user's back.
The message creation date (the 'Date:' line) and the 'From:'
line are generated automatically in a 'hidden' file (WWWWHDR),
so that the user gets no chance to modify them. It is very
important that these lines are authentic.
The files WWWWHDR and WWWWBDY are then copied into file
ZZZZITM, which is the final message that gets sent. Control of
this is done by a .PROC called WWWWPRC.
The message that is sent, whether sent to the local mail files
or to the RSCS system, is to a standard that is very close to
that laid down in RFC 822.
1 3.2 Receving Mail
-----------------
The dialog when receiving a message is as follows:-
1. /mail
2.
3.
4.
5. RHODES UNIVERSITY MAILING SYSTEM
6. Version 2.2
7.
8. There is one message for you.
9. R)ead...S)end...Q)uit...r
10. ------------------------------------------------------------
11. Received 11/01/89 at 11:19:33
12.
13. Date: Wed, 11 Jan 89 11:19:16 +0200 (SAST)
14. To: CCML
15. From: <CCML@RURES>
16. Subject: Testing
17.
18. Line 1
19. Line 2
20. Line 3
21. Line 4
22.
23.
24.
25. R)ead...C)opy...K)ill...c
26. Filename for message (RETURN to ignore)...INMAIL2
27.
28. R)ead...C)opy...K)ill...k
29. There are no messages for you.
30. S)end...Q)uit..q
31. MAIL.
32. /
The reading of mail is done by the same program that controls
the generating of mail. When a message is read, it is
displayed line by line, racking up the screen. Every 20 lines
or so there is a continue-or-stop pause.
The message to be read is decided by the mail program. It is
the next message in order of reception, and the user has no
choice in the matter. Once a message has been read (even only
partially), it can be re-read as many times as required, and it
can be copied into as many files as the reader chooses, but
before leaving the MAIL command, or doing anything more
constructive with the mail system, the reader must delete the
message.
At the start of the display of a message, three extra lines are
inserted. These are a line of minuses, a line showing the date
when the message was stored in the mail files, and a blank
line, ie lines 10, 11 and 12 in the above example.
Messages that arrive from the RSCS system are also read in this
way. The reading process does not distinguish between the
source hosts of the messages.
1 4. Changes Needed
-----------------
4.1 The 'To:' Line
------------------
4.1.1 Extended 'To:' Line. Priority A
-------------------------------------
It is necessary to be able to send mail to long and complex
addresses. The present system allows only up to 8 characters
for the name of the recipient. This must be extended in keeping
with international addresses, as laid down by RFC 822.
4.1.2 The 'To:' Line to use Mailnames. Priority B
-------------------------------------------------
The mailbox on the Cyber is identified by NOS username. It
would be better to identify mail in a more personalised way.
Therefore have a file of mail usernames that identify the user,
and cause the mail programs to do a lookup to match this
mailname against username. This file will initially hold two
fields, a mailname and a username. Lookup must be possible in
either direction because the RSCS receiving process will need to
lookup the other way, as may other programs. Lookup must be
case insensitive, but case as typed by the user must be
preserved.
Installation of this change must go hand in glove with making
the 'From:' line substitute the sender's mailname, not as at
present the username. Clearly, mail sent from CCML must be
returned to CCML. So, when CCML sends mail to a mailname, that
recipient must see 'From: MLawrie' (or whatever the sender's
mailname is) so that the reply is addressed to MLawrie (but
stored so that only username CCML can read it)
Allowance must be made for the existence of knowledge that
mailnames are currently usernames. So, for some time there must
be ways to deliver mail to CCML even though it should have been
addressed to MLawrie. The point is, the change to mailnames
will not be known by all network users at the instant that the
cutover takes place. Also, some mail systems use a REPLY
command to generate the 'To:' line, so anyone reading some old
mail and then using REPLY (ie on a remote computer) will
generate a 'To:' line for CCML, as the old mail (6 month's old?)
was sent from CCML, not from MLawrie.
The solution to the above problem must not lie in multiple
copies of mailname records, but rather in searching for the
recipient in the mailname fields, and if not found, look in the
username fields. Thus there is no need for remote senders ever
to change. (The hope is that they will, mailnames are much
nicer than usernames.)
1 As a installation 'crutch', initialise this system so that the
username and the mailname are identical. The system will then
be transparent to the average user, and it will be possible to
set special mailname/username combinations for testing.
A mail user who does not have a mailname must be barred from the
system, with a polite message.
In due course, a great deal more information on each user will
be held. See RFCs on WHOIS/NICNAME for an indication of what
might be held. Also, the Computing Centre might require further
information to be held. Therefore do nothing in the design of
this file to prevent considerable extension.
There might also be attribute or permission fields associated
with the mailname. Do nothing in the design to make this
difficult to implement at a later stage.
The updating of this file needs to be designed. A process of
picking up information from the user application form should be
introduced, as well as a POG (powers of god) mechanism. A good
future for this one is an offline system on a PC database
maintained by the Secretary, with periodic downloading to the
Cyber.
1 4.1.3 Aliasing. Priority B
--------------------------
It is cumbersome for a user to have to type a full address when
addressing mail. A method must be set up whereby the user can
set up a file of aliases, so that a full address is substituted
in response to the 'To:' prompt.
In addressing mail, the addressee must be searched for in the
alias file first, and only if it is not found there must the
text typed as the addressee be used.
NOTE: It is envisaged that the initial alias system, to be used
for testing, will have a simple facility for inputting and
deleting aliases from an alias file. Initially, no facility
will exist for viewing alias information, or editing existing
alias definitions. Until such time as existing alias
definitions can be viewed, the alias name will be stored in
upper case, thus allowing for case insensitive searches for the
alias name (ie the user can type Ian/IAN/ian ... etc to use the
same alias).
However, space has been left to allow the alias name to be
stored as 6/12-bit characters so that, when neccessary, we can
allow for case sensitive alias names (ie the alias "Ian" is
different from "IAN" which in turn is different from "ian" etc).
Alias definition files created with alias names in upper case
will have to be re-created to have case-sensitive alias names.
This is not something that we want general MAIL users to do.
Thus, if case-sensitive alias names are to be incorporated in an
alias facility, this aspect of the alias facility must be up and
running before aliasing is released for general usage.
4.1.3.1 Structure of Alias Information
--------------------------------------
The idea is to allow the mail system to use a more user-friendly
form of addressing mail, and at the same time to allow the
sender to keep copies of mail that he sends.
The user will be able to respond to the 'To:' prompt of the mail
system with either a literal network address (eg 'user@host') or
with an alias (eg 'Jim'). The alias file will always be
searched when an address is typed. Only if a match is not found
will the literal value be used.
Aliases will be stored in a user's filespace, in a direct-access
index-sequential file named MAILALI. An indirect-access file
called MAILKEY will be used as an alternate key file. Thus each
user will have a personal set of aliases stored in his
filespace. A utility program is used to maintain the data in
the file. An indefinite number of addressees may be held
against one alias to form a mailing list.
NOTE: For the initial alias facility will only cater for
aliases for individuals, i.e. only one netaddress will be
stored per alias name.
1 Information will be extracted from the alias file in the same
case as entered by the user, and will be displayed in that same
case. Noting again, that for the initial system, alias names
will be stored in upper case only. Enough space has been left
to expand the alias name field so that it can be used for upper-
and lower-case (6/12-bit) characters without the format of the
file needing to be changed.
The method of maintaining this alias file is given later.
The index-sequential file will have records of the following
format:
characters field
---------- -----
1-8 alias-name
9-16 alias-upper-case
17-18 alias-blank
19-20 alias sequence number
21-28 record-identifier
29-30 record-identifier sequence number
31-158 record-data
The primary key for the file will be characters 1-30.
Alternate Keys: Alias-name (chars 1-16)
Record-identifier (chars 21-30)
An alias is defined by all the records in the alias file that
contain the same alias-name. It is possible to have aliases for
individuals or for groups (collections of individuals). An
alias defined for a group facilitates the sending the same
message to a number of addressee's (eg all Computing Centre
staff).
The key to the fields used in the alias records is as follows:
alias-name In the case of an alias for an individual,
this must be a string consisting of 1 to 8
characters from the set (A-Z,0-9,"-","."),
and space-filled up to 8 characters. The
first character of the alias-name must be
from the set (A-Z). When case-insensitive
alias names are implemented, the permitted
character set will be expanded to include
(a-z).
For an alias for a group, this must be a "*"
followed by a a string consisting of 1 to 7
characters from the set (A-Z,0-9,"-","."),
and space filled up to 7 characters. When
case-sensitive alias names are implemented,
the permitted character set will be expanded
to include (a-z).
alias-upper-case provision for case-sensitive alias names
alias-blank is a string of 2 spaces.
1 alias sequence- is an integer between 01 and 99 - this is
number used to differentiate between the various
individuals specified within a group
covered by one alias-name. Each individual
defined within a group will have a unique
sequence number. In the case of an alias for
an individual, the sequence number will always
be 01.
record- is one of the following literal strings:
identifier "NETADDR " ;Substituted address
"ARCHIVE " ;Archive of mail sent
"NAME " ;real name (title optional)
"POST " ;position/postal addr
"PHONE " ;phone number
"COMMENTS" ;optional comment field
Any alias definition must have at least a
NETADDR-type record. A NAME-type record is
not compulsory, but is recommended.
All other record types are optional for an
alias definition. A netaddress can take up
to 256 ACSII characters. Each NETADDR-type
record can hold up to 64 ASCII characters,
thus we must allow for up to 4 NETADDR-type
records for each individual that is specified
within an alias.
record- is an integer between 01 and 04 which
identifier allows up to 4 NETADDR-type records per
sequence individual within an alias definition. For
number all other types of records, the record-
identifier sequence number must be 01.
record data the constraints on this field vary according
to the record type (as defined by the record-
identifier).
netaddr: (maximum of 64 ASCII characters)
The contents of this field must comply with
the mailbox definition in RFC822.
archive: (maximum of 7 ASCII characters)
The contents of this field must be a valid
NOS indirect-access file name.
name, post, phone, comments:
(maximum of 64 ASCII characters)
The contents of these fields can be any
text.
1 4.1.3.2 Example of a Mail Alias File
------------------------------------
In order to clarify the structure of an alias file, three
examples are given, showing the information to be stored for
each alias, and the way it is stored in the alias file records.
a/ A simple alias definition for an individual
alias : Mike record number
netaddr : <Mlawrie@rures> 1
archive : Miketxt 2
name : Mr M.A. Lawrie 3
post : Rhodes University, Grahamstown, 6140 4
phone : (0461) 22023 x 279 5
Records 1 to 5 of the example alias file are used to define the
alias "Mike". The alias name appears as "MIKE" in each of these
records to allow for case insensitive access. The alias
sequence number for these records is always 01 as the alias is
for an individual. All messages addressed to "Mike" (or "MIKE",
or "mike" ...etc) will be written to the archive file MIKETXT.
b/ An alias definition for a group of addressee's
This example of an alias for a group of addressee's will be used
to send mail to three persond under the alias "*CC". The
information used for the definition of the alias is as follows:
alias : *CC
netaddr : <CCFJ@RURES> 6
name : Jacot 7
archive : CCFJtxt 8
netaddr : <ccdw> 9
name : Dave Wilson 10
archive : CCDWtxt 11
netaddr : <CCRS@rupla> 12
name : Mr R.A. Scott 13
archive : Tonyfil 14
phone : 22023 EXT 279 15
Records 6 to 15 of the alias file given below contain the
definition of the alias "*cc" used for simultaneous mailing to a
group of addressees (in this case, 3 addressees). The first
addressee (name = jacot) is defined in records 6 to 8, the
second (name = Dave Wilson) is defined in records 9 to 11, and
the third (name = Mr R.A. Scott) in records 12 to 15. Each
addressee in this alias (*cc) has a unique alias sequence number
associated with the records used to define him. This is how
differentiation is made between the various sets of records used
within an alias for a group of addressees. Although, in this
case, all of the addressees within the alias have only one
NETADDR-type record each, it is possible for the different
addressees within the alias to have different numbers of
NETADDR-type records (ie any number between 1 and 4).
1 c/ An example of an alias definition with a long netaddress.
Some international electronic mail addresses may require more
than 64 characters in order to specify the netaddress. The
alias file has been set up to allow up to 256 ASCII characters
for the netaddress. Each NETADDR-type record can contain up to
64 displayed 'ASCII' characters (these ASCII characters will be
stored as 6/12-bit characters and might need up to 128 6-bit
character locations for storage). Hence, up to four
NETADDR-type records are needed per addressee. In the example
below, the netaddress needs two NETADDR-type records with
sequence numbers 01 and 02.
alias : John
netaddr : <doe@engz4.cs1. ...... .utexas.edu> 16 and 17
name : John Doe 18
Records 16 to 18 in the alias file example define the alias
"John". Two records are used for the netaddress, and one for
the name. This is the minimum number of records that can be
used to define this alias. No optional fields have been
included in the alias definition.
Sample of an alias file
-----------------------
record column numbers
numbers :
: :
V V
00000000..000000000000000000000000000000000000000 111111111
00000000..112222222222333333333344444444445555555......555555555
12345678..890123456789012345678901234567890123456......012345678
1 MIKE 01NETADDR 01<ML^A^W^R^I^E@A^R^U^R^E^S>
2 MIKE 01ARCHIVE 01M^I^K^E^T^X^T
3 MIKE 01NAME 01M^R. M.A. L^A^W^R^I^E
4 MIKE 01POST 01R^H^O^D^E^S U^N^I^V^E^R^S^......6140
5 MIKE 01PHONE 01(0461) 22023 ^X 279
6 *CC 01NETADDR 01<CCFJ@RURES>
7 *CC 01ARCHIVE 01CCFJ^T^X^T
8 *CC 01NAME 01J^A^C^O^T
9 *CC 02NETADDR 01<^C^C^D^W>
10 *CC 02ARCHIVE 01CCDW^T^X^T
11 *CC 02NAME 01D^A^V^E W^I^L^S^O^N
12 *CC 03NETADDR 01<CCRS@^R^U^P^L^A>
13 *CC 03NAME 01M^R. R.A. S^C^O^T^T
14 *CC 03ARCHIVE 01T^O^N^YF^I^L
15 *CC 03PHONE 0122023 EXT 279
16 JOHN 01NETADDR 01<^D^O^E@A^E^N^G^Z^4.^C^S^1........
17 JOHN 01NETADDR 02^U^T^E^X^A^S.^E^D^U>
18 JOHN 01NAME 01J^O^H^N D^O^E
1 4.1.3.3 Maintenance of the Alias File
-------------------------------------
The file must be an index sequential file, using the first 30
characters as the main key (ie alias and record-id). Alternate
keys will be alias-name and record-id separately. Initially,
lookup will be case-insensitive, but the extracting of
information must produce the exact case as typed by the user.
To do this, the alias name will be stored as upper-case
characters. The alias-blank field has been made large enough so
that, if needed, the alias-name field can be extended from the 8
6-bit display code characters to 16 6-bit locations using
6/12-bit character representation. This would allow case-
sensitive alias names (eg Ian would be a different alias from
IAN etc).
Maintenance of the alias file will be via screen-oriented
displays. An initial screen will prompt for the alias name.
Depending on the level of implementation of the alias facility,
the number of subsequent screens that are needed will vary.
Data entry/editing shall be via a screen-oriented display. When
an alias is displayed, each screen will hold the alias-name and
all the information pertaining to that alias (ie netaddress,
name, post, phone and comments) for a particular alias sequence
number. In the case of individual aliases the alias sequence
number will always be 01. In the case of a group alias, the
alias sequence number can be between 01 and 99. Editing of a
group alias will require an additional screen to display the
alias sequence numbers and the first few characters of the
corresponding names stored in their NAME-type records. This
screen will be used to identify which entry in the group alias
is to be edited.
Lookup by any of the keys (main or alternate) should be
possible. Browsing and other screen-oriented features must be
available.
1 5. Current Message Read Concept. Priority C
-------------------------------------------
The last message read, or the one currently being read, must be
treated as the 'current message'. If no message has yet been
read, then any command that relies on the current message
concept may not be used.
The following commands should operate with the current message
if no message number is specified:-
delete command
reply command
6. Deleting Messages. Priority B
--------------------------------
Mail should be deleted only when
the user issues a delete command
the user is de-registered from the mail system
and a tidyup run is being done.
When a message has been read, it should be flagged. It will
then be possible to identify unread mail.
The delete command should not operate on messages that have not
been read, either in part or in whole. Deleting partly-read
messages should require confirmation from the recipient before
the delete is carried out.
The effect of this is that a user can keep messages on-line for
some time. The current limit of 50 messages should remain, with
a concept of returning a 'mailbox full' signal when the 51st
message is sent.
7. Reply Command. Priority C
----------------------------
When a mail item has been (or is being) read, it must be
possible to issue a REPLY command that will generate the 'To:'
line and the 'Subject:' line from the current message.
The details of generating the 'To:' line are given in RFC 822.
The 'Subject:' line is formed by taking the text of the
'Subject:' field of the current message, prefixing the
characters 'Re:' to it.
1 8. Extra Header Lines. Priority C
---------------------------------
There are a number of optional header lines laid down in RFC
822. For example, it is possible to send a message to several
mailboxes (multiple 'To:' lines), or to have copies sent to
mailboxes ('Cc:' and 'Bcc:', or to have one person send mail on
behalf of another ('Sender:' and 'From:' instead of just
'From:'). A mechanism must be put into place to allow for this.
One way that might address some of the above is to allow the
mail sender to put these lines at the top of the message. Then,
when the message an the auto-generated header are merged, a
check is made as to whether there are certain RFC 822 fields in
a user-typed 'header', and if so, then incorporate the permitted
ones into the message header. Non-permitted ones are the
'authentic' of RFC 822, eg the 'From:' field cannot be changed.
An alternative is to set up an 'envelope' using screen
formatting and allow the user to enter these fields at that
stage (ie instead of the simple-minded line entry procedure of
MAIL 2.2.
The implementor of this feature needs to investigate and
to discuss the design before proceeding.
8.1 Sender and From. Priority C
-------------------------------
There must be a facility whereby one user can send mail on
behalf of another. The recommended way from RFC 822 is that
the person who generates the mail is identified by the header
line 'Sender:', and the person who asked the sender to send the
mail is identified in the 'From:' header line.
For example, if user CCSEC sends mail on behalf of CCML, then
the header will include the following lines (in this order):-
Sender: CCSEC
From: CCML
9. Adding the Hostname to the 'To:'. Priority B
-----------------------------------------------
Mail generated on RURES or RUPLA addressed as
To: CCML
must be sent with the 'To:' line expanded to be
To: CCML <CCML@host>
ie add the name of the host, viz RURES or RUPLA, to form a full
RSCS network address.
This will apply even when the mailnames feature is operative.
The recipient will then get used to seeing his full (RSA)
network address. Also, mail from various sources will have a
more consistent appearance.
1 10. Processing the 'To:' Line. Priority A
-----------------------------------------
The generic form of the 'To:' line is
user@host
The current mail generator process has several options that
depend on the contents of the 'To:' line. These are:-
a) If the HOST (and the preceeding '@') is omitted, then the
local Cyber is assumed as the host, and the message is
delivered to the specified USER, given that the USER is
registered on the local host. The MAILSND command is used.
b) If the HOST is the name of the local host, the message is
treated as for (a).
c) If the HOST is on the RSCS network, the message is sent
using NJROUTE, with the HOST as the destination node parameter
of NJROUTE.
d) All other messages are undeliverable, and the user is
advised immediately after the 'To:' line has been entered.
1 10.1 The 'To:' Line on RURES. Priority A
----------------------------------------
The 'To:' line can now have more options for an address. The
general form is still user@host. Some of the options are:-
user
user@host
user%relay@host
user%relay.1%relay.2@host
Further, the general forms of USER, RELAY and HOST are much
more complex, as laid down in RFC 822. In essence, any or all
of these fields can be quite long, and can have special
characters, most noticeably the full stop.
Preserve what the user typed, as this is the text to be used (as
a comment) in the message header. Then, in a working buffer,
test for a trailing '@RURES'. If this is present, remove it and
scan the remaining text from the right, replacing the first (if
any) '%' with an '@'.
Processing should proceed as follows:-
a) user
-------
Validate the user, use MAILSND to deliver (as done by MAIL 2.2)
b) user@host
------------
If HOST is now RURES, then reject the 'To:' line.
If HOST is on the RSCS network, then NJROUTE the message.
Otherwise, send the message to user RELAY in the local mail
system, using MAILSND. It will then make its way via Fidonet to
its destination.
c) user%relay@host (or any number of '%relay')
------------------
If the host is on the RSCS network, reject this form.
For all other hosts, send the message to user RELAY, using
MAILSND. It will then make its way via Fidonet to its
destination.
1 10.2 The 'To:' Line on RUPLA. Priority A
----------------------------------------
The 'To:' line can now have more options for an address. The
general form is still user@host. Some of the options are:-
user
user@host
user%relay@host
user%relay.1%relay.2@host
Further, the general forms of USER, RELAY and HOST are much
more complex, as laid down in RFC 822. In essence, any or all
of these fields can be quite long, and can have special
characters, most noticeably the full stop.
Preserve what the user typed, as this is the text to be used in
the message header. Then, in a working buffer, test for a
trailing '@RUPLA'. If this is present, remove it and scan the
remaining text from the right, replacing the first (if any) '%'
with an '@'.
Processing should proceed as follows:-
a) user
-------
Validate the user, use MAILSND to deliver (as done by MAIL 2.2)
b) user@host
------------
If HOST is RUPLA or it is missing from the list of hosts on the
RSCS network, then reject the 'To:' line.
Otherwise, NJROUTE the message.
c) user%relay@host (or any number of '%relay')
------------------
At this stage HOST must be RURES, as this is the local Rhodes
relay point. Send the message to user RELAY on RURES, using
NJROUTE. It will then make its way via Fidonet to its
destination. Note that the 'From:' line is still to be the
name of the user who created this message.
If HOST is not RURES, then reject the message as incorrectly
addressed.
1 11. Order of Header Fields. Priority B
--------------------------------------
The order of header fields is to follow the recommendation of
RFC 822. The relevant section has been extracted and inserted
here:-
---Start of Extract---
Note: Due to an artifact of the notational conventions, the
syntax indicates that, when present, some fields, must be in a
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---
12. Message Numbering. Priority C
---------------------------------
A basic concept of mailing is that messages are given reference
numbers. MAIL system Version 2.2 has an associated number,
used as the index number of the message as it is stored in the
mail files. This system has to be extended along the following
lines.
When a message is generated, it must be given a message
identification. This is part of the RFC 822 message header.
The message id looks like the following real-life
examples:-
Message-Id: <8812172159.AA00471@oresoft.UUCP>
Message-Id: <104.23B41C13@dawggon.fidonet.org>
Message-Id: <EXUMtgy00Wc84PH2hk@andrew.cmu.edu>
Message-Id: <37BF1A3@node406.net125.zone1.ifna.org>
Message-Id: <8811281604.AA11100@engc1.dal.utexas.edu>
Message-Id: <8812121744.AA02890@vax.ftp.com>
While the message id is never used for addressing, its format
is one of an address specification (see RFC 822, which defines
it this way). When a REPLY command is issued, apart from
generating the 'To:' line, an 'In-Reply-To:' line is generated,
which contains the original message id.
Further, when messages arrive, they are processed by some kind
of receiving program, which adds a 'Received:' line. This also
may have a message id.
In order to meet this, each program will stamp the messages it
generates or receives with the program's private message number
and the program id and release level. The message id (for that
program) is then incremented. At the same time, a dayfile
message should be generated to leave a permanent log of the
message, and some useful information for tracing that message.
Each program may have its own format, but once set, the format
should not change.
1 Thus, say, suppose that MAIL 3.1 generates a message. The
message header will then contain the line:-
Message-Id: <MAIL3.1.00236@rures>
This means that this message was created by the program MAIL
3.1 on RURES as its 236th message. The dayfile message would
be of the form:-
MAIL2.2.00236 RURES (sender) (route)
where (sender) is the 8-character mailname
(route) is what MAIL 2.2 did with it
(eg DISCARDED, NJROUTE, MAILSND)
Message numbers should start at 1, continue until 99999, and
then wraparound back to 1.
13. Tracing Received Mail. Priority B
-------------------------------------
When a message is stored in the mail files, (not when it is
created) it should have a 'Received:' line inserted into the
header. Note that RFC 822 specifies that when there is at
least one 'Received:' line, there must be one (and only one)
'Return-path:' line.
The 'Received:' line should look something like:-
Received: from RURES (MLawrie) with MAILSND (lvl 3.1) id 00234
; Wed, 04 Jan 89 09:08:07 +0200 (SAST)
Key points are:-
the 'from' has the Cyber hostname as known to the
RSCS network, with the sender's mailname as a
comment.
the 'with' has the name of the program and its
release level as a comment
the 'id' is the message number from the Cyber's
mail files
the time-stamp corresponds to the time that the
message was stored in the mail files, not when
the message was created (it will normally be very
close to the creation time)
The MAILSND and MAILNJF programs cause mail to be deposited in
the mail files. These programs are receiver programs, and must
indicate this in the trace (see RFC 822 for definition of trace
fields).
1 MAIL007 Ends
MAIL007. swf 9 73;sj y