ELIST Maintenance Program
~~~~~~~~~~~~~~~~~~~~~~~~~
This document is subject to change depending on coding and ongoing functional and system testing and the finding of errors within.
The following notes will be incorporated in to new manuals and help files for both the program and for Moderators.
All requests via MOD-ADD, MD-UPD and MOD-DEL must have keyword PASS present followed by the password on file. This is checked for on all, and for MOD-ADD the echo data record must not exist yet. At the current moment only files are accepted by being dropped off at the Elist maintainer system i.e., ECHOtag.RUL and ECHOtag.ECO the subject for the ECO file must be present (See new keywords below).
Once processing for JAM netmail areas are set up, then this is the file that is
created for each message so that the same processing can be used.
At the moment it is not intended to allow the use of Email for such as netmail validation will be tricky to say the least. Another and more important issue is
to find suitable C type libraries that can be utilised for the purpose and so far none has been found. As and when this is implemented each Email will also have a ECHOtag.ECO file created again to use the same processes.
New keywords:
------------
NEWPASS To change an existing password.
LANG Echo language where ENGLISH is the default.
SUBJect MOD-ADD, MOD-UPD or MOD-DEL and HELP. The hyphen can be one space
character instead.
COMDn See below for more information.
For HELP no other keywords are needed other than FROM
New sub keywords:
----------------
On keyword RESTrictions the following are accepted :
/REAl Real Names only
/SYS SYSops only
New:
/MOD Moderators (and Co-Mods) only
NONE or Blank - No restrictions
The restrictions can be cumulative, i.e., you could have /REL /SYS /MOD which implies:
Only for moderators who have a registered nodelist entry and they must use their
real names.
Keyword Changes:
~~~~~~~~~~~~~~~
COMOD DELETE (or NONE) will delete ALL 4 recorded Co-Moderators and the next
lines next keyword can be COMODn to create new one's if needed of up
to 4. where n = 1, 2, 3 or 4.
Useful if a CoMod has become a Mod and/or wishes to clear down dead
entries or specific entries.
NEW Keyword replacing COMOD
This keyword gives more control for the moderator to amend or delete
a specific CoModerator entry reducing the risk of mistakes.
COMODn Where n = 1, 2, 3 or 4. followed by :
DELETE or NONE will delete specific CoMod entry
or
A valid Netmail address which will update a specific CoMod entry.
Hopefully this is a better way of controlling specific Co-Moderator
entries.
RULES Processing:
----------------
Rules can be provided in two ways
1. Recommended by send a rules file with the file name of Echo Tag as upper
case plus extension of .RUL, i.e., MBSE.RUL
It can be any number of lines but each line must not exceed 75 characters
but can include blank lines for readability.
(for those Bulletin Board Systems that have such restrictions).
2. Sending as part of a MOD-ADD or MOD-UPD file where the rules text lines
follow immediately after the keyword RULETEXT and before the last line
which is the terminator '---' or '-+-', or the end of the file.
Again blank lines can be embedded within the text.
Note the same text block can be transferred to a ECHOtag.RUL file as is
but without the terminator line '---' or '-+-'.
In any event all RULETEXT content is transferred to a ECHOtag.RUL file
overwriting any existing file.
All MOD-ADD, MOD-UPD and MOD-DEL files use the extensions '.ECO' and can also include the subject context such as .ECOMOD-ADD or .ECOMOD-UPD or .ECOMOD-DEL. You CANNOT have a space between MOD and ADD or MOD and UPD as most operating system will not like it. You still need to include the keyword SUBJ with the above i.e., MOD-ADD, MOD-UPD or MOD-DEL. Using the hyphen reduces problems for typing the information and for that matter processing but you can have one space in place of the hyphen.
These must be sent as echo tag name as the filename, for example the echo MBSE the file would be : MBSE.ECO
NEW SECURITY :
~~~~~~~~~~~~
The address used when sending must exist in the current nodelist and the mailer
log is checked that the file came from a moderator (or Comod) on record
along with the password on record via the keyword PASSword as extra security features.
Likewise any echo .RUL files will also be checked.
A search of the nodelist is NOT done as the mailer will reject any that are
not present in the current file as processed by the mailer or other sub system and place any such in the unsecured directory which is may or may not be checked.
A moderator taking over from a previous one should get the existing moderator to send in a MOD-UPD with their name, node address as a CoMODn (1 thru 4).
If four co-mod are already registered then issue a COMOD(1 thru 4) DELETE, then a new COMODn for the new moderator, then wait for the acknowledgement, e.g.,
COMOD1 DELETE
After that is sent in and acknowledged, the new moderator can send in a update MOD-UPD containing their name & address details via keywords MOD and with a keyword COMOD DELETE to remove ALL existing CoMod details and if needed a new password keyword NEWPASS newpassword as a one word string with the letters
0 - 9, a - z, A - Z and any standard symbol character as found on a standard keyboard using one key stroke (shift allowed), i.e., no key sequences using the
ALT key as they can interfere with file processing.
Examples are `!"£$%^&*()_+-=}{[]~@:;'#?><,.
The password is case specific so ABCD is not the same as abcd.
Maximum size is 36 characters.
Note that the slash keys \ and / are not allowed in case of file processing using a database such as Mysqld or Mariadb etc and no they do not like them
for some reason.
Note that a change of password can also be done using the PASS keyword i.e., PASS old-password, new-password Note the space after the comma ','.
Examples for change of moderator - the current moderator sends:
SUBJ MOD-UPD
FROM 1:345/6
TAG echoname
PASS current-password {can also be current-password, new-password}
GROUP FIDO
COMOD DELETE
COMOD new moderator name address etc Fred_Blogs, 2:234/5
Then the new moderator sends after the previous MOD-UPD has been acknowledged:
SUBJ MOD-UPD
FROM 1:234/5
TAG echoname
PASS password [ using the (now) existing password ]
NEWPASS newpassword If needed.
or use
PASS old-password, new-password
GROUP FIDO
MOD Fred_Blogs, 1:234/5 [ Changing the moderator name and address ]
COMOD DELETE [ to remove all comod details as can't have a
duplicate address if not done by previous
moderator. ]
For subsequent updates then change PASS to reflect the new password after receiving an acknowledgement message via ELIST or netmail.
Remove the NEWPASS and COMOD entries, adding any other keywords that require changes if any.
There is one abnormality in functions found in that in the event of a Moderator
leaving the network (Fido or another) without having a co-moderator then
there is no simple way of changing by a new MOD-UPD file that can be used to change the Mod to another without a security risk unless the Co-Mod has a
copy of the MOD-UPD file that acts as a back up if something occurs with the Mods hardware or leaves the network for what ever reason.
It is recommended that all Moderators have a least one co-moderator for each echo area along with a copy of the current MOD-ADD and MOD-UPD file. Therefore the only other way is to send in a msg via ELIST echo to the maintainer to manually change her/him to another so that all Mods can see the request and if needed, object to such a request and this will help prevent echo hi-jacking, I hope.
Again:-
This hopefully will be the only reason for using the MAINT function unless I or
some one else can come up with another solution other than all moderators have at least one CoMod who is given a copy of the current MOD-ADD and MOD-UPD files
or records, so in the event of a major problem with the current moderator such as hardware, health or left fido then another can easily take over even if only for a few months while the problem/s are sorted out.
Expiry Warnings
---------------
Up to four is issued with the first one sent to moderator on record and in ELIST after six months have lapsed since the last update.
This is the reason why the WARN process is not run until all MOD UPDs processes
have finished close to 23:45 on the 1st of the month.
Warnings 2, 3 & 4 (the final) is sent to the moderator and all Co-Moderators on
record at their registered netmail address as well as in ELIST.
These will be issued after the WARNing run, which will happen on the first of each month close to midnight and after the last run of UPDATE has completed say
by 23:50 on the same day or the last day of the month.
If an update has not arrived at the elistmaintainer before the end of month 5 then the echo WILL be deleted.
Any registered moderator including Co-moderators for a given echo can send in MOD-UPD .ECO file and/or a Rules file.
Note that the content of a MOD-UPD only requires at a minimum the following keywords :
FROM
SUBJ
TAG
PASS
GROUP FIDO
Providing the address in the FROM keyword is one of the registered moderators then the Update will be considered valid proving there is no errors within any keyword or secondary parameters.
Note that each MOD-ADD, UPD or DEL is validated for correctness and if any errors are found the request is rejected with a message regarding the problem sent to the sender's netmail address and the ELIST echo.
System Data Limits :
Echo Tag name - 36 character max - UPPER CASE
Echo Group - 16 characters - UPPER CASE
Echo Title - 72 characters max - Mixed case.
Echo Volume - A monthly figure not exceeding 9999, please be realistic
e.g., 50.
Echo Restrictions - 72 characters which can be /REAL, /SYS & /MOD with a
practical maximum of any two of these or NONE or other
comments. Note that the three keywords MUST be upper case.
Any other text can be mixed case.
Echo Distribution - 72 characters. Any text.
Echo Gateway - 72 characters. Any text
Echo Lang - 16 characters - UPPER CASE - Default = ENGLISH
Echo PASSword - 36 characters Mixed case, A-Z, a-z, 0-9 and any symbol
using a standard 105 key keyboard, i.e., no ALT combinations
All sizes assume that one byte equals one character so use a standard character
set as the software does !
The program consists of four primary processes namely -
REPORT Run monthly on first of the month ?
WARN Run monthly on first of month before REPORT - This process
will delete out of time / warning echos where there has been four
warnings issued over a four month period after the 6 month time period
since the last MOD-UPD (update) has been received.
This means that no echo will be auto deleted unless there has been a
minimum period of 6 + 4 + 1 months from the last update or a request
to delete the echo via a MOD-DEL message.
MAINT Run only as needed.
UPDATE Run one or more times per day with the last at 23:45.
How goes it ? :
REPORT is finished coding and has completed provisional function and system
testing.
WARNING is finished coding and is awaiting F & S testing as needs UPDATE.
MAINT is finished coding and has had provisional function testing - still
needs system testing.
UPDATE is finished with some minor security code to be turned on subject to
system testing. This is now awaiting functional and, Yep, testing!
In the next few weeks I will be sending a request via ELIST for echo area ADD UPD files along with any .RUL files to be sent in to help with testing where all
results will go initially to a temporary echo called ELIST2 and later testing will go out to ELIST. The echo are ELIST2 is not normally available to other nodes as some tests may well look a bit of a mess, I hope not, but been programming for far too many year to assume otherwise.
Updated 2020/01/26 Vincent Coen. 1:250/1
vbcoen@gmail.com
--- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
* Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1)