• Current Help Information for ELIST processing

    From Vincent Coen@2:250/1 to All on Sat May 9 15:27:02 2020
    ELIST Maintenance Program
    ~~~~~~~~~~~~~~~~~~~~~~~~~

    This document is to show the basic format what is needed to submit a MOD-ADD or
    MOD-UPD or a rules file submission to the elist maintainer at
    2:250/1 or 2:25/21 using a file only, at least for the moment.

    All keyword are formed as as two primary elements where the first is the keyword
    itself followed by space then the next element that will depend on the keyword itself.

    There are a few keywords that MUST always be used and are therefore mandatory for all submissions.

    These are listed below along with all others and marked by an * at the beginning
    of the keyword name. The keywords consist of two segments, the characters that are tested for, in upper case (capitalised) and the remainder in lower case that makes them more readable.
    You must always supply the characters in capitals, the rest are ignored.

    References to Xnn means the maximum size in characters of the field after the keyword, i.e.,
    X75 means you can use up to 75 characters a to z, A to Z and 0 to 9 with
    full stop, comma and hyphen ( - ) etc.

    Using larger will, at best mean that any characters outside the limit will
    be ignored and at worst will result in a error report and the submission
    being rejected.

    The entire content of the submission is examined and all errors and warnings
    noted where at the end, any such problems are reported in the ELIST echo.

    List of keywords that can be used in any submission, the first block are the one's that MUST be always supplied in the suggested order.


    Keyword Sub keywords or other text
    ------- --------------------------

    Always required:

    *SUBJect MOD-UPD or MOD-ADD or MOD-DEL
    When Netmail and emails submissions are accepted
    MOD-ADD, MOD-UPD or MOD-DEL must be in the message subject
    line - hence one of the reasons for the need of this keyword.

    *GROUP <Abbrev. of Network; i.e. FIDO) X16.
    Default is FIDO but this keyword must be provided in case
    other networks are being supported.

    *TAGname <areatag> X36. Warning some older BBS systems may not support
    areatag names longer than 8 characters.

    *FROM <Contact Address> See lower for the format of this.
    Details of the sender of message where any replies regarding
    errors or confirmation of status of submission is made to.
    <Node as a Netmail address format: zone:net/node{@domain}
    Moderator node address (can be a registered echo Co-Moderator)

    Normally this address should be the Mod or a Co-Mod and can
    change depending on who sent in the submission. There is no
    option for an email address element but you should include
    your name.

    *TITLe <A one line brief area description> X72.

    *DESCription <Description of the echo> A maximum of 15 lines where the text
    is a maximum of 75 characters (not including the keyword
    'DESC').

    *MODerator Contact Address. See lower for the format of this.
    This keyword MUST be submitted before any COMODn keywords.
    For COMODn see more information below.

    *LANG Language used in this echo X16 (default is ENGLISH).
    Should always be provided. Not every one reads English :)

    *PASSword <current password>, <new password> X36, X36.
    [Note the required space after the comma (',') if new
    password is used.]
    Any standard characters can be used and is case sensitive
    ABCD is NOT the same as aBcD.

    The following keywords can be used as required for the specific echo.

    RULEs <A one line description of the rules> X75
    Can also be DELETE | NONE | spaces
    DELETE will remove any existing rule file and then be treated
    as if NONE was supplied.
    NONE There are no rules for this echo.
    The same as if the keyword is not supplied.
    Can be omitted, but also see RULETEXT.
    If both RULES and RULETEXT are omitted then there are no rules
    If both are supplied, the content from RULETEXT overrides.
    NOTE that the above symbol '|' means or, i.e., a choice.
    For a multi line set of rules see keyword RULETEXT.

    COMODn Where n = 1, 2, 3 or 4.
    Next word/s <Contact Address>
    See below for more details of the format for this.
    This keyword replaces the old keyword COMOD and should be
    placed any where after the MOD keyword.
    It's usage allows the moderator to control precisely where
    each Co-Moderator sits in the list of four Co-Mods.
    It is recommended therefore to use this
    option over using just the COMOD keyword as
    this option will be removed soon.
    Next word can also be DELETE which will clear all contact
    information for that Co-Moderator position.

    REPLY-to Contact Address.
    Usually same as one in keywords MOD or FROM
    Note that usage of Email address is optional for all
    Keywords that use contact address as shown above
    and that the address in the FROM keywords is normally used.
    Yes this one is a bit redundant.

    VOLume <number of messages> nnnn per month. X4
    Use a realistic number. Anything after the number is
    ignored as per month is automatically assumed.
    This is only used to show a number in the ELIST.RPT
    otherwise serves no real use.

    RESTrictions </SYSop, /MODerator, /REAl> (only first four letters
    are needed) and/or other text> X72.
    You can have one, two or all three of these predefined
    values and you can add additional text at the end
    an example is :
    /SYS Region 1234 write access only.

    The following are accepted :
    /REAl [ Real Names only ]
    /SYS [ SYSops only ]
    /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 in the [ ] as
    these get created for the ELIST.RPT and the posted report into
    the ELIST echo after each echo update.

    ORIGin <origination net address of the echo distribution> X36.
    More used in the days where almost all posts originated
    from one Netmail address, otherwise a bit redundant.

    DISTribution <distribution> Any text describing X72.

    GATEway <gateways> Any text describing X72.

    CHARSet <Language charcter set> {, Language Character set } X16
    One or more character sets used for a specific language other
    than English. If more than one specified seperated by a comma.
    This is to offer extra support when the language used needs
    special char sets to spport it such as for accents etc.
    Use sets for both Windows, Linux & other *nix based systems.
    Also see keyword LANG.
    E.g., UTF32, UTFabc,CP987,CP1094

    RULETEXT <Signifies start of appended Rules text data>
    MUST be the LAST Keyword that finishes with the end line '---'
    or '-+-'. X75 wide but NO line limits - as many as you need.
    This will generate a file as TAGname.RUL
    and the content will be listed in the ELIST.RPT reports.
    It will be treated exactly the same as a .RUL file and will
    in fact create one, replacing any existing rules file.
    Any and all lines even if consisting of spaces will be
    included.

    HELP <Respond with help message>
    The latest version of the longer help file !

    NEWPASSword Updated password that must be used with PASS and does
    the same job as the second parameter to PASS keyword.
    This keyword was used for testing but has been left
    in use in case it is needed.

    --- Or "-+-" terminates a RULETEXT keyword block.
    Also useful as you can place other text after, such as
    unused keywords, as they will be totally ignored.

    # Comment text, Ignore rest of the line.
    <blank> a Line starting with spaces will also be ignored.


    Contact Address
    ===============

    This information is the next word group after the following keywords:
    FROM, MOD, COMODn, REPLY.

    Formed of three elements where the first two are required, separated by
    commas in the form:

    < - Element one - > < - - - - - Element two - - - - > < Element three
    FirstName LastName, Zmmmm:Nmmmm.Kmmmm {.Pmmmm}{@demain}{, email@address}
    Z = zone, N = Net, K = Node with {optional P = Point or/and Domain}.
    mmmm = A number between 0 and 4095.

    The first two are required for responses posted to ELIST and if errors
    or expiry warnings also issued direct to the network address of
    MOD and to all Comod's if the warning # is above 1.
    Point and domain are totally optional and are not required.
    Note the leading commas are required for elements 2 and 3.
    {} Signify optional.
    You can use the characters {at} or =at= in place of the @ in the
    email address. They will be replaced by the @ symbol.
    Support for Email is not yet available.
    Support for receiving submissions via Netmail other than as files
    is not yet available but you CAN use Netmail file attachments.


    Redundant keywords
    ------------------

    COMODerator Contact Address. [ Use COMODn instead ]
    This keyword must always appear at any point AFTER a
    MOD keyword.
    See notes on New Keywords below and above.
    This keyword has been replaced by COMODn



    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.
    You will be sent the current version of file elisthlp.txt which may well go
    into more detail than this document but there again it might not:)

    Notes on RULES Processing:
    -------------------------

    Rules can be provided in one of two ways,

    1. Recommended by sending a rules file with the file name of Echo Tag as
    upper case plus extension of .RUL, i.e., MBSE.RUL

    It can be ANY number of lines but each line must not EXCEED 75 characters
    but can include blank lines for readability.
    (for those Bulletin Board Systems that have such width restrictions).

    2. Sending as part of a MOD-ADD or MOD-UPD file where the rules text lines
    follow immediately after the keyword RULETEXT and before the last line
    which is the terminator '---' or '-+-', or the end of the file.
    Again blank lines can be embedded within the text for readability.

    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. These rule files are stored in the rules
    directory found inside the weekly / month edition of ERyymmww.zip or
    ERULyymm.ZIP that are in turn in the archive ELyymmww.zip or ELSTyymm.ZIP.
    These along with the files ELST.RPT, ELIST.NA and if exists ELIST.NO
    are also included within the top level archive as well as the help files.


    Further Notes on Submissions
    ----------------------------

    If your submission has unknown keywords or contains bad data in place of such, the warning message 'EL219 Error Unknown keyword found' followed by the word found. If the word printed is of a valid word then there are bad characters before, caused by not using a text editor. You must never use any other type
    of editor and only use a TEXT editor as found on Windows, Linux and other *nix systems.

    For a full list of such messages that can appear as a response of a submission please see the end of this document.


    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.

    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. This method can also be used for a Co-Mod can take over an echo in the
    event of the Moderator being permanently unavailable. OF source this assumes that all Co Mods have a copy of the current MOD-ADD and/or MOD-UPD and any RULe
    files. It is recommended that for this reason alone, that all echo's have at least one Co Mod.

    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 over write one of these entries.

    After that is sent in and acknowledged, the new moderator can send in a update MOD-UPD containing their contact address details via keywords MOD and with a keyword COMOD1 DELETE to remove the previously created entry.
    If needed use PASS oldpassword, newpassword to change the existing password or use :
    PASS oldpassword
    NEWPASS anewpassword


    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 sensitive 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.

    A Reminder, a change of password can also be done using the PASS keyword i.e., PASS old-password, new-password Note the space after the comma ','.

    Examples for change of moderator - the current moderator sends:

    SUBJ MOD-UPD
    FROM 1:345/6
    TAG echoname
    PASS current-password {can also be current-password, new-password}
    GROUP FIDO
    COMOD1 new moderator Contact address, etc :
    COMOD1 Fred Blogs, 2:234/5, fboggs@gmailcom

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

    SUBJ MOD-UPD
    FROM 1:234/5
    TAG echoname
    PASS old-password, new-password
    GROUP FIDO
    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. ]

    For subsequent updates then, change PASS to reflect the new password after receiving an acknowledgment message via ELIST or Netmail.
    Remove the NEWPASS and COMOD entries, adding any other keywords that require changes if any.


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

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

    Warnings 2, 3 & 4 (the final followed by a Delete warning) is sent to the moderator and all Co-Moderators on record at their registered Netmail address as well as in ELIST.

    If an update has not arrived at the elist maintainer before the end of month 5 then the echo WILL be deleted with the tag and title transferred to the ELIST.NO
    file. This file contains the Echotag date deleted and the Title one line per echo

    Reminder:
    Any registered moderator including Co-moderators for a given echo can send in MOD-UPD .ECO file and/or a Rules file using the correct password.

    Note that the content of a MOD-UPD only requires at a minimum the following keywords :

    FROM
    SUBJ
    TAG
    PASS
    GROUP FIDO

    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 message/s regarding the problem/s
    found and sent to the sender's Netmail address (as on the FROM keyword) and the
    ELIST echo.

    Example for a new echo :

    SUBJ MOD-ADD
    TAG MBSE
    FROM Vince Coen, 2:250/1, vbcoen@gmail.com
    MOD Vince Coen, 2:250/1, vbcoen@gmail.com
    COMOD1 Fred Bloggs, 1:234/5
    GROUP FIDO
    LANG ENGLISH
    TITL The Linux/FreeBSD/OSX MBSE BBS Support Echo
    DESC The main aim of this echo is to help provide support and to pass on
    DESC problems regarding the Mbse BBS system software that runs under
    DESC Linux/FreeBSD/OSX operating systems between users and the programmers. DIST All Official Fidonet Backbones
    GATE NONE.
    VOLume 10
    ORIG 2:250/1
    PASS YourPaSsWord
    REST /Real

    If just updating in full, replace the above MOD-ADD with MOD-UPD

    If just updating to reset the warnings etc then this will do:

    SUBJ MOD-UPD
    TAG MBSE
    FROM Vince Coen, 2:250/1
    GROUP FIDO
    PASS YourPaSsWord


    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.
    All error messages result in the submission being rejected.
    Some warnings may not, but it is recommended to fix the problem and resubmit.

    WARNing n of 4: 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 .
    EL224 Error missing SUBJect.
    EL225 Invalid (Co)MODerator given in FROM,
    Echolist Update.
    EL228 Error INVALID contact Address in:
    EL230 Errors found in MOD submission, see messages:
    EL231 Ruletext rejected due to other reported errors
    EL232 Unknown Echo Group
    EL234 Netmail address missing
    EL235 Contact name Invalid
    EL236 Invalid/non numeric VOLume
    EL237 Error Invalid SUBJect

    These are warnings only but the process has still completed.

    EL229 Warning Invalid address changed to MODs Name.


    They are usually preceded by the Echo tag name.


    I hope the above information will answer any questions you might have but if not
    ask in the ELIST echo I will if needed update this file.

    Updated 2020/05/1 Vincent Coen - Support for new keyword CHARSet, typos &
    grammar.
    Make sure no line exceeds CC 80.



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