ELIST Maintenance Program
~~~~~~~~~~~~~~~~~~~~~~~~~

This document is subject to change depending 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 operation and for Moderators otherwise acts as additional material.

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). ECHOtag should match up to the content of TAG keyword.

For the echo description you can also provide the optional file ECHOgroup.Echotag.DES

Note the periods / full stops. The content of this file is plain text with up to 72 characters per line and up to 15 lines and this is so that many BBS systems can operate.

Once processing for JAM netmail areas are set up (as used with mbse), then this
is the file that is created for each message so that the same processing can be
used.
The same will apply to the use of email for sending and receiving elist updates
or warnings.

At this time, no suitable software for this purpose has been found.

The 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 used for file submissions.

New keywords: Where a * preceding is a mandatory keyword - it MUST be provided.
------------ ================================================================

*LANG Echo language where ENGLISH is the default.
*SUBJect MOD-ADD, MOD-UPD or MOD-DEL and HELP.
COMODn See below for more information.
HELP To request the help text file via netmail and the ELIST echo.

Failure to proved one of the mandatory keyword will result in the submission being reject with the appropriate Error messages being issued.
The same applies to any other errors found but for any Warning messages the processing will continue, providing no Error messages was generated.

For HELP (to be sent via netmail, no other keywords are needed other than FROM
but the file must have the .ECO extension but the name could be anything.

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 - Use NONE to remove any others present
and make it NONE.

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. Do not use the other additional descriptions as these get created for the ELIST.RPT and the posted report into the ELIST echo after each echo update. Note a space between these restrictions.

Keyword Changes:
~~~~~~~~~~~~~~~

NEW Keyword that replaced 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 contact address which will update a specific CoMod entry.

Hopefully this is a better way of controlling Co-Moderator entries.
Note that a submission file can be sent (with adjusted FROM keyword)
from any recorded moderator or co-moderator. This is to safeguard the
echo in the event a moderator is ill or left Fido.

For this reason it is recommended that all Moderators have at least one
co-mod set up for ALL echos that they look after and have a current
copy of the echotag.ECO files for Updating and if available the
original for adding the echo say with the file name of echotag.ECO-ADD
where the update file is echotag.ECO-MOD

The extra extension after the word .ECO is ignored by the system but
is useful to keep what file does what for a co-mod or mod.

Contact Address
===============
Formed of three elements separated by commas in the form:
- Element one - - - - - - Element two - - - - - - Element three
FirstName LastName, Zmmm:Nmmmm.Kmmmm {.Pmmmm}{@demain} {, email@address}
Z = zone, N = Net, K = Node with {optional P = Point or/and Domain}.

Note that Domain is no longer used as serves no purpose these days but
it allowed for but other wise not processed.

So in practice the format is :
FirstName LastName, Zmmm:Nmmmm.Kmmmm {.Pmmmm} {, email@address}

Example : Vince Coen, 2:250/1

The first two (name and netmail address) are required for responses
posted to ELIST and if errors or expiry warnings direct to the network
address to both the mod and any co-mod on record.

Point and domain are totally optional and are not required.
Note the leading commas for elements 2 and 3.
{} Signify optional.

Support for Email is not yet available.
Support for receiving submissions via netmail not yet available.

RULES Processing:
----------------

Rules can be provided in one of two ways

1. Recommended to 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 one blank lines between other text lines for readability.
(for those Bulletin Board Systems that have such restrictions).
The restriction of 75 character length is not tested for but you will see
the results of such, by text being chopped off after character 75 in all
reports and netmails.

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 one blank line can be embedded within text lines.

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 'as is', with no checking of content.

Description Processing: [ NEW ]
----------------------

As the system now fully supports ALL Fido echo's for the BACKBONE using for lists of areas into BACKBONE.NA which can be used for bbs systems that support autocreate echo functions, when receiving a new messages for a new Echo area and
the BACKBONE.RPT that holds all FIDO areas from the ELIST system as well as all
not on that facility that is considered un-moderated.
This will also happens for any echo areas that expire and is deleted from the ELIST reporting in that each echo will be moved over to the backbone for those reports and files.

The backbone lists will be maintained and owned by elistmaint which currently has the netmail address of 2:25/21. While it will be reported as Moderated by the same person, they will in fact not be moderated at all, such will remain only as backbone echo's.

As the backbone echos in the main, does not have descriptions listed, the format of the database that holds this information within the elist software has
been changed so that details of echo descriptions are no longer held on it but in separate files in the same way that the rules are stored in files named as {echotag}.RUL so is description but stored in files in the same format (as text
files) but with the filename of {Group}.{echotag}.DES - more later.

This along with the previous removal of rules has reduced the size of each echo
record from 4500+ bytes or characters, depending on the size of the rules to 1024 bytes, a good reduction.

This allows the number of echos that can be stored on a restricted storage system running the elist software, even to run on a SD card say within a Raspberry Pi computer although speed will be some what reduced - to put it mildly.

As a follow on from this :
------------------------

As of version 5.3 (as used from 5th April 2022) you can also submit one additional file that holds the description text in the same format as the one for .RUL and for this optional file (mostly for the use of backbone echo's) is:

This optional file (if submitted), MUST be in the format of aaa.bbb.DES

Where aaa = Group name i.e., FIDO, FSXNET etc
bbb = Echo Tag name i.e., ELIST
followed by the fixed text '.DES' (without the quotes).



All MOD-ADD, MOD-UPD and MOD-DEL files use the extensions '.ECO'.
You MUST include the keyword SUBJ in each of the above i.e., MOD-ADD, MOD-UPD or
MOD-DEL. This extension can also have such text as -ADD or -UPD etc so you could
have ELIST.ECO-ADD or ELIST.ECO-UPD (to add or update the system respectively).

These files must be sent as echo tag name as the filename, for example the echo
MBSE the file would be : MBSE.ECO and if needed MBSE.RUL for the rules.

Note that any moderator and this includes a co-moderator can submit a MOD-UPD or
MOD-DEL providing they are on record as one, in the echo being changed. This is
so that if the moderator has a major system problem or leaves the network for any reason, another can take over and send a MOD-UPD submission even as a
one off.

A moderator taking over from a previous one should get the existing moderator to send in a MOD-UPD with their contact address as a CoMODn (1 through 4) and if
all are in use just overwrite one of these entries.

After that is sent in and acknowledged, the new moderator can send in a update MOD-UPD containing their contract address details via keywords MOD and with a keyword COMOD1 DELETE to remove the previously created entry.

Note you can send in multiple changes to a echo with the submit files say called
ELIST1.ECO, ELIST2.ECO and ELIST3.ECO.

If needed use PASS oldpassword, newpassword to change the existing password.

The password, 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 or CTL keys as they
can interfere with file processing. Do NOT use a space character as that will mark the end of the password.

Examples are ¬`!"£$%^&*()_+-=}{[]~@:;'#?><,.

The password is case specific so ABCD is not the same as abcd which is not the same as AbCd.
Maximum size is 36 characters.

Note that the slash keys \ and / must not be used in case of file processing using a database such as Mysqld or Mariadb etc and no, they do not like them for some reason.

Examples for change of moderator - the current 1:345:6 or co-mod sends:
Note that the FROM and MOD must be the same and as in the system record.

as echoname1.ECO
SUBJ MOD-UPD
FROM Bat Man, 1:345/6
TAG echoname
GROUP FIDO
LANG ENGLISH
PASS current-password {can also be current-password, new-password}
COMOD1 new moderator Contact address, etc, Fred Blogs, 2:234/5

Note the comma separators between each segment.
Then the new moderator sends after the previous MOD-UPD has been acknowledged:

as echoname2.ECO
SUBJ MOD-UPD
FROM Fred Blogs, 1:234/5
TAG echoname
GROUP FIDO
LANG ENGLISH
PASS password [ using the currently existing password ]
or
PASS old-password, new-password

MOD Fred_Blogs, 1:234/5 [ Changing the moderator name and address ]

as echoname3.ECO
SUBJ MOD-UPD
FROM Fred Blogs, 1:234/5
TAG echoname
GROUP FIDO
LANG ENGLISH
PASS password
MOD Fred_Blogs, 1:234/5 [ Changing the moderator name and address ]

COMOD1 DELETE [ to remove all comod details as should not have a
duplicate address if not done by previous
moderator. ]

As the system processes .ECO files in alphabetic sorted order all three submission files can be sent in, at the same time.

For subsequent updates then change PASS to reflect the new password if changed.
Remove the COMOD1 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
Elist 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.
Again if a com-mod gets these two files and they are not in the for of : ECHOTAG.ECO-ADD and ECHOTAG.ECO-UPD they should change them so they are, just in case.

Yes, I have written it twice!


Expiry Warnings
---------------

Updated as of v5.3:

Up to ONE is issued with the first one sent to moderator on record and in
ELIST after TEN months have lapsed since the last update.
This is the reason why the WARN process is not run until all MOD-UPD's processes
have finished close to 23:45 on the 1st of the month.

Warnings are sent to the moderator and all Co-Moderators on record at their registered netmail address as well as in ELIST.
These will be issued during the WARN 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 elist maintainers system before the end of the issued month then the echo WILL be deleted with the tag and title transferred to the Backbone system with elistmaint, 2:25/21 as the listed moderator.

Reminder:
Any registered moderator including Co-moderators for a given echo can send in MOD-UPD .ECO file and/or a Rules file or for that matter a .DES file.
Note that the content of a MOD-UPD only requires at a minimum the following keywords :

FROM
SUBJ
TAG
GROUP
PASS

Providing the contact 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/s
found, sent to the sender's netmail address (as on the FROM keyword) and the ELIST echo.


System Data Limits :
==================

Echo Tag name - 36 character max - UPPER CASE
Echo Group - 16 characters max - 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 - 48 characters which can be /REAL, /SYS & /MOD with a
practical maximum of any of these or NONE or other
comments. Note that the three keywords MUST be upper case.
They MUST also precede any other text.
Any other text can be mixed case.
Echo Distribution - 36 characters. Any text.
Echo Gateway - 36 characters. Any text
Echo Lang - 16 characters - any case but converted to 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
but not \ / or space.

All sizes assume that one byte equals one character so use a standard character
set as the software does !

elist Operations mini version
-----------------------------

Elist Program:
-------------
The elist program consists of three primary processes driven by one to four parameters namely -

Parameter one:
UPDATE Run 24 times per day at 30 minutes past the hour with the last at 23:30

WARN Run monthly on first of month before REPORT - This process
will delete out of time / warning echos where there has been one
warnings issued over a month period after the 10 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 10 + 1 months + 1 from the last update or a request
to delete the echo via a MOD-DEL message and that will still stay
until the next WARN run. This runs 1st month after 23:30.

REPORT Run monthly on first of the month after 23:30 the UPDATE & WARN runs.
This process create two primary files - for each group under control
such as FIDO (using the name ELIST) as ELIST.NA (a list of areas by
Echotag name and Title), and ELIST.RPT a details report for each echo
in Echo Tag order. This file ELIST.RPT for January and July a more
detailed is generated that includes a copy of any Rules for all echos
in both the ELIST system as well as the Backbone with all BACKBONE
areas so marked.
For non ELIST and FIDO net areas a .NO file that holds deleted echo
areas that are held for 12 months before being deleted. In the event
that a deleted echo is reinstated the entry in the .NO file is removed.
As expired echo's in the ELIST files are transferred to the Backbone
the .NO file is not created.
Any echo that is deleted by use of a submission file from a registered
moderator the echo is deleted as it is deemed inactive with no postings
for a period no shorter than 12 months it is not transferred to the
backbone not stored in the .NO file - it is gone.

Various housekeeping jobs are then run as well as creating the ELST archive for
the month past that is then sent to all links of the bbs system. Likewise for all ELIST echo postings by the system. Various back ups are created and stored in a range of other systems when connected, for security.

There are other processes that are not described as they are used under system,
security or testing.

Emaint Program:
--------------

The emaint program has only one process.

Run Interactive Maintenance only as needed.

This will add, update or delete an existing echo entry as needed or mark a echo
as being on the BACKBONE.



Updated 2022/04/05 Vincent Coen. 1:25/21 & 2:250/1, vbcoen=at=gmail.com
Text, grammar, typo's and updates.



--- MBSE BBS v1.0.8 (Linux-x86_64)
* Origin: The Elist Maintainer (2:250/1)

ELIST Maintenance Program
~~~~~~~~~~~~~~~~~~~~~~~~~

This document is subject to change depending 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 operation and for Moderators otherwise acts as additional material.

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). ECHOtag should match up to the content of TAG keyword.

For the echo description you can also provide the optional file ECHOgroup.Echotag.DES

Note the periods / full stops. The content of this file is plain text with up to 72 characters per line and up to 15 lines and this is so that many BBS systems can operate.

Once processing for JAM netmail areas are set up (as used with mbse), then this
is the file that is created for each message so that the same processing can be
used.
The same will apply to the use of email for sending and receiving elist updates
or warnings.

At this time, no suitable software for this purpose has been found.

The 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 used for file submissions.

New keywords: Where a * preceding is a mandatory keyword - it MUST be provided.
------------ ================================================================

*LANG Echo language where ENGLISH is the default.
*SUBJect MOD-ADD, MOD-UPD or MOD-DEL and HELP.
COMODn See below for more information.
HELP To request the help text file via netmail and the ELIST echo.

Failure to proved one of the mandatory keyword will result in the submission being reject with the appropriate Error messages being issued.
The same applies to any other errors found but for any Warning messages the processing will continue, providing no Error messages was generated.

For HELP (to be sent via netmail, no other keywords are needed other than FROM
but the file must have the .ECO extension but the name could be anything.

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 - Use NONE to remove any others present
and make it NONE.

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. Do not use the other additional descriptions as these get created for the ELIST.RPT and the posted report into the ELIST echo after each echo update. Note a space between these restrictions.

Keyword Changes:
~~~~~~~~~~~~~~~

NEW Keyword that replaced 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 contact address which will update a specific CoMod entry.

Hopefully this is a better way of controlling Co-Moderator entries.
Note that a submission file can be sent (with adjusted FROM keyword)
from any recorded moderator or co-moderator. This is to safeguard the
echo in the event a moderator is ill or left Fido.

For this reason it is recommended that all Moderators have at least one
co-mod set up for ALL echos that they look after and have a current
copy of the echotag.ECO files for Updating and if available the
original for adding the echo say with the file name of echotag.ECO-ADD
where the update file is echotag.ECO-MOD

The extra extension after the word .ECO is ignored by the system but
is useful to keep what file does what for a co-mod or mod.

Contact Address
===============
Formed of three elements separated by commas in the form:
- Element one - - - - - - Element two - - - - - - Element three
FirstName LastName, Zmmm:Nmmmm.Kmmmm {.Pmmmm}{@demain} {, email@address}
Z = zone, N = Net, K = Node with {optional P = Point or/and Domain}.

Note that Domain is no longer used as serves no purpose these days but
it allowed for but other wise not processed.

So in practice the format is :
FirstName LastName, Zmmm:Nmmmm.Kmmmm {.Pmmmm} {, email@address}

Example : Vince Coen, 2:250/1

The first two (name and netmail address) are required for responses
posted to ELIST and if errors or expiry warnings direct to the network
address to both the mod and any co-mod on record.

Point and domain are totally optional and are not required.
Note the leading commas for elements 2 and 3.
{} Signify optional.

Support for Email is not yet available.
Support for receiving submissions via netmail not yet available.

RULES Processing:
----------------

Rules can be provided in one of two ways

1. Recommended to 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 one blank lines between other text lines for readability.
(for those Bulletin Board Systems that have such restrictions).
The restriction of 75 character length is not tested for but you will see
the results of such, by text being chopped off after character 75 in all
reports and netmails.

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 one blank line can be embedded within text lines.

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 'as is', with no checking of content.

Description Processing: [ NEW ]
----------------------

As the system now fully supports ALL Fido echo's for the BACKBONE using for lists of areas into BACKBONE.NA which can be used for bbs systems that support autocreate echo functions, when receiving a new messages for a new Echo area and
the BACKBONE.RPT that holds all FIDO areas from the ELIST system as well as all
not on that facility that is considered un-moderated.
This will also happens for any echo areas that expire and is deleted from the ELIST reporting in that each echo will be moved over to the backbone for those reports and files.

The backbone lists will be maintained and owned by elistmaint which currently has the netmail address of 2:25/21. While it will be reported as Moderated by the same person, they will in fact not be moderated at all, such will remain only as backbone echo's.

As the backbone echos in the main, does not have descriptions listed, the format of the database that holds this information within the elist software has
been changed so that details of echo descriptions are no longer held on it but in separate files in the same way that the rules are stored in files named as {echotag}.RUL so is description but stored in files in the same format (as text
files) but with the filename of {Group}.{echotag}.DES - more later.

This along with the previous removal of rules has reduced the size of each echo
record from 4500+ bytes or characters, depending on the size of the rules to 1024 bytes, a good reduction.

This allows the number of echos that can be stored on a restricted storage system running the elist software, even to run on a SD card say within a Raspberry Pi computer although speed will be some what reduced - to put it mildly.

As a follow on from this :
------------------------

As of version 5.3 (as used from 5th April 2022) you can also submit one additional file that holds the description text in the same format as the one for .RUL and for this optional file (mostly for the use of backbone echo's) is:

This optional file (if submitted), MUST be in the format of aaa.bbb.DES

Where aaa = Group name i.e., FIDO, FSXNET etc
bbb = Echo Tag name i.e., ELIST
followed by the fixed text '.DES' (without the quotes).



All MOD-ADD, MOD-UPD and MOD-DEL files use the extensions '.ECO'.
You MUST include the keyword SUBJ in each of the above i.e., MOD-ADD, MOD-UPD or
MOD-DEL. This extension can also have such text as -ADD or -UPD etc so you could
have ELIST.ECO-ADD or ELIST.ECO-UPD (to add or update the system respectively).

These files must be sent as echo tag name as the filename, for example the echo
MBSE the file would be : MBSE.ECO and if needed MBSE.RUL for the rules.

Note that any moderator and this includes a co-moderator can submit a MOD-UPD or
MOD-DEL providing they are on record as one, in the echo being changed. This is
so that if the moderator has a major system problem or leaves the network for any reason, another can take over and send a MOD-UPD submission even as a
one off.

A moderator taking over from a previous one should get the existing moderator to send in a MOD-UPD with their contact address as a CoMODn (1 through 4) and if
all are in use just overwrite one of these entries.

After that is sent in and acknowledged, the new moderator can send in a update MOD-UPD containing their contract address details via keywords MOD and with a keyword COMOD1 DELETE to remove the previously created entry.

Note you can send in multiple changes to a echo with the submit files say called
ELIST1.ECO, ELIST2.ECO and ELIST3.ECO.

If needed use PASS oldpassword, newpassword to change the existing password.

The password, 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 or CTL keys as they
can interfere with file processing. Do NOT use a space character as that will mark the end of the password.

Examples are ¬`!"£$%^&*()_+-=}{[]~@:;'#?><,.

The password is case specific so ABCD is not the same as abcd which is not the same as AbCd.
Maximum size is 36 characters.

Note that the slash keys \ and / must not be used in case of file processing using a database such as Mysqld or Mariadb etc and no, they do not like them for some reason.

Examples for change of moderator - the current 1:345:6 or co-mod sends:
Note that the FROM and MOD must be the same and as in the system record.

as echoname1.ECO
SUBJ MOD-UPD
FROM Bat Man, 1:345/6
TAG echoname
GROUP FIDO
LANG ENGLISH
PASS current-password {can also be current-password, new-password}
COMOD1 new moderator Contact address, etc, Fred Blogs, 2:234/5

Note the comma separators between each segment.
Then the new moderator sends after the previous MOD-UPD has been acknowledged:

as echoname2.ECO
SUBJ MOD-UPD
FROM Fred Blogs, 1:234/5
TAG echoname
GROUP FIDO
LANG ENGLISH
PASS password [ using the currently existing password ]
or
PASS old-password, new-password

MOD Fred_Blogs, 1:234/5 [ Changing the moderator name and address ]

as echoname3.ECO
SUBJ MOD-UPD
FROM Fred Blogs, 1:234/5
TAG echoname
GROUP FIDO
LANG ENGLISH
PASS password
MOD Fred_Blogs, 1:234/5 [ Changing the moderator name and address ]

COMOD1 DELETE [ to remove all comod details as should not have a
duplicate address if not done by previous
moderator. ]

As the system processes .ECO files in alphabetic sorted order all three submission files can be sent in, at the same time.

For subsequent updates then change PASS to reflect the new password if changed.
Remove the COMOD1 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
Elist 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.
Again if a com-mod gets these two files and they are not in the for of : ECHOTAG.ECO-ADD and ECHOTAG.ECO-UPD they should change them so they are, just in case.

Yes, I have written it twice!


Expiry Warnings
---------------

Updated as of v5.3:

Up to ONE is issued with the first one sent to moderator on record and in
ELIST after TEN months have lapsed since the last update.
This is the reason why the WARN process is not run until all MOD-UPD's processes
have finished close to 23:45 on the 1st of the month.

Warnings are sent to the moderator and all Co-Moderators on record at their registered netmail address as well as in ELIST.
These will be issued during the WARN 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 elist maintainers system before the end of the issued month then the echo WILL be deleted with the tag and title transferred to the Backbone system with elistmaint, 2:25/21 as the listed moderator.

Reminder:
Any registered moderator including Co-moderators for a given echo can send in MOD-UPD .ECO file and/or a Rules file or for that matter a .DES file.
Note that the content of a MOD-UPD only requires at a minimum the following keywords :

FROM
SUBJ
TAG
GROUP
PASS

Providing the contact 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/s
found, sent to the sender's netmail address (as on the FROM keyword) and the ELIST echo.


System Data Limits :
==================

Echo Tag name - 36 character max - UPPER CASE
Echo Group - 16 characters max - 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 - 48 characters which can be /REAL, /SYS & /MOD with a
practical maximum of any of these or NONE or other
comments. Note that the three keywords MUST be upper case.
They MUST also precede any other text.
Any other text can be mixed case.
Echo Distribution - 36 characters. Any text.
Echo Gateway - 36 characters. Any text
Echo Lang - 16 characters - any case but converted to 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
but not \ / or space.

All sizes assume that one byte equals one character so use a standard character
set as the software does !

elist Operations mini version
-----------------------------

Elist Program:
-------------
The elist program consists of three primary processes driven by one to four parameters namely -

Parameter one:
UPDATE Run 24 times per day at 30 minutes past the hour with the last at 23:30

WARN Run monthly on first of month before REPORT - This process
will delete out of time / warning echos where there has been one
warnings issued over a month period after the 10 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 10 + 1 months + 1 from the last update or a request
to delete the echo via a MOD-DEL message and that will still stay
until the next WARN run. This runs 1st month after 23:30.

REPORT Run monthly on first of the month after 23:30 the UPDATE & WARN runs.
This process create two primary files - for each group under control
such as FIDO (using the name ELIST) as ELIST.NA (a list of areas by
Echotag name and Title), and ELIST.RPT a details report for each echo
in Echo Tag order. This file ELIST.RPT for January and July a more
detailed is generated that includes a copy of any Rules for all echos
in both the ELIST system as well as the Backbone with all BACKBONE
areas so marked.
For non ELIST and FIDO net areas a .NO file that holds deleted echo
areas that are held for 12 months before being deleted. In the event
that a deleted echo is reinstated the entry in the .NO file is removed.
As expired echo's in the ELIST files are transferred to the Backbone
the .NO file is not created.
Any echo that is deleted by use of a submission file from a registered
moderator the echo is deleted as it is deemed inactive with no postings
for a period no shorter than 12 months it is not transferred to the
backbone not stored in the .NO file - it is gone.

Various housekeeping jobs are then run as well as creating the ELST archive for
the month past that is then sent to all links of the bbs system. Likewise for all ELIST echo postings by the system. Various back ups are created and stored in a range of other systems when connected, for security.

There are other processes that are not described as they are used under system,
security or testing.

Emaint Program:
--------------

The emaint program has only one process.

Run Interactive Maintenance only as needed.

This will add, update or delete an existing echo entry as needed or mark a echo
as being on the BACKBONE.



Updated:
2022/04/05 Vincent Coen. 2:250/1, vbcoen=at=gmail.com
Text, grammar, typo's and updates.
2022/05/05 Removed a reference to sending to 250/1.



--- MBSE BBS v1.0.8 (Linux-x86_64)
* Origin: The Elist Maintainer (2:250/1)

ELIST Maintenance Programs
~~~~~~~~~~~~~~~~~~~~~~~~~~

The following notes will be incorporated into the Elist manual and help files for the program facilities and operation. It will be deleted then after.

These notes are mostly for a new elistmaint administrator of the Elist system and liek wise the full Elist manual that provides information for the installation and set up of the full Elist system including supporting software such as the MBSE BBS system along with the compiler for building the elist programs.

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). ECHOtag should match up to the content of TAG keyword.

For the echo description you can also provide the optional file ECHOgroup.Echotag.DES

Note the periods / full stops. The content of this file is plain text with up to 75 characters per line and up to 15 lines and this is so that many BBS systems can operate that may still have this limitation if they use descriptions
at all, as for example MBSE does not although it does support the RULes files.

The .DES file replaces the need to use keyword DESC so that, can be removed from
a submission file. This file can be used in any BBS system being under current development but any active programmer should advise of this to myself as the Elist programmer and I will ensure that the .DES files are also provided in the
monthly archives other wise they will remain for internal Elist processing.

Once processing for JAM netmail areas are set up (as used with mbse), then this
is the file that is created for each message so that the same processing can be
used.
The same will apply to the use of email for sending and receiving elist updates
or warnings.

At this time, NO suitable software for this purpose has been found.

The 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 used for file submissions.

Failure to proved one of the mandatory keyword will result in the submission being reject with the appropriate Error messages being issued.
The same applies to any other errors found but for any Warning messages the processing will continue, providing no Error messages was generated.

For HELP (to be sent via netmail, no other keywords are needed other than FROM
but the file must have the .ECO extension but the name could be anything.

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 - Use NONE to remove any others present
and make it NONE.

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. Do not use the other additional descriptions as these get created for the ELIST.RPT and the posted report into the ELIST echo after each echo update. Note a space between these restrictions.

Keyword Changes:
~~~~~~~~~~~~~~~

NEW Keyword that replaced 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 contact address which will update a specific CoMod entry.

Hopefully this is a better way of controlling Co-Moderator entries.
Note that a submission file can be sent (with adjusted FROM keyword)
from any recorded moderator or co-moderator. This is to safeguard the
echo in the event a moderator is ill or left Fido.

For this reason it is recommended that all Moderators have at least one
co-mod set up for ALL echos that they look after and have a current
copy of the echotag.ECO files for Updating and if available the
original for adding the echo say with the file name of echotag.ECO-ADD
where the update file is echotag.ECO-MOD

The extra extension after the word .ECO is ignored by the system but
is useful to keep what file does what for a co-mod or mod.

Contact Address
===============
Formed of three elements separated by commas in the form:
- Element one - - - - - - Element two - - - - - - Element three
FirstName LastName, Zmmm:Nmmmm.Kmmmm {.Pmmmm}{@demain} {, email@address}
Z = zone, N = Net, K = Node with {optional P = Point or/and Domain}.

Note that Domain is no longer used as serves no purpose these days but
is allowed for but, otherwise not processed.

So in practice the format is :
FirstName LastName, Zmmm:Nmmmm.Kmmmm {.Pmmmm} {, email@address}

Example : Vince Coen, 2:250/1

The first two (name and netmail address) are required for responses
posted to ELIST and if errors or expiry warnings direct to the network
address to both the mod and any co-mod on record.

Point and domain are totally optional and are not required.
Note the leading commas for elements 2 and 3.
{} Signify optional.

Support for Email is not yet available so no need for the address.
Support for receiving submissions via netmail not yet available.

RULES Processing:
----------------

Rules can be provided in one of two ways

1. Recommended to 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 one blank lines between other text lines for readability.
(for those Bulletin Board Systems that have such restrictions).
The restriction of 75 character length is not tested for but you will see
the results of such, by text being chopped off after character 75 in all
reports and netmails.

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 one blank line can be embedded within text lines.

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 'as is', with no checking of content.

Description Processing: [ NEW ] as of v5.3.
----------------------

As the system now fully supports ALL Fido echo's for the BACKBONE using for lists of areas into BACKBONE.NA which can be used for BBS systems that support auto create echo functions, when receiving a new messages for a new Echo area and
the BACKBONE.RPT that holds all FIDO areas from the ELIST system as well as all
not on that facility that is considered un-moderated.

This will also happens for any echo areas that expire and is deleted from the ELIST reporting in that each echo will be moved over to the backbone for those reports and files.

The backbone lists will be maintained and owned by elistmaint which currently has the netmail address of 2:25/21. While it will be reported as Moderated by the this person, they will in fact not be moderated at all, and will remain only as backbone echo's.

As the backbone echos in the main, does not have descriptions listed, the format of the database that holds this information within the elist software has
been changed so that details of echo descriptions are no longer held on it but in separate files in the same way that the rules are stored in files named as {echotag}.RUL so is description, but stored in files in the same format (as text
files) but with the filename of {Group}.{echotag}.DES - more later.

This along with the previous removal of rules has reduced the size of each echo
record from 4500+ bytes or characters, depending on the size of the rules to 1024 bytes, a good reduction.

This allows the number of echos that can be stored on a restricted storage system running the elist software, even to run on a SD card say within a Raspberry Pi computer although speed will be some what reduced - to put it mildly.

As a follow on from this :
------------------------

As of version 5.3 (as used from 5th April 2022) you can also submit one additional file that holds the description text in the same format as the one for .RUL and for this optional file (mostly for the use of backbone echo's) is:

This optional file (if submitted), MUST be in the format of aaa.bbb.DES

Where aaa = Group name i.e., FIDO, FSXNET etc
bbb = Echo Tag name i.e., ELIST
followed by the fixed text '.DES' (without the quotes).



All MOD-ADD, MOD-UPD and MOD-DEL files use the extensions '.ECO'.
You MUST include the keyword SUBJ in each of the above i.e., MOD-ADD, MOD-UPD or
MOD-DEL. This extension can also have such text as -ADD or -UPD etc so you could
have ELIST.ECO-ADD or ELIST.ECO-UPD (to add or update the system respectively).

These files must be sent as echo tag name as the filename, for example the echo
MBSE the file would be : MBSE.ECO and if needed MBSE.RUL for the rules.

Note that any moderator and this includes a co-moderator can submit a MOD-UPD or
MOD-DEL providing they are on record as one, in the echo being changed. This is
so that if the moderator has a major system problem or leaves the network for any reason, another can take over and send a MOD-UPD submission even as a
one off.

A moderator taking over from a previous one should get the existing moderator to send in a MOD-UPD with their contact address as a CoMODn (1 through 4) and if
all are in use just overwrite one of these entries.

After that is sent in and acknowledged, the new moderator can send in a update MOD-UPD containing their contract address details via keywords MOD and with a keyword COMOD1 DELETE to remove the previously created entry.

Note you can send in multiple changes to a echo with the submit files say called
ELIST1.ECO, ELIST2.ECO and ELIST3.ECO.

If needed use PASS oldpassword, newpassword to change the existing password.

The password, 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 or CTL keys as they
can interfere with file processing. Do NOT use a space character as that will mark the end of the password.

Examples are ¬`!"£$%^&*()_+-=}{[]~@:;'#?><,.

The password is case specific so ABCD is not the same as abcd which is not the same as AbCd.
Maximum size is 36 characters.

Note that the slash keys \ and / must not be used in case of file processing using a database such as Mysqld or Mariadb etc and no, they do not like them for some reason.

Examples for change of moderator - the current 1:345:6 or co-mod sends:
Note that the FROM and MOD must be the same and as in the system record.

as ECHONAME.ECO
SUBJ MOD-UPD
FROM Bat Man, 1:345/6
TAG echoname
GROUP FIDO
LANG ENGLISH
PASS current-password {can also be current-password, new-password}
COMOD1 new moderator Contact address, etc, Fred Blogs, 2:234/5

Note the comma separators between each segment.
Then the new moderator sends after the previous MOD-UPD has been acknowledged:

as ECHONAME.ECO
SUBJ MOD-UPD
FROM Fred Blogs, 1:234/5
TAG echoname
GROUP FIDO
LANG ENGLISH
PASS password [ using the currently existing password ]
or
PASS old-password, new-password

MOD Fred_Blogs, 1:234/5 [ Changing the moderator name and address ]

as echoname3.ECO
SUBJ MOD-UPD
FROM Fred Blogs, 1:234/5
TAG echoname
GROUP FIDO
LANG ENGLISH
PASS password
MOD Fred_Blogs, 1:234/5 [ Changing the moderator name and address ]

COMOD1 DELETE [ to remove all co-mod details as should not have a
duplicate address if not done by previous
moderator. ]

As the system processes .ECO files in alphabetic sorted order all three submission files can be sent in, at the same time.

For subsequent updates then change PASS to reflect the new password if changed.
Remove the COMOD1 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
Elist 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.
Again if a com-mod gets these two files and they are not in the for of : ECHOTAG.ECO-ADD and ECHOTAG.ECO-UPD they should change them so they are, just in case.

Yes, I have written it twice!


Expiry Warnings
---------------

Updated as of v5.3:

Up to ONE is issued with the first one sent to moderator on record and in
ELIST after TEN months have lapsed since the last update.
This is the reason why the WARN process is not run until all MOD-ADD and MOD-UPD's processes have finished close to 23:45 on the 1st of the month.

Warnings are sent to the moderator and all Co-Moderators on record at their registered netmail address as well as in ELIST.
These will be issued during the WARN 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 elist maintainers system before the end of the issued month then the echo WILL be deleted with the tag and title transferred to the Backbone system with elistmaint, 2:25/21 as the listed moderator.

Reminder:
Any registered moderator including Co-moderators for a given echo can send in MOD-UPD .ECO file and/or a Rules file or for that matter a .DES file.
Note that the content of a MOD-UPD only requires at a minimum the following keywords :

FROM
SUBJ
TAG
GROUP
PASS

Providing the contact 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/s
found, sent to the sender's netmail address (as on the FROM keyword) and the ELIST echo.


System Data Limits :
==================

Echo Tag name - 36 character max - UPPER CASE
Echo Group - 16 characters max - 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 - 48 characters which can be /REAL, /SYS & /MOD with a
practical maximum of any of these or NONE or other
comments. Note that the three keywords MUST be upper case.
They MUST also precede any other text.
Any other text can be mixed case.
Echo Distribution - 36 characters. Any text.
Echo Gateway - 36 characters. Any text
Echo Lang - 16 characters - any case but converted to 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
but not \ / or space.

All sizes assume that one byte equals one character so use a standard character
set as the software does !

elist Operations mini version
-----------------------------

Elist Program:
-------------
The elist program consists of three primary processes driven by one to four parameters namely -

Parameter one:
UPDATE Run 24 times per day at 30 minutes past the hour with the last at 23:30
This process will also run WARN and REPORT on the first of each month.

WARN Run monthly on first of month before REPORT - This process
will delete out of time / warning echos where there has been one
warnings issued over a month period after the 10 month time period
since the last MOD-UPD (update) has been received.
In reality, they are not deleted but transferred over to the Backbone
listings with elistmaint as the new so called moderator.
This means that no echo will be auto deleted unless there has been a
minimum period of 10 + 1 months + 1 from the last update or a request
to delete the echo via a MOD-DEL message and that will still stay
until the next WARN run. This runs 1st month after 23:30.

REPORT Run monthly on first of the month after 23:30 the UPDATE & WARN runs.
This process create two primary files - for each group under control
such as FIDO (using the name ELIST) as ELIST.NA (a list of areas by
Echotag name and Title), and ELIST.RPT a details report for each echo
in Echo Tag order. This file ELIST.RPT for January and July a more
detailed is generated that includes a copy of any Rules for all echos
in both the ELIST system as well as the Backbone with all BACKBONE
areas so marked.
For non ELIST and FIDO net areas a .NO file that holds deleted echo
areas that are held for 12 months before being deleted. In the event
that a deleted echo is reinstated the entry in the .NO file is removed.
As expired echo's in the ELIST files are transferred to the Backbone
the .NO file is not created for FIDO.
Any echo that is deleted by use of a submission file from a registered
moderator the echo is deleted as it is deemed inactive with no postings
for a period no shorter than 12 months it is not transferred to the
backbone not stored in the .NO file - it is gone.

Various housekeeping jobs are then run as well as creating the ELST archive for
the month past that is then sent to all links of the BBS system. Likewise for all ELIST echo postings by the system. Various back ups are created and stored in a range of other systems when connected, for security.

There are other processes that are not described as they are used under system,
security or testing.

Emaint Program:
--------------

The emaint program has only one process.

Run Interactive Maintenance only as needed.

This will add, update or delete an existing echo entry as needed or mark a echo
as being on the BACKBONE. It also provides optional displayed listing of all echo's in the system where use of arrow down or up can move between the displayed echo's and the high-lighted one selected for examination or change.



Updated:
2022/04/05 Vincent Coen. 2:250/1, vbcoen=at=gmail.com
Text, grammar, typo's and updates.
2022/05/05 Removed a reference to sending to 250/1.
2022/06/01 Minor corrections.


--- MBSE BBS v1.0.8 (Linux-x86_64)
* Origin: The Elist Maintainer (2:250/1)