• Elist help

    From Vincent Coen@2:250/1 to All on Mon Mar 23 21:51:04 2020

    Quick Help for Moderators

    EList v5.0 - The Elist program
    Copyright (c) 2019 by Vincent Coen.


    Note: The information in this guide was taken from A Moderator's
    Guide to ECHOBASE (c) Dana Bell, with changes by Ben Ritchey and
    then customized by Vincent Coen.

    This file may be designated as the file to be sent in response to
    fatal errors and requests for HELP.

    EList v5 is a database program that maintains a database of
    echomail conference information. This particular program was
    written to meet the need to maintain and distribute echomail
    conference lists within FIDONet and with other networks.

    The FIDONet echolists published by this program include ELIST.NA
    a short, areafix uplink file format distributed monthly,
    ELIST.RPT, a longer descriptive file distributed on a monthly
    basis and ELIST.NO a short list of newly deleted echo's on a
    monthly basis.
    The last file ELIST.NO is now produced, as Ben did not
    produce it, may be it has out lived it's usefulness how ever.
    it will be a rolling list in that it will only contain deleted
    Echos with any renewed one's at any later date being removed.

    Moderators may add or update entries to the list by writing to
    ELIST or via Netmail, when these options are available as
    announced in ELIST.

    Currently such Additions, Updates or Deletions to the Echomail
    database should be sent as files as ECHOtag.RUL for any rules
    file and as ECHOtag.ECO as MOD-ADD, MOD-UPD or as MOD-DEL
    requests and these subjects must also be placed after the keyword
    SUBJect.

    Once Elist can process Netmail msgs they will be converted to a
    individual ECHOtag.ECO file and processed the same way without
    any more changes to the program. It is hoped that the same will
    apply to Emails
    The program will read these files and update the EList database,
    then post a reply to the ELIST conference and via Netmail.
    (Note: the Reply-to keyword overrides the FROM address if present)
    otherwise the FROM is always used.

    Address netmail messages

    To: ECHOLIST, (2:25/21)
    Subj: MOD UPD or MOD-UPD or MOD-DEL

    It is hoped that Updates via Email will be also available some
    time in the future via elistmaint@dykegrove.plus.net and this
    facility will be announced in the ELIST echo area once available
    along with any update to the email address used as well as usage
    of netmail to directly deliver such messages instead of using
    files.

    For the moment delivery of MOD-ADD, MOD-UPD and MOD-DEL messages
    MUST come as files only, along with any rules file with the
    following file names :
    For MOD-ADD, UPD and DEL as echotag.ECO
    For rules files as echotag.RUL
    Where echotag is the Echo area tag that is up to 36 characters
    in length. Note that for MOD requests you can also add the subject
    to the end of the extension i.e.,
    MBSE.ECOMOD-ADD or MBSE.ECOMOD-UPD
    [ Note that there is NO space between MOO and UPD or ADD only a
    hyphen. ]

    Use the following keywords to set the fields of your echo list
    submission and note that only the upper case characters are significant
    e.g., only SUBJ is needed for SUBJect.
    All keywords shown starting with * are mandatory - they MUST be provided.

    For keywords FROM, MOD, COMODn and REPLY the following is the format for
    your contact address where text with {} are optional extras and as needed:

    Contact Address:
    <name>, <node>[, <email>] Note the separating commas.
    name = first last names i.e., Fred Bloggs - Compulsory
    [ note the space between name elements ]
    node = zone:net/node {@domain} i.e.,
    2:345/678 - Compulsory
    email = name@emailaddess i.e., fbloggs@gmail.com You can use '{at}' in
    place of the at sign [@] and this will
    be the one used ELIST.RPT reporting.
    You may omit the elements between [] but name is needed to respond to
    an update in the ELIST echo so that a problem or not can be addressed
    to the specific poster along with the netmail address for sending a
    direct message as well.


    *SUBJect MOD-UPD or MOD-ADD or MOD-DEL
    A space can be between MOD and next word instead of
    the '-'.
    *FROM 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)
    {} Shows a optional extension and therefore can be omitted.
    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.
    *TAGname <areatag> x36.
    *TITLe <Brief area description> x72.
    *DESCription <Description of the echo> 15 lines x75.
    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.
    Can be omitted, also see RULETEXT.
    If both RULES and RULETEXT 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
    *MODerator Contact Address.
    This keyword MUST be submitted before any COMODn keywords.
    COMODerator Contact Address.
    This keyword must always appear at any point AFTER a
    MOD keyword. This keyword has been replaced by COMODn
    Where n = 1, 2, 3, 4.
    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.
    *PASSword <current password>, <new password> x36, x36.
    [Note the required space after the comma (',')
    if new password is used.]
    VOLume <number of messages> nnnnn per month.
    Use a realistic number. Anything after the number is
    ignored as per month is automatically assumed.
    RESTrictions </SYSop, /MODerator, /REAl (only first four letters
    are needed) or text> x72.
    ORIGin <origination net address of the distribution> x36.
    DISTribution <distribution> Any text describing x72.
    GATEway <gateways> Any text describing x72.
    *GROUP <Abbrev. of Network; i.e. FIDO) x16.
    *LANG Language used in this echo x16 (default = ENGLISH).
    RULETEXT <Signifies start of appended Rules text data> MUST be
    last Keyword that finishes with the end line '---'
    or '-+-' x75 wide but NO line limits.
    This will generate a file as TAGname.RUL
    but will not be listed in any reports. It will be
    treated exactly the same as a .RUL file and will
    in fact create one, replacing any existing rules file.
    HELP <respond with help message>
    The latest version of this file !
    NEWPASSword Updated password that must be used with PASS and does
    the same job as the second parameter to PASS keyword.
    --- Or "-+-" terminates MOD message but needed after
    a RULETEXT keyword block.

    * Means these are compulsory - they must always be supplied.
    xnn is the maximum size in characters of the field.


    New keywords or changes to modes of operation:
    NEWPASSword Updated password must be used with valid
    PASS keyword but also see the optional second
    parameter of the PASS keyword.

    COMOD DELETE Will delete ALL CoModerators and can then be
    followed in another submission with one or more
    COMODn (see below) after you have received an
    acknowledgement of the update in the echo ELIST.
    Do NOT use both in the same UPD submission.
    This may change in a later version of the
    maintenance elist program.
    This keyword is being replaced by the keyword
    COMODn (where n = 1, 2, 3 and 4.

    This keyword must always be used after a MOD keyword
    and NEVER before. There is a maximum limit of
    4 Co-Mods (and the same for applies to COMODn).

    The usage of the COMOD DELETE option is to allow
    a Co Mod moving over to be the new moderator
    perhaps with also using NEWPASS to replace the
    existing password which must be specified for
    the PASS keyword. Note that the keyword PASS
    can also be used as password, new-password
    instead of NEWPASS.

    COMODn Where n = 1, 2, 3 or 4. This keyword will
    replace the keyword COMOD. It's usage allows
    the moderator to control precisely where each
    Co-Moderator sits in the list of four.
    It is recommended therefore to use this
    option over using just the COMOD keyword as
    this option will be removed at some point.

    FROM Contact Address.
    Sending moderators netmail address in the form
    zone:net/node{@domain} This is compulsory.
    e.g., (Mod first lastname), 1:123/4@fidonet or
    just zone:net/node.
    Can be a registered CoMod.

    A minimum sample ADD file might have this :

    SUBJ MOD-ADD or MOD ADD
    TAG ECHOES
    GROU FIDO
    FROM Joe Sysop, 1:234/56
    PASS password
    LANG ENGLISH
    TITL FIDONet echoes discussion
    MOD Joe Sysop, 1:234/56
    DESC Discussions about echoes
    DESC and moderators.
    ---

    A minimum sample UPD file with no changes is :

    SUBJ MOD-UPD or MOD UPD
    TAG echo-name
    GROUP FIDO
    FROM Joe Sysop, 1:234/45
    PASS password
    ---

    Likewise for a DEL file just replace SUBJ with MOD-DEL or MOD DEL
    for the above sample.

    The keywords are truncated prior to checking, so matching will
    only be done for the capitalized portion of the keyword.
    Keywords may be capitalized or lowercase. The following three
    entries will have the same effect.

    TAG BOARD_GAMES
    Tagname BOARD_GAMES
    tag BOARD_GAMES

    Optionally end the message with --- or -+- (three-dashes or
    dash, Plus symbol, dash) indicating the end of the message file.
    With the exception of the DESCription field, only one entry is
    allowed per field. If multiple entries are included in the text,
    processing will continue but only the last one will be saved.
    If you don't have an entry for a field, there is no need to
    include the keyword (specifying JUST the keyword will
    erase/blank any existing value(s).
    Only the GROUP. ECHOtag, SUBJect, FROM and PASSword are necessary
    for updating.

    Update submissions to the echolist that don't require any changes
    may be done by including the above mentioned keywords.
    Full details already in the database will remain the same. New
    listings (echo) will again require the above mentioned keywords
    at a minimum.

    In order to delete an area from the list, you must use the
    subject MOD-DEL.

    When submitting an entry with the DESC field, be sure to begin
    each line with DESC and end it asa with any other keywords
    with a hard carriage return.

    Note that there can only be one line with a RULES keyword.
    For multi line rules use the keyword RULETEXT see below.
    (Some editors may word wrap all messages and strip carriage
    returns when saving. Some of these editors, however, may allow
    you to force carriage returns by indenting.) Avoid any that use
    the TAB as it is not honoured and any will be replaced by space.

    NOTE: blank lines after DESC keyword will RESET everything to
    null, as with all text based keywords.
    For RULETEXT, every line is included as is.

    You can insert the content of your Mod Rul text file (just the
    body of text) on the next and following lines right AFTER the
    RULETEXT keyword at the END of a MOD UPD submission (naturally
    for the same Tag name). The content of RULETEXT will create a
    .RUL with the same Echo tag name (as upper case) followed by the
    extension .RUL, again in upper case.

    For latest changes also see the document README-Elist where more
    information may be present to extend these details.


    Address any questions to the ELIST controller Vince Coen at
    2:250/1, by choice at the echolist echo itself, [ELIST] or via
    Email to vbcoen@gmail.com for a faster response.

    -=:{ End of EListHlp.Txt }:=-


    This document last updated :
    2020/01/23 Vincent Coen, 2:250/1 or vbcoen@gmail.com-
    Updated content for elist v5.0.30.
    2020/01/26 Vincent Coen, 2:250/1 or vbcoen@gmail.com.
    Updated content for elist v5.0.32.
    2020/02/21 Vincent Coen, 2:250/1 or vbcoen@gmail.com.
    Updated content for elist v5.0.50.
    2020/03/16 Vincent Coen, 2:250/1 or vbcoen@gmail.com
    Updated comments regarding ELIST.NO.


    --- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
    * Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1)
  • From Vincent Coen@2:250/1 to All on Wed Apr 7 18:50:56 2021

    Quick Help for Moderators

    EList v5.1c - The Elist program
    Copyright (c) 2020 by Vincent B. Coen, FBCS


    Note: The information in this guide was taken from A Moderator's
    Guide to ECHOBASE (c) Dana Bell, with changes by Ben Ritchey and
    then customized by Vincent Coen.

    This file may be designated as the file to be sent in response to
    requests for HELP.

    EList v5 is a database program that maintains a database of
    echomail conference information. This particular program was
    written to meet the need to maintain and distribute echomail
    conference lists within Fidonet and with other networks.

    The Fidonet Echolist published by this program include ELIST.NA
    a short, areafix uplink file format distributed monthly,
    ELIST.RPT, a longer descriptive file distributed on a monthly
    basis and ELIST.NO a short list of newly deleted echo's on a
    monthly basis.

    These updates are also currently provided weekly with a differing
    archive name so users can always be assured of an up to date list.

    The last file ELIST.NO is now produced, as Ben did not produce it,
    may be it has out lived it's usefulness however.
    It is a rolling list in that it will only contain deleted
    Echos along with the date, with any renewed one's at any later date
    being removed for that echo.
    Any entries will be removed after one year from being added as
    deemed to no longer being relevant hence the reason for the included
    date.

    Moderators may add or update entries to the list by supplying submission
    files sent directly to 2:25/21 or via Netmail when this option is
    available as announced in ELIST. The use of Email to do the same as
    Netmail is also being examined to try and get that available again
    it will be announced in ELIST when it is ready.

    Currently such Additions, Updates or Deletions to the Echomail
    database must be sent as files as ECHOtag.RUL for any rules
    file and as ECHOtag.ECO as MOD-ADD, MOD-UPD or MOD-DEL
    requests and these subjects MUST be placed after the keyword
    SUBJect.

    Once Elist can process Netmail msgs they will be converted to a
    individual ECHOtag.ECO file and processed the same way without
    any more changes to the program. It is hoped that the same will
    apply to Emails.
    The program will read these files and update the EList database,
    then post a reply to the ELIST conference and via Netmail.

    The FROM address is always used for replies.


    It is hoped that Updates via Email will be also available some
    time in the future via elistmaint@gmail.com and this
    facility will be announced in the ELIST echo area once available
    along with any update to the email address used as well as usage
    of netmail to directly deliver such messages instead of using
    files. This email address is not being monitored at this time.

    NOTE that only dropping off the files tag.ECO and tag.RUL to
    2:25/21 or 2:250/1 is supported for the moment.

    For the moment delivery of MOD-ADD, MOD-UPD and MOD-DEL messages
    MUST come as files only, along with any rules file with the
    following file names :
    For MOD-ADD, UPD and DEL as echotag.ECO
    For rules files as echotag.RUL
    Where echotag is the Echo area tag that is up to 36 characters
    in length. Note that for MOD requests you can also add the subject
    to the end of the extension i.e.,
    MBSE.ECOMOD-ADD or MBSE.ECOMOD-UPD
    [ Note that there is NO space between MOO and UPD or ADD only a
    hyphen. ]
    When sending in multiple submissions for the same echo you should add
    a number after the echotag name as all submissions are processed in
    sorted alphabetic order, i.e., MBSE1.ECO MBSE2.ECO.

    Use the following keywords to set the fields of your echo list
    submission and note that only the upper case characters are significant
    e.g., only SUBJ is needed for SUBJect.
    All keywords shown starting with * are mandatory - they MUST be provided.

    For keywords FROM, MOD, COMODn and REPLY the following is the format for
    your contact address where text with {} are optional extras and as needed:

    Contact Address:
    A1 A2 A3 Sub field class name as used below.
    <name>, <node>[, <email>] Note the (required) separating commas.
    A1 name = first last names i.e., Fred Bloggs - Compulsory
    [ note the space between name elements ]
    A2 node = zone:net/node {@domain} i.e.,
    2:345/678 - Compulsory.
    A3 email = name@emailaddress i.e., fbloggs@gmail.com You can use '{at}'
    or '=at=' in place of the at sign [@] and this will
    be the one used in ELIST reporting once email support is
    operational.

    You may omit the elements between [] but name is needed to respond to
    an update in the ELIST echo so that a problem or not, can be addressed
    to the specific poster along with the netmail address for sending a
    direct message as well. If omitted, a posting could be addressed to
    SYSOP, UNKnown, 'No Idea' and other variations depending on where in the
    elist program the posting report is issued (helps in debugging).
    None of which, aids the moderator doing a search on their name to check
    the latest postings.

    KEYWORDS in use Where characters in UPPER CASE are relevant
    and the * signifies a mandatory keyword -
    (You Must provide it but without the '*').

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

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

    *FROM 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)
    {} Shows a optional extension and therefore can be omitted.
    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.

    *TAGname <areatag> x36.

    *TITLe <Brief area description> x72.

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

    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.
    Can be omitted, also see RULETEXT.
    If both RULES and RULETEXT 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.

    *MODerator Contact Address.
    This keyword MUST be submitted before any COMODn keywords.

    For COMODn see more information under new keywords
    but note that COMODn HAS replace 'COMOD '.

    COMODn Where n = 1, 2, 3 or 4. This keyword has
    replaced the keyword COMOD. It's usage allows
    the moderator to control precisely where each
    Co-Moderator sits in the list of four.
    Next word can be DELETE which will clear all contact
    information for that Co-Moderator otherwise the next word
    is the contact address for that Co-Moderator.

    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.
    This keyword is some what redundant as FROM is used to
    respond to for all issues and reporting.

    *PASSword <current password>, <new password> x36, x36.
    [Note the required space after the comma (',')
    if new password is used.]

    VOLume <number of messages> nnnnn per month.
    Use a realistic number. Anything after the number is
    ignored as per month is automatically assumed.

    RESTrictions </SYSop, /MODerator, /REAl> (Only the first four letters
    are needed along with /) or text> x72.
    These predefined settings can be supplied in any order.
    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.

    ORIGin <Origination net address of the distribution> x36.
    More used in the days where almost all posts originated
    from one netmail address.

    DISTribution <distribution> Any text describing x72.

    GATEway <gateways> Any text describing x72.

    *GROUP <Abbrev. of Network; i.e. FIDO) x16.
    Default is FIDO but this keyword must be provided.

    *LANG Language used in this echo x16 (default = ENGLISH).
    This is a ONE word so that any software reading it
    can understand.

    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 consisting of spaces will be included.

    HELP <respond with help message>
    The latest version of this file !

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

    * Means these are compulsory - they must always be supplied.
    xnn is the maximum size in characters of the field after the keyword.


    New keywords or changes to modes of operation:
    ==============================================

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

    *FROM Contact Address.
    Sending moderators address see above for the exact
    format
    Can also be any registered CoMod for the echo.

    COMODn Where n = 1, 2, 3 or 4. This keyword has replaced
    the redundant keyword COMOD. It's usage allows
    the moderator to control precisely where each
    Co-Moderator sits in the list of four.
    DELETE will remove any contact information for
    the specific Co Moderator.

    # In the first character position of a line that is NOT
    in a RULETEXT block.
    The line will be ignored

    = Treated axactly the same as #

    Spaces When not in a RULETEXT block will also be ignored,

    A minimum example MOD-ADD file might have this :

    SUBJ MOD-ADD
    TAG ECHOES
    GROUP FIDO
    FROM Joe Sysop, 1:234/56
    PASS password
    LANG ENGLISH
    TITL FIDONet echoes discussion
    MOD Joe Sysop, 1:234/56
    DESC Discussions about echoes and moderators.

    Which will create a new echo entry for ECHOES for the FIDO network
    using the English language created and moderated by Joe Sysop.

    A minimum example MOD-UPD file with no changes is :

    SUBJ MOD-UPD
    TAG echo-name
    GROUP FIDO
    FROM Joe Sysop, 1:234/45
    PASS password

    Likewise for a MOD-DEL file just replace SUBJ with MOD-DEL for the above
    example. This is actioned during the next expiry warning run

    The keywords are truncated prior to checking, so matching will
    only be done for the capitalised portion of the keyword.
    Keywords may be capitalized or lower case. The following three
    entries will have the same effect.

    TAG BOARD_GAMES
    Tagname BOARD_GAMES
    tag BOARD_GAMES

    However the capitalised text in the keyword descriptions above show
    the elements of a keyword that MUST be supplied regardless of the
    case supplied in the submission.

    Optionally end the message with --- or -+- (three-dashes or
    dash, Plus symbol, dash) indicating the end of the message file.
    This should be supplied if using keyword RULETEXT otherwise is NOT
    needed.

    With the exception of the DESCription field, only one entry is
    allowed per field. If multiple entries are included in the text,
    processing will continue but only the last one will be saved.
    If you don't have an entry for a field, there is no need to
    include the keyword (specifying JUST the keyword will
    erase/blank any existing value(s) for keywords
    REPLY, REST. DIST, ORIG, GATE.
    COMODn must use DELETE to remove any existing details for that co-mod.

    Only the GROUP. ECHOtag, SUBJect, FROM and PASSword are necessary
    for updating.

    Update submissions to the Echolist that don't require any changes
    may be done by including the above mentioned keywords.
    Full details already in the database will remain the same.
    New echos, will again require the above mentioned keywords
    at a minimum.

    In order to delete an area from the list, you must use the
    subject MOD-DEL.

    When submitting an entry with the DESC field, be sure to begin
    each line with DESC and end it as with any other keywords
    with a hard carriage return.

    Note that there can only be one line with a RULES keyword.
    For multi line rules use the keyword RULETEXT see below.
    (Some editors may word wrap all messages and strip carriage
    returns when saving. Some of these editors, however, may allow
    you to force carriage returns by indenting.) Avoid any that use
    the TAB as it is not honoured and any will be replaced by space.

    Using RULEs DELETE will clear content of rules AND delete any
    existing .RUL file.

    NOTE: blank lines after DESC keyword will RESET everything to
    null, as with all text based keywords.
    For RULETEXT, every line is included as is.

    You can insert the content of your MOD-RUL text file (just the
    body of text) on the next and following lines right AFTER the
    RULETEXT keyword at the END of a MOD-UPD submission (naturally
    for the same Tag name). The content of RULETEXT will create a
    .RUL with the same Echo tag name (as upper case) followed by the
    extension .RUL, again in upper case.

    For latest changes also see the documents README-Elist
    and Fast-Readme.txt where more information may be present to extend
    these details. The Fast-Readme file is always kept up too date.


    Address any questions to the ELIST controller Vince Coen at
    2:25/21, by choice at the Echolist echo itself, [ELIST] or via
    Email to vbcoen@gmail.com for a faster response.

    -=:{ End of EListHlp.Txt }:=-


    This document last updated :
    2020/03/24 Vincent Coen, 2:250/1 or vbcoen@gmail.com
    Updated content for readability, helpfully.
    2020/04/12 Tidy up explanations on keywords.
    2020/04/19 Spelling errors mostly on the original.
    2020/05/08 Updated version of Elist to current.
    2020/05/24 Updated to match latest version of elist (5.1.60) and the
    Fast-Readme.txt help file.
    2020/12/11 Minor grammar fixes and CR date.



    --- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
    * Origin: The Elist Maintainer (2:250/1)
  • From Vincent Coen@2:250/1 to All on Sat May 1 15:00:24 2021

    Quick Help for Moderators

    EList v5.2c - The Elist program
    Copyright (c) 2020 - 2021 by Vincent B. Coen, FBCS


    Note: The information in this guide was taken from A Moderator's
    Guide to ECHOBASE (c) Dana Bell, with changes by Ben Ritchey and
    then customized by Vincent Coen.

    This file may be designated as the file to be sent in response to
    requests for HELP.

    EList v5 is a database program that maintains a database of
    echomail conference information. This particular program was
    written to meet the need to maintain and distribute echomail
    conference lists within Fidonet and with other networks.

    The Fidonet Echolist published by this program include ELIST.NA
    a short, areafix uplink file format distributed monthly,
    ELIST.RPT, a longer descriptive file distributed on a monthly
    basis and ELIST.NO a short list of all deleted echo's.

    It is a rolling list in that it will only contain deleted
    Echos along with the date, with any renewed one's at any later date
    within 12 months being removed for the specific echo.
    Any entries will be removed after one year from being added as
    deemed to no longer being relevant hence the reason for the included
    date.

    Moderators may add or update entries to elist by supplying submission
    files sent directly to 2:25/21 or 2:250/1.

    Currently such Additions, Updates or Deletions to the Echomail
    database must be sent as files as ECHOtag.RUL for any rules
    file and as ECHOtag.ECO as MOD-ADD, MOD-UPD or MOD-DEL
    requests and these subjects MUST be placed after the keyword
    SUBJect.

    Once Elist can process Netmail msgs they will be converted to a
    individual ECHOtag.ECO file and processed the same way without
    any more changes to the program. It is hoped that the same will
    apply to Emails.
    The program will read these files and update the EList database,
    then post a reply to the ELIST conference and via Netmail.

    These options i.e., via netmail or email is NOT currently available as a
    software solution has not yet been found for use under Linux.

    It is hoped that Updates via Email will be also available some
    time in the future via elistmaint@gmail.com and this
    facility will be announced in the ELIST echo area once available
    along with any update to the email address used as well as usage
    of netmail to directly deliver such messages instead of using
    files. This email address is NOT being monitored at this time.

    NOTE that ONLY dropping off the files tag.ECO and tag.RUL to
    2:25/21 or 2:250/1 is supported for the moment.

    The FROM address is always used for replies.

    For the moment delivery of MOD-ADD, MOD-UPD and MOD-DEL messages
    MUST come as files only, along with any rules file with the
    following file names :
    For MOD-ADD, UPD and DEL as echotag.ECO
    For rules files as echotag.RUL
    Where echotag is the Echo area tag that is up to 36 characters
    in length. Note that for MOD requests you can also add the subject
    to the end of the extension i.e.,
    MBSE.ECOMOD-ADD or MBSE.ECOMOD-UPD
    [ Note that there is NO space between MOO and UPD or ADD only a
    hyphen. ]
    When sending in multiple submissions for the same echo you should add
    a number after the echotag name as all submissions are processed in
    sorted alphabetic order, i.e., MBSE1.ECO MBSE2.ECO.

    Use the following keywords to set the fields of your echo list
    submission and note that only the upper case characters are significant
    e.g., only SUBJ is needed for SUBJect.
    All keywords shown starting with * are mandatory - they MUST be provided.

    For keywords FROM, MOD, COMODn and REPLY the following is the format for
    your contact address where text with {} are optional extras and as needed:

    Contact Address:
    A1 A2 A3 Sub field class name as used below.
    <name>, <node>[, <email>] Note the (required) separating commas.
    A1 name = first last names i.e., Fred Bloggs - Compulsory
    [ note the space between name elements ]
    A2 node = zone:net/node {@domain} i.e.,
    2:345/678 - Compulsory.
    A3 email = name@emailaddress i.e., fbloggs@gmail.com You can use '{at}'
    or '=at=' in place of the at sign [@] and this will
    be the one used in ELIST reporting once email support is
    operational.

    You may omit the elements between [] but name is needed to respond to
    an update in the ELIST echo so that a problem or not, can be addressed
    to the specific poster along with the netmail address for sending a
    direct message as well. If omitted, a posting could be addressed to
    SYSOP, UNKnown, 'No Idea' and other variations depending on where in the
    elist program the posting report is issued (helps in debugging).
    None of which, aids the moderator doing a search on their name to check
    the latest postings.

    KEYWORDS in use Where characters in UPPER CASE are relevant
    and the * signifies a mandatory keyword -
    (You Must provide it but without the '*').

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

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

    *FROM 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)
    {} Shows a optional extension and therefore can be omitted.
    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.

    *TAGname <areatag> x36.

    *TITLe <Brief area description> x72.

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

    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.
    Can be omitted, also see RULETEXT.
    If both RULES and RULETEXT 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.

    *MODerator Contact Address.
    This keyword MUST be submitted before any COMODn keywords.

    For COMODn see more information under new keywords
    but note that COMODn HAS replace 'COMOD '.

    COMODn Where n = 1, 2, 3 or 4. This keyword has
    replaced the keyword COMOD. It's usage allows
    the moderator to control precisely where each
    Co-Moderator sits in the list of four.
    Next word can be DELETE which will clear all contact
    information for that Co-Moderator otherwise the next word
    is the contact address for that Co-Moderator.

    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.
    This keyword is some what redundant as FROM is used to
    respond to for all issues and reporting.

    *PASSword <current password>, <new password> x36, x36.
    [Note the required space after the comma (',')
    if new password is used.]

    VOLume <number of messages> nnnnn per month.
    Use a realistic number. Anything after the number is
    ignored as per month is automatically assumed.

    RESTrictions </SYSop, /MODerator, /REAl> (Only the first four letters
    are needed along with /) or text> x72.
    These predefined settings can be supplied in any order.
    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.

    ORIGin <Origination net address of the distribution> x36.
    More used in the days where almost all posts originated
    from one netmail address.

    DISTribution <distribution> Any text describing x72.

    GATEway <gateways> Any text describing x72.

    *GROUP <Abbrev. of Network; i.e. FIDO) x16.
    Default is FIDO but this keyword must be provided.

    *LANG Language used in this echo x16 (default = ENGLISH).
    This is a ONE word so that any software reading it
    can understand.

    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 consisting of spaces will be included.

    HELP <respond with help message>
    The latest version of this file !

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

    * Means these are compulsory - they must always be supplied.
    xnn is the maximum size in characters of the field after the keyword.


    New keywords or changes to modes of operation:
    ==============================================

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

    *FROM Contact Address.
    Sending moderators address see above for the exact
    format
    Can also be any registered CoMod for the echo.

    COMODn Where n = 1, 2, 3 or 4. This keyword has replaced
    the redundant keyword COMOD. It's usage allows
    the moderator to control precisely where each
    Co-Moderator sits in the list of four.
    DELETE will remove any contact information for
    the specific Co Moderator.

    # In the first character position of a line that is NOT
    in a RULETEXT block.
    The line will be ignored.

    = Treated axactly the same as #

    Spaces When not in a RULETEXT block will also be ignored,

    A minimum example MOD-ADD file might have this :

    SUBJ MOD-ADD
    TAG ECHOES
    GROUP FIDO
    FROM Joe Sysop, 1:234/56
    PASS password
    LANG ENGLISH
    TITL FIDONet echoes discussion
    MOD Joe Sysop, 1:234/56
    DESC Discussions about echoes and moderators.

    Which will create a new echo entry for ECHOES for the FIDO network
    using the English language created and moderated by Joe Sysop.

    A minimum example MOD-UPD file with no changes is :

    SUBJ MOD-UPD
    TAG echo-name
    GROUP FIDO
    FROM Joe Sysop, 1:234/45
    PASS password

    Likewise for a MOD-DEL file just replace SUBJ with MOD-DEL for the above
    example. This is actioned during the next expiry warning run

    The keywords are truncated prior to checking, so matching will
    only be done for the capitalised portion of the keyword.
    Keywords may be capitalized or lower case. The following three
    entries will have the same effect.

    TAG BOARD_GAMES
    Tagname BOARD_GAMES
    tag BOARD_GAMES

    However the capitalised text in the keyword descriptions above show
    the elements of a keyword that MUST be supplied regardless of the
    case supplied in the submission.

    Optionally end the message with --- or -+- (three-dashes or
    dash, Plus symbol, dash) indicating the end of the message file.
    This should be supplied if using keyword RULETEXT otherwise is NOT
    needed.

    With the exception of the DESCription field, only one entry is
    allowed per field. If multiple entries are included in the text,
    processing will continue but only the last one will be saved.
    If you don't have an entry for a field, there is no need to
    include the keyword (specifying JUST the keyword will
    erase/blank any existing value(s) for keywords
    REPLY, REST. DIST, ORIG, GATE.
    COMODn must use DELETE to remove any existing details for that co-mod.

    Only the GROUP. ECHOtag, SUBJect, FROM and PASSword are necessary
    for updating.

    Update submissions to the Echolist that don't require any changes
    may be done by including the above mentioned keywords.
    Full details already in the database will remain the same.
    New echos, will again require the above mentioned keywords
    at a minimum.

    In order to delete a echo area from the list, you must use the
    subject MOD-DEL.

    When submitting an entry with the DESC field, be sure to begin
    each line with DESC and end it as with any other keywords
    with a hard carriage return.

    Note that there can only be one line with a RULES keyword.
    For multi line rules use the keyword RULETEXT see below.
    (Some editors may word wrap all messages and strip carriage
    returns when saving. Some of these editors, however, may allow
    you to force carriage returns by indenting.) Avoid any that use
    the TAB as it is not honoured and any will be replaced by space.

    Using RULEs DELETE will clear content of rules AND delete any
    existing .RUL file.

    NOTE: blank lines after DESC keyword will RESET everything to
    null, as with all text based keywords.
    For RULETEXT, every line is included as is.

    You can insert the content of your MOD-RUL text file (just the
    body of text) on the next and following lines right AFTER the
    RULETEXT keyword at the END of a MOD-UPD submission (naturally
    for the same Tag name). The content of RULETEXT will create a
    .RUL with the same Echo tag name (as upper case) followed by the
    extension .RUL, again in upper case.

    For latest changes also see the documents README-Elist
    and Fast-Readme.txt where more information may be present to extend
    these details. The Fast-Readme file is always kept up too date.


    Address any questions to the ELIST controller Vince Coen at
    2:25/21, by choice at the Echolist echo itself, [ELIST] or via
    Email to vbcoen@gmail.com for a faster response.

    -=:{ End of EListHlp.Txt }:=-


    This document last updated :
    2020/03/24 Vincent Coen, 2:250/1 or vbcoen@gmail.com
    Updated content for readability, helpfully.
    2020/04/12 Tidy up explanations on keywords.
    2020/04/19 Spelling errors mostly on the original.
    2020/05/08 Updated version of Elist to current.
    2020/05/24 Updated to match latest version of elist (5.1.60) and the
    Fast-Readme.txt help file.
    2020/12/11 Minor grammar fixes and CR date.
    2021/04/08 Minor grammar with additional notes & update s/w version.


    --- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
    * Origin: The Elist Maintainer (2:250/1)
  • From Vincent Coen@2:250/1 to All on Wed Sep 1 15:18:46 2021

    Quick Help for Moderators

    EList v5.1c - The Elist program
    Copyright (c) 2019 by Vincent Coen.


    Note: The information in this guide was taken from A Moderator's
    Guide to ECHOBASE (c) Dana Bell, with changes by Ben Ritchey and
    then customized by Vincent Coen.

    This file may be designated as the file to be sent in response to
    fatal errors and requests for HELP.

    EList v5 is a database program that maintains a database of
    echomail conference information. This particular program was
    written to meet the need to maintain and distribute echomail
    conference lists within Fidonet and with other networks.

    The Fidonet Echolist published by this program include ELIST.NA
    a short, areafix uplink file format distributed monthly,
    ELIST.RPT, a longer descriptive file distributed on a monthly
    basis and ELIST.NO a short list of newly deleted echo's on a
    monthly basis.

    The last file ELIST.NO is now produced, as Ben did not
    produce it, may be it has out lived it's usefulness how ever.
    it will be a rolling list in that it will only contain deleted
    Echos with any renewed one's at any later date being removed.
    Any entries will be removed after one year from being added as
    deemed to no longer being relevant.

    Moderators may add or update entries to the list by writing to
    ELIST or via Netmail, when these options are available as
    announced in ELIST.

    Currently such Additions, Updates or Deletions to the Echomail
    database must be sent as files as ECHOtag.RUL for any rules
    file and as ECHOtag.ECO as MOD-ADD, MOD-UPD or as MOD-DEL
    requests and these subjects must also be placed after the keyword
    SUBJect.

    Once Elist can process Netmail msgs they will be converted to a
    individual ECHOtag.ECO file and processed the same way without
    any more changes to the program. It is hoped that the same will
    apply to Emails
    The program will read these files and update the EList database,
    then post a reply to the ELIST conference and via Netmail.
    (Note: the Reply-to keyword overrides the FROM address if present)
    otherwise the FROM is always used. I must admit the REPLY-TO keyword
    is a bit redundant with the usage of FROM so might kill that off at some
    point.

    Address netmail messages

    To: ECHOLIST, (2:25/21)
    Subj: MOD-ADD or MOD-UPD or MOD-DEL

    It is hoped that Updates via Email will be also available some
    time in the future via elistmaint@dykegrove.plus.net and this
    facility will be announced in the ELIST echo area once available
    along with any update to the email address used as well as usage
    of netmail to directly deliver such messages instead of using
    files. This email address is not being monitored at this time.

    NOTE that only dropping off the files tag.ECO and tag.RUL to
    2:25/21 or 2:250/1 is supported for the moment.

    For the moment delivery of MOD-ADD, MOD-UPD and MOD-DEL messages
    MUST come as files only, along with any rules file with the
    following file names :
    For MOD-ADD, UPD and DEL as echotag.ECO
    For rules files as echotag.RUL
    Where echotag is the Echo area tag that is up to 36 characters
    in length. Note that for MOD requests you can also add the subject
    to the end of the extension i.e.,
    MBSE.ECOMOD-ADD or MBSE.ECOMOD-UPD
    [ Note that there is NO space between MOO and UPD or ADD only a
    hyphen. ]

    Use the following keywords to set the fields of your echo list
    submission and note that only the upper case characters are significant
    e.g., only SUBJ is needed for SUBJect.
    All keywords shown starting with * are mandatory - they MUST be provided.

    For keywords FROM, MOD, COMODn and REPLY the following is the format for
    your contact address where text with {} are optional extras and as needed:

    Contact Address:
    A1 A2 A3 Sub field class name as used below.
    <name>, <node>[, <email>] Note the separating commas.
    A1 name = first last names i.e., Fred Bloggs - Compulsory
    [ note the space between name elements ]
    A2 node = zone:net/node {@domain} i.e.,
    2:345/678 - Compulsory.
    A3 email = name@emailaddress i.e., fbloggs@gmail.com You can use '{at}'
    or '=at=' in place of the at sign [@] and this will
    be the one used in ELIST reporting once email support is
    operational.
    You may omit the elements between [] but name is needed to respond to
    an update in the ELIST echo so that a problem or not, can be addressed
    to the specific poster along with the netmail address for sending a
    direct message as well. If omitted a posting could be addressed to
    SYSOP, UNKnown, 'No Idea' and other variations depending on where in the
    elist program the posting report is issued (helps in debugging).
    None of which, aids the moderator doing a search on their name to check
    the latest postings.

    KEYWORDS in use (where characters in UPPER CASE are relevant)

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

    *SUBJect MOD-UPD or MOD-ADD or MOD-DEL
    A space can be between MOD and next word instead of
    the '-'. 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.

    *FROM 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)
    {} Shows a optional extension and therefore can be omitted.
    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.

    *TAGname <areatag> x36.

    *TITLe <Brief area description> x72.

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

    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.
    Can be omitted, also see RULETEXT.
    If both RULES and RULETEXT 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.

    *MODerator Contact Address.
    This keyword MUST be submitted before any COMODn keywords.

    For COMODn and COMOD see more information under new keywords
    but note that COMODn will replace 'COMOD ' soon.

    COMODn Where n = 1, 2, 3 or 4. This keyword will
    replace the keyword COMOD. It's usage allows
    the moderator to control precisely where each
    Co-Moderator sits in the list of four.
    It is recommended therefore to use this
    option over using just the COMOD keyword as
    this option will be removed at some point.
    Next word can be DELETE which will clear all contact
    information for that Co-Moderator.

    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.

    *PASSword <current password>, <new password> x36, x36.
    [Note the required space after the comma (',')
    if new password is used.]

    VOLume <number of messages> nnnnn per month.
    Use a realistic number. Anything after the number is
    ignored as per month is automatically assumed.

    RESTrictions </SYSop, /MODerator, /REAl> (only first four letters
    are needed) and / or 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.

    ORIGin <origination net address of the distribution> x36.
    More used in the days where almost all posts originated
    from one netmail address.

    DISTribution <distribution> Any text describing x72.

    GATEway <gateways> Any text describing x72.

    *GROUP <Abbrev. of Network; i.e. FIDO) x16.
    Default is FIDO but this keyword must be provided.

    *LANG Language used in this echo x16 (default = ENGLISH).

    CHARSet <Language character set> {, Language Character set } X16
    One or more character sets used for a specific language other
    than English. If more than one specified separated by a comma.
    This is to offer extra support when the language used needs
    special char sets to support 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 consisting of spaces will be included.

    HELP <respond with help message>
    The latest version of this 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 if it is needed.

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

    * Means these are compulsory - they must always be supplied.
    xnn is the maximum size in characters of the field after the keyword.


    New Changes to modes of operation:
    =================================

    # In the first character position of a line that is NOT
    in a RULETEXT block.
    The line will be ignored

    Spaces When not in a RULETEXT block will also be ignored and
    is in the first position.

    A minimum example ADD file might have this :

    SUBJ MOD-ADD
    TAG ECHOES
    GROUP FIDO
    FROM Joe Sysop, 1:234/56
    PASS password
    LANG ENGLISH
    TITL FIDONet echoes discussion
    MOD Joe Sysop, 1:234/56
    DESC Discussions about echoes
    DESC and moderators.
    ---

    Which will create a new echo entry for ECHOES for the FIDO network
    using the English language created and moderated by Joe Sysop.


    A minimum example UPD file with no changes is :

    SUBJ MOD-UPD
    TAG echo-name
    GROUP FIDO
    FROM Joe Sysop, 1:234/45
    PASS password
    ---

    Likewise for a DEL file just replace SUBJ with MOD-DEL for the above
    example. This is actioned during the next expiry warning
    run

    The keywords are truncated prior to checking, so matching will
    only be done for the capitalised portion of the keyword.
    Keywords may be capitalized or lower case. The following three
    entries will have the same effect.

    TAG BOARD_GAMES
    Tagname BOARD_GAMES
    tag BOARD_GAMES

    However the capitalised text in the keyword descriptions above show
    the elements of a keyword that MUST be supplied regardless of the
    case supplied in the submission.

    Optionally end the message with --- or -+- (three-dashes or
    dash, Plus symbol, dash) indicating the end of the message file.
    This should be supplied if using keyword RULETEXT otherwise is not
    needed.

    With the exception of the DESCription field, only one entry is
    allowed per field. If multiple entries are included in the text,
    processing will continue but only the last one will be saved.
    If you don't have an entry for a field, there is no need to
    include the keyword (specifying JUST the keyword will
    erase/blank any existing value(s) for keywords
    REPLY, REST. DIST, ORIG, GATE.
    COMODn must use DELETE to remove any existing details for that co-mod.

    Only the GROUP. ECHOtag, SUBJect, FROM and PASSword are necessary
    for updating.

    Update submissions to the Echolist that don't require any changes
    may be done by including the above mentioned keywords.
    Full details already in the database will remain the same.
    New echos, will again require the above mentioned keywords
    at a minimum.

    In order to delete an area from the list, you must use the
    subject MOD-DEL.

    When submitting an entry with the DESC field, be sure to begin
    each line with DESC and end it as with any other keywords
    with a hard carriage return.

    Note that there can only be one line with a RULES keyword.
    For multi line rules use the keyword RULETEXT see below.
    (Some editors may word wrap all messages and strip carriage
    returns when saving. Some of these editors, however, may allow
    you to force carriage returns by indenting.) Avoid any that use
    the TAB as it is not honoured and any will be replaced by space.

    Using RULEs DELETE will clear content of rules AND delete any
    existing .RUL file.

    NOTE: blank lines after DESC keyword will RESET everything to
    null, as with all text based keywords.
    For RULETEXT, every line is included as is.

    You can insert the content of your Mod Rul text file (just the
    body of text) on the next and following lines right AFTER the
    RULETEXT keyword at the END of a MOD UPD submission (naturally
    for the same Tag name). The content of RULETEXT will create a
    .RUL with the same Echo tag name (as upper case) followed by the
    extension .RUL, again in upper case.

    For latest changes also see the document README-Elist where more
    information may be present to extend these details.


    Address any questions to the ELIST controller Vince Coen at
    2:250/1, by choice at the Echolist echo itself, [ELIST] or via
    Email to vbcoen@gmail.com for a faster response.

    -=:{ End of EListHlp.Txt }:=-


    This document last updated :
    2020/03/24 Vincent Coen, 2:250/1 or vbcoen@gmail.com
    Updated content for readability, helpfully.
    2020/04/12 Tidy up explanations on keywords.
    2020/04/19 Spelling errors mostly on the original.
    2020/05/08 Updated version of Elist to current.
    2021/06/16 Added missing keyword CHARSet and removed changed keywords
    as in main text body.


    --- MBSE BBS v1.0.7.22 (GNU/Linux-x86_64)
    * Origin: The Elist Maintainer (2:250/1)
  • From Vincent Coen@2:250/1 to All on Fri Oct 1 00:00:20 2021

    Quick Help for Moderators

    EList v5.2c - The Elist program
    Copyright (c) 2019 - 2021 by Vincent Coen.


    Note: The information in this guide was taken from A Moderator's
    Guide to ECHOBASE (c) Dana Bell, with changes by Ben Ritchey and
    then customized by Vincent Coen.

    This file may be designated as the file to be sent in response to
    fatal errors and requests for HELP.

    EList v5 is a database program that maintains a database of
    echomail conference information. This particular program was
    written to meet the need to maintain and distribute echomail
    conference lists within Fidonet and with other networks.

    The Fidonet Echolist published by this program include ELIST.NA
    a short, areafix uplink file format distributed monthly,
    ELIST.RPT, a longer descriptive file distributed on a monthly
    basis and ELIST.NO a short list of newly deleted echo's on a
    monthly basis.

    The last file ELIST.NO is now produced, as Ben did not
    produce it, may be it has out lived it's usefulness how ever.
    it will be a rolling list in that it will only contain deleted
    Echos with any renewed one's at any later date being removed.
    Any entries will be removed after one year from being added as
    deemed to no longer being relevant.

    Moderators may add or update entries to the list by writing to
    ELIST or via Netmail, when these options are available as
    announced in ELIST.

    Currently such Additions, Updates or Deletions to the Echomail
    database must be sent as files as ECHOtag.RUL for any rules
    file and as ECHOtag.ECO as MOD-ADD, MOD-UPD or as MOD-DEL
    requests and these subjects must also be placed after the keyword
    SUBJect.

    Once Elist can process Netmail msgs they will be converted to a
    individual ECHOtag.ECO file and processed the same way without
    any more changes to the program. It is hoped that the same will
    apply to Emails
    The program will read these files and update the EList database,
    then post a reply to the ELIST conference and via Netmail.
    (Note: the Reply-to keyword overrides the FROM address if present)
    otherwise the FROM is always used. I must admit the REPLY-TO keyword
    is a bit redundant with the usage of FROM so might kill that off at some
    point.

    Address netmail messages

    To: ECHOLIST, (2:25/21)
    Subj: MOD-ADD or MOD-UPD or MOD-DEL

    It is hoped that Updates via Email will be also available some
    time in the future via elistmaint@dykegrove.plus.net and this
    facility will be announced in the ELIST echo area once available
    along with any update to the email address used as well as usage
    of netmail to directly deliver such messages instead of using
    files. This email address is not being monitored at this time.

    NOTE that only dropping off the files tag.ECO and tag.RUL to
    2:25/21 or 2:250/1 is supported for the moment.

    For the moment delivery of MOD-ADD, MOD-UPD and MOD-DEL messages
    MUST come as files only, along with any rules file with the
    following file names :
    For MOD-ADD, UPD and DEL as echotag.ECO
    For rules files as echotag.RUL
    Where echotag is the Echo area tag that is up to 36 characters
    in length. Note that for MOD requests you can also add the subject
    to the end of the extension i.e.,
    MBSE.ECOMOD-ADD or MBSE.ECOMOD-UPD
    [ Note that there is NO space between MOO and UPD or ADD only a
    hyphen. ]

    Use the following keywords to set the fields of your echo list
    submission and note that only the upper case characters are significant
    e.g., only SUBJ is needed for SUBJect.
    All keywords shown starting with * are mandatory - they MUST be provided.

    For keywords FROM, MOD, COMODn and REPLY the following is the format for
    your contact address where text with {} are optional extras and as needed:

    Contact Address:
    A1 A2 A3 Sub field class name as used below.
    <name>, <node>[, <email>] Note the separating commas.
    A1 name = first last names i.e., Fred Bloggs - Compulsory
    [ note the space between name elements ]
    A2 node = zone:net/node {@domain} i.e.,
    2:345/678 - Compulsory.
    A3 email = name@emailaddress i.e., fbloggs@gmail.com You can use '{at}'
    or '=at=' in place of the at sign [@] and this will
    be the one used in ELIST reporting once email support is
    operational.
    You may omit the elements between [] but name is needed to respond to
    an update in the ELIST echo so that a problem or not, can be addressed
    to the specific poster along with the netmail address for sending a
    direct message as well. If omitted a posting could be addressed to
    SYSOP, UNKnown, 'No Idea' and other variations depending on where in the
    elist program the posting report is issued (helps in debugging).
    None of which, aids the moderator doing a search on their name to check
    the latest postings.

    KEYWORDS in use (where characters in UPPER CASE are relevant)

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

    *SUBJect MOD-UPD or MOD-ADD or MOD-DEL
    A space can be between MOD and next word instead of
    the '-'. 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.

    *FROM 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)
    {} Shows a optional extension and therefore can be omitted.
    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.

    *TAGname <areatag> x36.

    +*TITLe <Brief area description> x72.

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

    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.
    Can be omitted, also see RULETEXT.
    If both RULES and RULETEXT 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.

    +*MODerator Contact Address.
    This keyword MUST be submitted before any COMODn keywords.

    COMODn Where n = 1, 2, 3 or 4. This keyword allows
    the moderator to control precisely where each
    Co-Moderator sits in the list of four.
    Next word can be DELETE which will clear all contact
    information for that Co-Moderator.

    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.

    *PASSword <current password>, <new password> x36, x36.
    [Note the required space after the comma (',')
    if new password is used.]

    VOLume <number of messages> nnnnn per month.
    Use a realistic number. Anything after the number is
    ignored as per month is automatically assumed.

    RESTrictions </SYSop, /MODerator, /REAl> (only first four letters
    are needed) and / or 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.

    ORIGin <origination net address of the distribution> x36.
    More used in the days where almost all posts originated
    from one netmail address.

    DISTribution <distribution> Any text describing x72.

    GATEway <gateways> Any text describing x72.

    *GROUP <Abbrev. of Network; i.e. FIDO) x16.
    Default is FIDO but this keyword must be provided.

    +*LANG Language used in this echo x16 (default = ENGLISH).

    CHARSet <Language character set> {, Language Character set } X16
    One or more character sets used for a specific language other
    than English. If more than one specified separated by a comma.
    This is to offer extra support when the language used needs
    special char sets to support 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 consisting of spaces will be included.

    HELP <respond with help message>
    The latest version of this 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 if it is needed.

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

    * Means these are compulsory - they must always be supplied.

    + Compulsory as for * but, NOT when modifying an echo (MOD-UPD), i.e., not
    required.
    xnn is the maximum size in characters of the field after the keyword.


    New Changes to modes of operation:
    =================================

    # In the first character position of a line that is NOT
    in a RULETEXT block.
    The line will be ignored

    Spaces When not in a RULETEXT block will also be ignored and
    is in the first position.

    A minimum example ADD file might have this :

    SUBJ MOD-ADD
    TAG ECHOES
    GROUP FIDO
    FROM Joe Sysop, 1:234/56
    PASS password
    LANG ENGLISH
    TITL FIDONet echoes discussion
    MOD Joe Sysop, 1:234/56
    DESC Discussions about echoes
    DESC and moderators.
    ---

    Which will create a new echo entry for ECHOES for the FIDO network
    using the English language created and moderated by Joe Sysop.


    A minimum example UPD file with no changes is :

    SUBJ MOD-UPD
    TAG echo-name
    GROUP FIDO
    FROM Joe Sysop, 1:234/45
    PASS password
    ---

    Likewise for a DEL file just replace SUBJ with MOD-DEL for the above
    example. This is actioned during the next expiry warning
    run

    The keywords are truncated prior to checking, so matching will
    only be done for the capitalised portion of the keyword.
    Keywords may be capitalized or lower case. The following three
    entries will have the same effect.

    TAG BOARD_GAMES
    Tagname BOARD_GAMES
    tag BOARD_GAMES

    However the capitalised text in the keyword descriptions above show
    the elements of a keyword that MUST be supplied regardless of the
    case supplied in the submission.

    Optionally end the message with --- or -+- (three-dashes or
    dash, Plus symbol, dash) indicating the end of the message file.
    This should be supplied if using keyword RULETEXT otherwise is not
    needed.

    With the exception of the DESCription field, only one entry is
    allowed per field. If multiple entries are included in the text,
    processing will continue but only the last one will be saved.
    If you don't have an entry for a field, there is no need to
    include the keyword (specifying JUST the keyword will
    erase/blank any existing value(s) for keywords
    REPLY, REST. DIST, ORIG, GATE.
    COMODn must use DELETE to remove any existing details for that co-mod.

    Only the GROUP. ECHOtag, SUBJect, FROM and PASSword are necessary
    for updating.

    Update submissions to the Echolist that don't require any changes
    may be done by including the above mentioned keywords.
    Full details already in the database will remain the same.
    New echos, will again require the above mentioned keywords
    at a minimum.

    In order to delete an area from the list, you must use the
    subject MOD-DEL.

    When submitting an entry with the DESC field, be sure to begin
    each line with DESC and end it as with any other keywords
    with a hard carriage return.

    Note that there can only be one line with a RULES keyword.
    For multi line rules use the keyword RULETEXT see below.
    (Some editors may word wrap all messages and strip carriage
    returns when saving. Some of these editors, however, may allow
    you to force carriage returns by indenting.) Avoid any that use
    the TAB as it is not honoured and any will be replaced by space.

    Using RULEs DELETE will clear content of rules AND delete any
    existing .RUL file.

    NOTE: blank lines after DESC keyword will RESET everything to
    null, as with all text based keywords.
    For RULETEXT, every line is included as is.

    You can insert the content of your Mod Rul text file (just the
    body of text) on the next and following lines right AFTER the
    RULETEXT keyword at the END of a MOD UPD submission (naturally
    for the same Tag name). The content of RULETEXT will create a
    .RUL with the same Echo tag name (as upper case) followed by the
    extension .RUL, again in upper case.


    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.

    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 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 or ECHOLIST echos and will if needed update this file.


    + -------------------------------- +
    For latest changes also see the document README-Elist where more
    information may be present to extend these details.


    Address any questions to the ELIST controller Vince Coen at
    2:250/1, by choice at the Echolist echo itself, [ELIST] or via
    Email to vbcoen@gmail.com for a faster response.



    -=:{ End of EListHlp.Txt }:=-


    This document last updated :
    2020/03/24 Vincent Coen, 2:250/1 or vbcoen@gmail.com
    Updated content for readability, helpfully.
    2020/04/12 Tidy up explanations on keywords.
    2020/04/19 Spelling errors mostly on the original.
    2020/05/08 Updated version of Elist to current.
    2021/06/16 Added missing keyword CHARSet and removed changed keywords
    as in main text body.
    2021/09/10 Changed compulsory keywords with modifier + for keywrds not
    needed with MOD-UPD.
    Included list of warning and error messages.



    --- MBSE BBS v1.0.7.22 (GNU/Linux-x86_64)
    * Origin: The Elist Maintainer (2:250/1)
  • From Vincent Coen@2:250/1 to All on Wed Dec 1 00:00:24 2021

    Quick Help for Moderators

    EList v5.2c - The Elist program
    Copyright (c) 2019 - 2021 by Vincent Coen.


    Note: The information in this guide was taken from A Moderator's
    Guide to ECHOBASE (c) Dana Bell, with changes by Ben Ritchey and
    then customized by Vincent Coen.

    This file may be designated as the file to be sent in response to
    fatal errors and requests for HELP.

    EList v5 is a database program that maintains a database of
    echomail conference information. This particular program was
    written to meet the need to maintain and distribute echomail
    conference lists within Fidonet and with other networks.

    The Fidonet Echolist published by this program include ELIST.NA
    a short, areafix uplink file format distributed monthly,
    ELIST.RPT, a longer descriptive file distributed on a monthly
    basis and ELIST.NO a short list of newly deleted echo's on a
    monthly basis.

    The last file ELIST.NO is now produced, as Ben did not
    produce it, may be it has out lived it's usefulness how ever.
    it will be a rolling list in that it will only contain deleted
    Echos with any renewed one's at any later date being removed.
    Any entries will be removed after one year from being added as
    deemed to no longer being relevant.

    Moderators may add or update entries to the list by writing to
    ELIST or via Netmail, when these options are available as
    announced in ELIST.

    Currently such Additions, Updates or Deletions to the Echomail
    database must be sent as files as ECHOtag.RUL for any rules
    file and as ECHOtag.ECO as MOD-ADD, MOD-UPD or as MOD-DEL
    requests and these subjects must also be placed after the keyword
    SUBJect.

    Once Elist can process Netmail msgs they will be converted to a
    individual ECHOtag.ECO file and processed the same way without
    any more changes to the program. It is hoped that the same will
    apply to Emails
    The program will read these files and update the EList database,
    then post a reply to the ELIST conference and via Netmail.
    (Note: the Reply-to keyword overrides the FROM address if present)
    otherwise the FROM is always used. I must admit the REPLY-TO keyword
    is a bit redundant with the usage of FROM so might kill that off at some
    point.

    Address netmail messages

    To: ECHOLIST, (2:25/21)
    Subj: MOD-ADD or MOD-UPD or MOD-DEL

    It is hoped that Updates via Email will be also available some
    time in the future via elistmaint@gmail.com and this
    facility will be announced in the ELIST echo area once available
    along with any update to the email address used as well as usage
    of netmail to directly deliver such messages instead of using
    files. This email address is not being monitored at this time.

    NOTE that only dropping off the files tag.ECO and tag.RUL to
    2:25/21 or 2:250/1 is supported for the moment.

    For the moment delivery of MOD-ADD, MOD-UPD and MOD-DEL messages
    MUST come as files only, along with any rules file with the
    following file names :
    For MOD-ADD, UPD and DEL as echotag.ECO
    For rules files as echotag.RUL
    Where echotag is the Echo area tag that is up to 36 characters
    in length. Note that for MOD requests you can also add the subject
    to the end of the extension i.e.,
    MBSE.ECOMOD-ADD or MBSE.ECOMOD-UPD
    [ Note that there is NO space between MOO and UPD or ADD only a
    hyphen. ]

    Use the following keywords to set the fields of your echo list
    submission and note that only the upper case characters are significant
    e.g., only SUBJ is needed for SUBJect.
    All keywords shown starting with * are mandatory - they MUST be provided.

    For keywords FROM, MOD, COMODn and REPLY the following is the format for
    your contact address where text with {} are optional extras and as needed:

    Contact Address:
    A1 A2 A3 Sub field class name as used below.
    <name>, <node>[, <email>] Note the separating commas.
    A1 name = first last names i.e., Fred Bloggs - Compulsory
    [ note the space between name elements ]
    A2 node = zone:net/node {@domain} i.e.,
    2:345/678 - Compulsory.
    A3 email = name@emailaddress i.e., fbloggs@gmail.com You can use '{at}'
    or '=at=' in place of the at sign [@] and this will
    be the one used in ELIST reporting once email support is
    operational.
    You may omit the elements between [] but name is needed to respond to
    an update in the ELIST echo so that a problem or not, can be addressed
    to the specific poster along with the netmail address for sending a
    direct message as well. If omitted a posting could be addressed to
    SYSOP, UNKnown, 'No Idea' and other variations depending on where in the
    elist program the posting report is issued (helps in debugging).
    None of which, aids the moderator doing a search on their name to check
    the latest postings.

    KEYWORDS in use (where characters in UPPER CASE are relevant)

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

    *SUBJect MOD-UPD or MOD-ADD or MOD-DEL
    A space can be between MOD and next word instead of
    the '-'. 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.

    *FROM 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)
    {} Shows a optional extension and therefore can be omitted.
    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.

    *TAGname <areatag> x36.

    +*TITLe <Brief area description> x72.

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

    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.
    Can be omitted, also see RULETEXT.
    If both RULES and RULETEXT 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.

    +*MODerator Contact Address.
    This keyword MUST be submitted before any COMODn keywords.

    COMODn Where n = 1, 2, 3 or 4. This keyword allows
    the moderator to control precisely where each
    Co-Moderator sits in the list of four.
    Next word can be DELETE which will clear all contact
    information for that Co-Moderator.

    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.

    *PASSword <current password>, <new password> x36, x36.
    [Note the required space after the comma (',')
    if new password is used.]

    VOLume <number of messages> nnnnn per month.
    Use a realistic number. Anything after the number is
    ignored as per month is automatically assumed.

    RESTrictions </SYSop, /MODerator, /REAl> (only first four letters
    are needed) and / or 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.

    ORIGin <origination net address of the distribution> x36.
    More used in the days where almost all posts originated
    from one netmail address.

    DISTribution <distribution> Any text describing x72.

    GATEway <gateways> Any text describing x72.

    *GROUP <Abbrev. of Network; i.e. FIDO) x16.
    Default is FIDO but this keyword must be provided.

    +*LANG Language used in this echo x16 (default = ENGLISH).

    CHARSet <Language character set> {, Language Character set } X16
    One or more character sets used for a specific language other
    than English. If more than one specified separated by a comma.
    This is to offer extra support when the language used needs
    special char sets to support 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 consisting of spaces will be included.

    HELP <respond with help message>
    The latest version of this 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 if it is needed.

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

    * Means these are compulsory - they must always be supplied.

    + Compulsory as for * but, NOT when modifying an echo (MOD-UPD), i.e., not
    required.
    xnn is the maximum size in characters of the field after the keyword.


    New Changes to modes of operation:
    =================================

    # In the first character position of a line that is NOT
    in a RULETEXT block.
    The line will be ignored

    Spaces When not in a RULETEXT block will also be ignored and
    is in the first position.

    A minimum example ADD file might have this :

    SUBJ MOD-ADD
    TAG ECHOES
    GROUP FIDO
    FROM Joe Sysop, 1:234/56
    PASS password
    LANG ENGLISH
    TITL FIDONet echoes discussion
    MOD Joe Sysop, 1:234/56
    DESC Discussions about echoes
    DESC and moderators.
    ---

    Which will create a new echo entry for ECHOES for the FIDO network
    using the English language created and moderated by Joe Sysop.


    A minimum example UPD file with no changes is :

    SUBJ MOD-UPD
    TAG echo-name
    GROUP FIDO
    FROM Joe Sysop, 1:234/45
    PASS password
    ---

    Likewise for a DEL file just replace SUBJ with MOD-DEL for the above
    example. This is actioned during the next expiry warning
    run

    The keywords are truncated prior to checking, so matching will
    only be done for the capitalised portion of the keyword.
    Keywords may be capitalized or lower case. The following three
    entries will have the same effect.

    TAG BOARD_GAMES
    Tagname BOARD_GAMES
    tag BOARD_GAMES

    However the capitalised text in the keyword descriptions above show
    the elements of a keyword that MUST be supplied regardless of the
    case supplied in the submission.

    Optionally end the message with --- or -+- (three-dashes or
    dash, Plus symbol, dash) indicating the end of the message file.
    This should be supplied if using keyword RULETEXT otherwise is not
    needed.

    With the exception of the DESCription field, only one entry is
    allowed per field. If multiple entries are included in the text,
    processing will continue but only the last one will be saved.
    If you don't have an entry for a field, there is no need to
    include the keyword (specifying JUST the keyword will
    erase/blank any existing value(s) for keywords
    REPLY, REST. DIST, ORIG, GATE.
    COMODn must use DELETE to remove any existing details for that co-mod.

    Only the GROUP. ECHOtag, SUBJect, FROM and PASSword are necessary
    for updating.

    Update submissions to the Echolist that don't require any changes
    may be done by including the above mentioned keywords.
    Full details already in the database will remain the same.
    New echos, will again require the above mentioned keywords
    at a minimum.

    In order to delete an area from the list, you must use the
    subject MOD-DEL.

    When submitting an entry with the DESC field, be sure to begin
    each line with DESC and end it as with any other keywords
    with a hard carriage return.

    Note that there can only be one line with a RULES keyword.
    For multi line rules use the keyword RULETEXT see below.
    (Some editors may word wrap all messages and strip carriage
    returns when saving. Some of these editors, however, may allow
    you to force carriage returns by indenting.) Avoid any that use
    the TAB as it is not honoured and any will be replaced by space.

    Using RULEs DELETE will clear content of rules AND delete any
    existing .RUL file.

    NOTE: blank lines after DESC keyword will RESET everything to
    null, as with all text based keywords.
    For RULETEXT, every line is included as is.

    You can insert the content of your Mod Rul text file (just the
    body of text) on the next and following lines right AFTER the
    RULETEXT keyword at the END of a MOD UPD submission (naturally
    for the same Tag name). The content of RULETEXT will create a
    .RUL with the same Echo tag name (as upper case) followed by the
    extension .RUL, again in upper case.


    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 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 or ECHOLIST echos and will if needed update this file.


    + -------------------------------- +
    For latest changes also see the document README-Elist where more
    information may be present to extend these details.


    Address any questions to the ELIST controller Vince Coen at
    2:250/1, by choice at the Echolist echo itself, [ELIST] or via
    Email to vbcoen@gmail.com for a faster response.



    -=:{ End of EListHlp.Txt }:=-


    This document last updated :
    2020/03/24 Vincent Coen, 2:250/1 or vbcoen@gmail.com
    Updated content for readability, helpfully.
    2020/04/12 Tidy up explanations on keywords.
    2020/04/19 Spelling errors mostly on the original.
    2020/05/08 Updated version of Elist to current.
    2021/06/16 Added missing keyword CHARSet and removed changed keywords
    as in main text body.
    2021/09/10 Changed compulsory keywords with modifier + for keywrds not
    needed with MOD-UPD.
    Included list of warning and error messages.
    2021/11/01 Added comment regarding some warming/error messages are
    with/without preceding letters/numbers.



    --- MBSE BBS v1.0.7.22 (GNU/Linux-x86_64)
    * Origin: The Elist Maintainer (2:250/1)
  • From Vincent Coen@2:250/1 to All on Tue Feb 1 00:00:02 2022

    Quick Help for Moderators

    EList v5.2d - The Elist program
    Copyright (c) 2019 - 2022 by Vincent Coen.


    Note: The information in this guide was taken from A Moderator's
    Guide to ECHOBASE (c) Dana Bell, with changes by Ben Ritchey and
    then customized by Vincent Coen.

    This file may be designated as the file to be sent in response to
    fatal errors and requests for HELP.

    EList v5 is a database program that maintains a database of
    echomail conference information. This particular program was
    written to meet the need to maintain and distribute echomail
    conference lists within Fidonet and with other networks.

    The Fidonet Echolist published by this program include ELIST.NA
    a short, areafix uplink file format distributed monthly,
    ELIST.RPT, a longer descriptive file distributed on a monthly
    basis and ELIST.NO a short list of newly deleted echo's on a
    monthly basis.

    The last file ELIST.NO is now produced, as Ben did not
    produce it, may be it has out lived it's usefulness how ever.
    it will be a rolling list in that it will only contain deleted
    Echos with any renewed one's at any later date being removed.
    Any entries will be removed after one year from being added as
    deemed to no longer being relevant.

    Moderators may add or update entries to the list by writing to
    ELIST or via Netmail, when these options are available as
    announced in ELIST.

    Currently such Additions, Updates or Deletions to the Echomail
    database must be sent as files as ECHOtag.RUL for any rules
    file and as ECHOtag.ECO as MOD-ADD, MOD-UPD or as MOD-DEL
    requests and these subjects must also be placed after the keyword
    SUBJect.

    Once Elist can process Netmail msgs they will be converted to a
    individual ECHOtag.ECO file and processed the same way without
    any more changes to the program. It is hoped that the same will
    apply to Emails
    The program will read these files and update the EList database,
    then post a reply to the ELIST conference and via Netmail.
    (Note: the Reply-to keyword overrides the FROM address if present)
    otherwise the FROM is always used. I must admit the REPLY-TO keyword
    is a bit redundant with the usage of FROM so might kill that off at some
    point.

    Address netmail messages

    To: ECHOLIST, (2:25/21)
    Subj: MOD-ADD or MOD-UPD or MOD-DEL

    It is hoped that Updates via Email will be also available some
    time in the future via elistmaint@gmail.com and this
    facility will be announced in the ELIST echo area once available
    along with any update to the email address used as well as usage
    of netmail to directly deliver such messages instead of using
    files. This email address is not being monitored at this time.

    NOTE that only dropping off the files tag.ECO and tag.RUL to
    2:25/21 or 2:250/1 is supported for the moment.

    For the moment delivery of MOD-ADD, MOD-UPD and MOD-DEL messages
    MUST come as files only, along with any rules file with the
    following file names :
    For MOD-ADD, UPD and DEL as echotag.ECO
    For rules files as echotag.RUL
    Where echotag is the Echo area tag that is up to 36 characters
    in length. Note that for MOD requests you can also add the subject
    to the end of the extension i.e.,
    MBSE.ECOMOD-ADD or MBSE.ECOMOD-UPD
    [ Note that there is NO space between MOO and UPD or ADD only a
    hyphen. ]

    Use the following keywords to set the fields of your echo list
    submission and note that only the upper case characters are significant
    e.g., only SUBJ is needed for SUBJect.
    All keywords shown starting with * are mandatory - they MUST be provided.

    For keywords FROM, MOD, COMODn and REPLY the following is the format for
    your contact address where text with {} are optional extras and as needed:

    Contact Address:
    A1 A2 A3 Sub field class name as used below.
    <name>, <node>[, <email>] Note the separating commas.
    A1 name = first last names i.e., Fred Bloggs - Compulsory
    [ note the space between name elements ]
    A2 node = zone:net/node {@domain} i.e.,
    2:345/678 - Compulsory.
    A3 email = name@emailaddress i.e., fbloggs@gmail.com You can use '{at}'
    or '=at=' in place of the at sign [@] and this will
    be the one used in ELIST reporting once email support is
    operational.
    You may omit the elements between [] but name is needed to respond to
    an update in the ELIST echo so that a problem or not, can be addressed
    to the specific poster along with the netmail address for sending a
    direct message as well. If omitted a posting could be addressed to
    SYSOP, UNKnown, 'No Idea' and other variations depending on where in the
    elist program the posting report is issued (helps in debugging).
    None of which, aids the moderator doing a search on their name to check
    the latest postings.

    KEYWORDS in use (where characters in UPPER CASE are relevant) in form of :

    KEYWord {one or more spaces} Sub keyword or other text

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

    *SUBJect MOD-UPD or MOD-ADD or MOD-DEL
    A space can be between MOD and next word instead of
    the '-'. 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.

    *FROM 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)
    {} Shows a optional extension and therefore can be omitted.
    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.

    *TAGname <areatag> x36.

    +*TITLe <Brief area description> x72.

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

    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.
    Can be omitted, also see RULETEXT.
    If both RULES and RULETEXT 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.

    +*MODerator Contact Address.
    This keyword MUST be submitted before any COMODn keywords.

    COMODn Where n = 1, 2, 3 or 4. This keyword allows
    the moderator to control precisely where each
    Co-Moderator sits in the list of four.
    Next word can be DELETE which will clear all contact
    information for that Co-Moderator.

    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.

    *PASSword <current password>, <new password> x36, x36.
    [Note the required space after the comma (',')
    if new password is used.]

    VOLume <number of messages> nnnnn per month.
    Use a realistic number. Anything after the number is
    ignored as per month is automatically assumed.

    RESTrictions </SYSop, /MODerator, /REAl> (only first four letters
    are needed) and / or 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.

    ORIGin <origination net address of the distribution> x36.
    More used in the days where almost all posts originated
    from one netmail address.

    DISTribution <distribution> Any text describing x72.

    GATEway <gateways> Any text describing x72.

    *GROUP <Abbrev. of Network; i.e. FIDO) x16.
    Default is FIDO but this keyword must be provided.

    +*LANG Language used in this echo x16 (default = ENGLISH).

    CHARSet <Language character set> {, Language Character set } X16
    One or more character sets used for a specific language other
    than English. If more than one specified separated by a comma.
    This is to offer extra support when the language used needs
    special char sets to support 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 consisting of spaces will be included.

    HELP <respond with help message>
    The latest version of this 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 if it is needed.

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

    * Means these are compulsory - they must always be supplied.

    + Compulsory as for * but, NOT when modifying an echo (MOD-UPD), i.e., not
    required.
    xnn is the maximum size in characters of the field after the keyword.


    New Changes to modes of operation:
    =================================

    # In the first character position of a line that is NOT
    in a RULETEXT block.
    The line will be ignored

    Spaces When not in a RULETEXT block will also be ignored and
    is in the first position.

    A minimum example ADD file might have this :

    SUBJ MOD-ADD
    TAG ECHOES
    GROUP FIDO
    FROM Joe Sysop, 1:234/56
    PASS password
    LANG ENGLISH
    TITL FIDONet echoes discussion
    MOD Joe Sysop, 1:234/56
    DESC Discussions about echoes
    DESC and moderators.
    ---

    Which will create a new echo entry for ECHOES for the FIDO network
    using the English language created and moderated by Joe Sysop.


    A minimum example UPD file with no changes is :

    SUBJ MOD-UPD
    TAG echo-name
    GROUP FIDO
    FROM Joe Sysop, 1:234/45
    PASS password
    ---

    Likewise for a DEL file just replace SUBJ with MOD-DEL for the above
    example. This is actioned during the next expiry warning
    run

    The keywords are truncated prior to checking, so matching will
    only be done for the capitalised portion of the keyword.
    Keywords may be capitalized or lower case. The following three
    entries will have the same effect.

    TAG BOARD_GAMES
    Tagname BOARD_GAMES
    tag BOARD_GAMES

    However the capitalised text in the keyword descriptions above show
    the elements of a keyword that MUST be supplied regardless of the
    case supplied in the submission.

    Optionally end the message with --- or -+- (three-dashes or
    dash, Plus symbol, dash) indicating the end of the message file.
    This should be supplied if using keyword RULETEXT otherwise is not
    needed.

    With the exception of the DESCription field, only one entry is
    allowed per field. If multiple entries are included in the text,
    processing will continue but only the last one will be saved.
    If you don't have an entry for a field, there is no need to
    include the keyword (specifying JUST the keyword will
    erase/blank any existing value(s) for keywords
    REPLY, REST. DIST, ORIG, GATE.
    COMODn must use DELETE to remove any existing details for that co-mod.

    Only the GROUP. ECHOtag, SUBJect, FROM and PASSword are necessary
    for updating.

    Update submissions to the Echolist that don't require any changes
    may be done by including the above mentioned keywords.
    Full details already in the database will remain the same.
    New echos, will again require the above mentioned keywords
    at a minimum.

    In order to delete an area from the list, you must use the
    subject MOD-DEL.

    When submitting an entry with the DESC field, be sure to begin
    each line with DESC and end it as with any other keywords
    with a hard carriage return.

    Note that there can only be one line with a RULES keyword.
    For multi line rules use the keyword RULETEXT see below.
    (Some editors may word wrap all messages and strip carriage
    returns when saving. Some of these editors, however, may allow
    you to force carriage returns by indenting.) Avoid any that use
    the TAB as it is not honoured and any will be replaced by space.

    Using RULEs DELETE will clear content of rules AND delete any
    existing .RUL file.

    NOTE: blank lines after DESC keyword will RESET everything to
    null, as with all text based keywords.
    For RULETEXT, every line is included as is.

    You can insert the content of your Mod Rul text file (just the
    body of text) on the next and following lines right AFTER the
    RULETEXT keyword at the END of a MOD UPD submission (naturally
    for the same Tag name). The content of RULETEXT will create a
    .RUL with the same Echo tag name (as upper case) followed by the
    extension .RUL, again in upper case.


    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 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 or ECHOLIST echos and will if needed update this file.


    + -------------------------------- +
    For latest changes also see the document README-Elist where more
    information may be present to extend these details.


    Address any questions to the ELIST controller Vince Coen at
    2:250/1, by choice at the Echolist echo itself, [ELIST] or via
    Email to vbcoen@gmail.com for a faster response.



    -=:{ End of EListHlp.Txt }:=-


    This document last updated :
    2020/03/24 Vincent Coen, 2:250/1 or vbcoen@gmail.com
    Updated content for readability, helpfully.
    2020/04/12 Tidy up explanations on keywords.
    2020/04/19 Spelling errors mostly on the original.
    2020/05/08 Updated version of Elist to current.
    2021/06/16 Added missing keyword CHARSet and removed changed keywords
    as in main text body.
    2021/09/10 Changed compulsory keywords with modifier + for keywrds not
    needed with MOD-UPD.
    Included list of warning and error messages.
    2021/11/01 Added comment regarding some warming/error messages are
    with/without preceding letters/numbers.
    2022/01/27 Aded extra space between keyword and rest of text matching 5.2.035.


    --- MBSE BBS v1.0.7.24 (GNU/Linux-x86_64)
    * Origin: The Elist Maintainer (2:250/1)
  • From Vincent Coen@2:250/1 to All on Tue Mar 1 00:00:02 2022

    Quick Help for Moderators

    EList v5.3 - The Elist program
    Copyright (c) 2019 - 2022 by Vincent Coen.


    Note: The information in this guide was taken from A Moderator's
    Guide to ECHOBASE (c) Dana Bell, with changes by Ben Ritchey and
    then customized by Vincent Coen.

    This file may be designated as the file to be sent in response to
    fatal errors and requests for HELP.

    EList v5 is a database program that maintains a database of
    echomail conference information. This particular program was
    written to meet the need to maintain and distribute echomail
    conference lists within Fidonet and with other networks.

    The Fidonet Echolist published by this program include ELIST.NA
    a short, areafix uplink file format distributed monthly,
    ELIST.RPT, a longer descriptive file distributed on a monthly
    basis and ELIST.NO a short list of newly deleted echo's on a
    monthly basis.

    The last file ELIST.NO is now produced, as Ben did not
    produce it, may be it has out lived it's usefulness how ever.
    it will be a rolling list in that it will only contain deleted
    Echos with any renewed one's at any later date being removed.

    From v5.3 this listing will be discontinued as instaad of deleting echos
    they will remain on the system but transferred to the BACKBONE system.
    This makes the .NO file redundant.

    Moderators may add or update entries to the list by writing to
    ELIST or via Netmail, when these options are available as
    announced in ELIST.

    Currently such Additions, Updates or Deletions to the Echomail
    database must be sent as files as ECHOtag.RUL for any rules
    file and as ECHOtag.ECO as MOD-ADD, MOD-UPD or as MOD-DEL
    requests and these subjects must also be placed after the keyword
    SUBJect.

    Once Elist can process Netmail msgs they will be converted to a
    individual ECHOtag.ECO file and processed the same way without
    any more changes to the program. It is hoped that the same will
    apply to Emails
    The program will read these files and update the EList database,
    then post a reply to the ELIST conference and via Netmail.
    (Note: the Reply-to keyword overrides the FROM address if present)
    otherwise the FROM is always used. I must admit the REPLY-TO keyword
    is a bit redundant with the usage of FROM so might kill that off at some
    point.

    Address netmail messages

    To: ECHOLIST, (2:25/21)
    Subj: MOD-ADD or MOD-UPD or MOD-DEL

    It is hoped that Updates via Email will be also available some
    time in the future via elistmaint@gmail.com and this
    facility will be announced in the ELIST echo area once available
    along with any update to the email address used as well as usage
    of netmail to directly deliver such messages instead of using
    files. This email address is not being monitored at this time.

    NOTE that only dropping off the files tag.ECO and tag.RUL to
    2:25/21 or 2:250/1 is supported for the moment.

    For the moment delivery of MOD-ADD, MOD-UPD and MOD-DEL messages
    MUST come as files only, along with any rules file with the
    following file names :
    For MOD-ADD, UPD and DEL as echotag.ECO
    For rules files as echotag.RUL
    Where echotag is the Echo area tag that is up to 36 characters
    in length. Note that for MOD requests you can also add the subject
    to the end of the extension i.e.,
    MBSE.ECOMOD-ADD or MBSE.ECOMOD-UPD
    [ Note that there is NO space between MOO and UPD or ADD only a
    hyphen. ]

    Use the following keywords to set the fields of your echo list
    submission and note that only the upper case characters are significant
    e.g., only SUBJ is needed for SUBJect.
    All keywords shown starting with * are mandatory - they MUST be provided.

    For keywords FROM, MOD, COMODn and REPLY the following is the format for
    your contact address where text with {} are optional extras and as needed:

    Contact Address:
    A1 A2 A3 Sub field class name as used below.
    <name>, <node>[, <email>] Note the separating commas.
    A1 name = first last names i.e., Fred Bloggs - Compulsory
    [ note the space between name elements ]
    A2 node = zone:net/node {@domain} i.e.,
    2:345/678 - Compulsory.
    A3 email = name@emailaddress i.e., fbloggs@gmail.com You can use '{at}'
    or '=at=' in place of the at sign [@] and this will
    be the one used in ELIST reporting once email support is
    operational.
    You may omit the elements between [] but name is needed to respond to
    an update in the ELIST echo so that a problem or not, can be addressed
    to the specific poster along with the netmail address for sending a
    direct message as well. If omitted a posting could be addressed to
    SYSOP, UNKnown, 'No Idea' and other variations depending on where in the
    elist program the posting report is issued (helps in debugging).
    None of which, aids the moderator doing a search on their name to check
    the latest postings.

    KEYWORDS in use (where characters in UPPER CASE are relevant) in form of :

    KEYWord {one or more spaces} Sub keyword or other text

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

    *SUBJect MOD-UPD or MOD-ADD or MOD-DEL

    *FROM 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)
    {} Shows a optional extension and therefore can be omitted.
    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 must include
    your name.

    *TAGname <areatag> x36.

    +*TITLe <Brief area description> x72.

    +*DESCription <Description of the echo> 15 lines where the text is a maximum
    of 75 characters (not including the keyword 'DESC').
    Do not provide any usage rules see RULETEXT.

    As of elist v5.3 a description file can be submitted in the
    same manner as a .RUL file in that a file containing the
    contents of the DESC keywork but without the keyword can be
    supplied where the file name is in the format of :
    AAA.BBB.DES Where AAA = from GROUP keyword,
    BBB = EchoTag name
    Followed by '.DES' { but without the '. }
    This file only needs to be submitted for a MOD-UPD if there
    is any changes from the one cuurently in use.

    RULEs <A one line description of the rules> x36 < NOTE SIZE CHANGE
    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.
    Can be omitted, also see RULETEXT.
    If both RULES and RULETEXT 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.

    +*MODerator Contact Address.
    This keyword MUST be submitted before any COMODn keywords.

    COMODn Where n = 1, 2, 3 or 4. This keyword allows
    the moderator to control precisely where each
    Co-Moderator sits in the list of four.
    Next word can be DELETE which will clear all contact
    information for that Co-Moderator.

    *PASSword <current password>, <new password> x36, x36.
    [Note the required space after the comma (',')
    if new password is used.]

    VOLume <number of messages> nnnnn per month.
    Use a realistic number. Anything after the number is
    ignored as per month is automatically assumed.

    RESTrictions </SYSop, /MODerator, /REAl> (only first four letters
    are needed) and / or 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.

    ORIGin <origination net address of the distribution> x36.
    More used in the days where almost all posts originated
    from one netmail address.

    DISTribution <distribution> Any text describing x72.

    GATEway <gateways> Any text describing x72.

    *GROUP <Abbrev. of Network; i.e. FIDO) x16.
    Default is FIDO but this keyword must be provided.

    +*LANG Language used in this echo x16 (default = ENGLISH).

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

    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 consisting of spaces will be included.

    Note you can submit a .RUL file at any time whenever there
    is a change of text.

    HELP <respond with help message>
    The latest version of this file !

    Keywords removed with v5.3 -- If present it is ignored.

    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.


    * Means these are compulsory - they must always be supplied.

    + Compulsory as for * but, NOT when modifying an echo (MOD-UPD), i.e., not
    required.
    xnn is the maximum size in characters of the field after the keyword.


    New Changes to modes of operation:
    =================================

    # In the first character position of a line that is NOT
    in a RULETEXT block.
    The line will be ignored

    Spaces When not in a RULETEXT block will also be ignored and
    is in the first position.

    A minimum example ADD file might have this :

    SUBJ MOD-ADD
    TAG ECHOES
    GROUP FIDO
    FROM Joe Sysop, 1:234/56
    PASS password
    LANG ENGLISH
    TITL FIDONet echoes discussion
    MOD Joe Sysop, 1:234/56
    DESC Discussions about echoes
    DESC and moderators.
    ---

    Which will create a new echo entry for ECHOES for the FIDO network
    using the English language created and moderated by Joe Sysop.


    A minimum example UPD file with no changes is :

    SUBJ MOD-UPD
    TAG echo-name
    GROUP FIDO
    FROM Joe Sysop, 1:234/45
    PASS password
    ---

    Likewise for a DEL file just replace SUBJ with MOD-DEL for the above
    example. This is actioned during the next expiry warning
    run

    The keywords are truncated prior to checking, so matching will
    only be done for the capitalised portion of the keyword.
    Keywords may be capitalized or lower case. The following three
    entries will have the same effect.

    TAG BOARD_GAMES
    Tagname BOARD_GAMES
    tag BOARD_GAMES

    However the capitalised text in the keyword descriptions above show
    the elements of a keyword that MUST be supplied regardless of the
    case supplied in the submission.

    Optionally end the message with --- or -+- (three-dashes or
    dash, Plus symbol, dash) indicating the end of the message file.
    This should be supplied if using keyword RULETEXT otherwise is not
    needed.

    With the exception of the DESCription field, only one entry is
    allowed per field. If multiple entries are included in the text,
    processing will continue but only the last one will be saved.
    If you don't have an entry for a field, there is no need to
    include the keyword (specifying JUST the keyword will
    erase/blank any existing value(s) for keywords
    REPLY, REST. DIST, ORIG, GATE.
    COMODn must use DELETE to remove any existing details for that co-mod.

    Only the GROUP. ECHOtag, SUBJect, FROM and PASSword are necessary
    for updating.

    Update submissions to the Echolist that don't require any changes
    may be done by including the above mentioned keywords.
    Full details already in the database will remain the same.
    New echos, will again require the above mentioned keywords
    at a minimum.

    In order to delete an area from the list, you must use the
    subject MOD-DEL.

    When submitting an entry with the DESC field, be sure to begin
    each line with DESC and end it as with any other keywords
    with a hard carriage return.

    Note that there can only be one line with a RULES keyword.
    For multi line rules use the keyword RULETEXT see below.
    (Some editors may word wrap all messages and strip carriage
    returns when saving. Some of these editors, however, may allow
    you to force carriage returns by indenting.) Avoid any that use
    the TAB as it is not honoured and any will be replaced by space.

    Using RULEs DELETE will clear content of rules AND delete any
    existing .RUL file.

    NOTE: blank lines after DESC keyword will RESET everything to
    null, as with all text based keywords.
    For RULETEXT, every line is included as is.

    You can insert the content of your Mod Rul text file (just the
    body of text) on the next and following lines right AFTER the
    RULETEXT keyword at the END of a MOD UPD submission (naturally
    for the same Tag name). The content of RULETEXT will create a
    .RUL with the same Echo tag name (as upper case) followed by the
    extension .RUL, again in upper case.


    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 .
    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 or ECHOLIST echos and will if needed update this file.


    + -------------------------------- +
    For latest changes also see the document README-Elist where more
    information may be present to extend these details.


    Address any questions to the ELIST controller Vincent Coen at
    2:250/1, by choice at the Echolist echo itself, [ELIST] or via
    Email to vbcoen@gmail.com for a faster response.



    -=:{ End of EListHlp.Txt }:=-


    This document last updated :
    2020/03/24 Vincent Coen, 2:250/1 or vbcoen@gmail.com
    Updated content for readability, helpfully.
    2020/04/12 Tidy up explanations on keywords.
    2020/04/19 Spelling errors mostly on the original.
    2020/05/08 Updated version of Elist to current.
    2021/06/16 Added missing keyword CHARSet and removed changed keywords
    as in main text body.
    2021/09/10 Changed compulsory keywords with modifier + for keywrds not
    needed with MOD-UPD.
    Included list of warning and error messages.
    2021/11/01 Added comment regarding some warming/error messages are
    with/without preceding letters/numbers.
    2022/01/27 Aded extra space between keyword and rest of text matching 5.2.035.
    2022/02/16 v5.3 - Removed keyword REPLY-TO and reduced size of RULEs text to 36
    and included note about a .DES {description text file}.


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