MSGID: 2:250/1@fidonet 47655575   
   PID: MBSE-FIDO 1.0.8 (Linux-x86_64)   
   CHRS: UTF-8 4   
   TZUTC: 0100   
   TID: MBSE-FIDO 1.0.8 (Linux-x86_64)   
                               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)   
   SEEN-BY: 1/123 15/0 18/200 25/0 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: 250/1 292/854 229/426