MSGID: 2:25/21@fidonet 6251e97b   
   PID: MBSE-FIDO 1.0.8 (Linux-armv7l)   
   CHRS: UTF-8 4   
   TZUTC: 0100   
   TID: MBSE-FIDO 1.0.8 (Linux-armv7l)   
                               ELIST Maintenance Programs   
                               ~~~~~~~~~~~~~~~~~~~~~~~~~~   
      
   These notes are mostly for a new elistmaint administrator of the Elist system   
   and likewise 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.   
      
   These notes as a help file are also for moderators and Co-Moderators for the   
   submission of MOD-ADD, MOD-UPD and MOD-DEL files sent direct to the   
   elistmaintainers  at 2:25/21.   
      
   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   
   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 and   
   FIDO.MBSE.DES  for the description.   
      
   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 also send in multiple changes to a echo with the submit files say   
   called ELIST1.ECO, ELIST2.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 and not be available on some keyboards.   
   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.   
      
   This 'Assumes' that the new moderator knows the password in use.   
      
   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, 1:234/5   
      
   Note the comma separators between each segment.   
      
   At the same time send :   
      
   as ECHONAME2.ECO   
   SUBJ MOD-UPD   
   FROM Fred Blogs, 1:234/5   
   TAG ECHONAME   
   GROUP FIDO   
   LANG ENGLISH   
   MOD  Fred_Blogs, 1:234/5 [ Changing the moderator name and address ]   
   PASS password   [ using the currently existing password ]   
     or   
   PASS old-password, new-password   
      
   As the system processes all files including .ECO files, in alphabetic sorted   
   order both 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 with the   
   current password present.   
      
   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   
   someone 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 co-mod gets these two files, and they are not in the format of :   
   ECHOTAG.ECO-ADD  and ECHOTAG.ECO-UPD they should change them so they are, just   
   in case.   
      
   Thse files can be submitted to the elist maintainers system at 2:25/21 in this   
   format as the extra characters after '-MOD' or '-UPD' are ignored.   
      
   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 file processing 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.   
      
   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 echo 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. Any problems that cause only a warning message to be issued will   
   still allow the Update or echo addition process to be completed.   
      
      
   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  (Must be first).   
                       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   
            after any updates on or after 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.   
            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 after    
   UPDATE.   
      
   REPORT   Run monthly on first of the month after the 23:30 UPDATE and 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 report 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 shown.   
            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 system are transferred to the Backbone   
            and 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 and not stored in the .NO file - it is gone !   
      
   Various housekeeping jobs are then run as well as creating the ELST archive    
   for   
   the past previous month 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 for system   
   security or testing.   
      
   Emaint Program:   
   --------------   
      
   The emaint program has only one process.   
      
   Run Interactive Maintenance only as needed by the elist maintainer.   
      
   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.   
      
   The following is a List of possible error or warning messages   
   -------------------------------------------------------------   
      
   These can appear as a response to a MOD-ADD, MOD-UPD or MOD-DEL submission   
   to the system and hopefully do not need explanations.   
      
   Most messages are preceded by a letter/number combination however a few do not   
   and these are used with other text messages.   
      
   All error messages result in the submission being rejected.   
   Some warnings may not, but it is recommended to fix the problem and resubmit.   
      
   Error EL213 is issued if you attempt to Update a echo that does not exist.   
   Error EL214 is issued if you attempt to Add a new echo when it already exists.   
    These are used to protect if a Moderator was using cut and paste when    
   building   
     a new submission from another echo area and made a mistake with the Echo    
   name.   
      
   ==> WARNing n of n: This Echo is expiring, please Update.   
   Expiration WARNing n.   
      
   EL201 ==> WARNing: Echo has Expired & will be Deleted very shortly.   
   EL202 Error TAGname not specified.   
   EL203 PASSword not specified.   
   EL204 Error Messenger (From) is missing.   
   EL205 Error PASSword validation failed.   
   EL206 ==> Expiration Warnings have been Reset.   
   EL207 ==> Pending Delete has been Cleared.   
   EL208 Error Too many COMODerators (only 4 allowed).   
   EL209 ==> Echo has been Flagged for Deletion.   
   EL210 ==> Rules file { TAG name }   
   { followed by one of these 4 messages ]   
    has been Purged.   
    has been Created.   
    has been Updated.   
    Had error when creating - Deleted.   
      
    ==> Echo Successfully Updated.   
   EL212 Error Missing Mandatory Keywords (FROM, TITL, MOD or SUBJ).   
   EL213 UPD to non existing area - Rejected.   
   EL214 MOD-ADD to existing area - Rejected.   
   EL215 Error Invalid or missing TITLe.   
   EL216 Error Invalid or missing MODerator.   
   ==> Echo successfully Added.   
   EL218 HELP File Requested:   
   EL219 Error Unknown keyword found:   
   EL220 Warning Too many Description lines, Max 15 lines truncated.   
   EL221 TAG {Tag name ]   
    Has been deleted .   
    migrated to backbone   
   EL224 Error missing SUBJect.   
   EL225 Invalid (Co)MODerator given in FROM,   
    Echolist Update.   
   EL228 Error INVALID contact Address in:   
   EL229 Warning Invalid address changed to MODs Name   
   EL230 Errors found in MOD submission, see messages:   
   EL231 Ruletext rejected due to other reported errors   
   EL232 Unknown Echo Group   
   EL233 Error GROUP not specified.   
   EL234 Error Invalid SUBJect   
   EL235 Contact name Invalid   
      
   These are warnings only but the process has still completed.   
      
   They are usually preceded by the Echo tag name.   
      
      
   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.   
    2022/07/01       Added Warning and Error messages and minor corrections for   
                     processsing steps for WARN, REPORT etc.   
      
      
   --- MBSE BBS v1.0.8 (Linux-armv7l)   
    * Origin: Elist Maintainer at 2:25/21 (2:25/21)   
   SEEN-BY: 1/123 15/0 18/200 25/0 21 90/1 105/81 106/201 120/340 123/131   
   SEEN-BY: 129/305 330 331 153/7715 218/700 221/1 226/30 227/114 229/110   
   SEEN-BY: 229/111 112 113 206 317 400 424 426 428 470 664 700 250/0   
   SEEN-BY: 250/1 3 4 5 6 8 11 12 261/38 263/0 266/512 275/1000 282/1038   
   SEEN-BY: 292/854 317/3 320/219 322/757 342/200 396/45 460/58 633/280   
   SEEN-BY: 712/848 3634/12   
   PATH: 25/21 250/1 292/854 229/426