• elisthlp text file content

    From Vince Coen@2:2/21 to All on Sun Jan 26 22:12:10 2020
    Quick Help for Moderators

    EList v5.0
    The Elist program
    Copyright (c) 2018 by Ben Ritchey and from 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 but works 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.
    At the moment this last file ELIST.NO is NOT produced but can be
    subject to requests from Sysops and/or moderators as Ben did not
    produce it, may be it has out lived it's usefulness.

    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 to the Echomail database or Updates and
    Deletions should be sent as files as ECHOtag.RUL for any rules
    file and as ECHOtag.ECO as MOD-ADD or 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 progam.
    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 Email if present).

    Address netmail messages

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

    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 annouced 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 whith 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 echolist submission.

    *SUBJect MOD-UPD or MOD-ADD or MOD-DEL
    A space can be between MOD and next word instead of
    the '-'.
    *FROM <Node as a Netmail address format: zone:net/node@domain
    Moderator node address (can be a registered echo Co-Moderator)
    *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 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.
    NOTE that the above symbol '|' means a choicei.e., or.
    *MODerator <moderator name>, <mod node>, <mod email>
    This keyword MUST be submitted before any COMOD keywords.
    COMODerator <co-moderator name>, <co-mod node>, <co-mod email>
    This keyword must always appear AFTER a MOD keyword.
    REPLY-to <reply-to name>, <reply-to node>, <reply-to email>
    Usually same as one in keywords MOD or FROM
    *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.
    RESTrictions </SYSop, /MODerator, /REAl (only first four letters
    are needed) or text> x72.
    ORIGin <origination net address of the distribution> x36.
    DISTribution <distribution> x72.
    GATEway <gateways> Any text so describing x72.
    *GROUP <Abbrev. of Network; i.e. FIDO) x16.
    LANG Language used in this echo default = ENGLISH x16.
    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 otherwise will not be listed. 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>
    NEWPASSword Updated password must be used with PASS and does
    the same job as the second parameter to PASS keyword.
    --- or "-+-" terminates MOD message

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

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

    COMOD DELETE Will delete ALL CoModerators and can be followed
    with one or more COMOD or CO~MODn (see below)
    that gives new details.
    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 COMODn).

    You can issue up to four of these giving five
    moderators in all.

    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 can
    replace the keyword COMOD. It's usage allows
    the moderator to control precisely where each
    Co-Moderator sets in the list of four.
    It is recommended there fore to use this
    option over using just the COMOD keyword as
    this option will be removed at some point.

    FROM 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@domain (fidonet).

    A minimum sample ADD file might have this :

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

    A minimum sample UPD file with no changes is :

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

    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, Plussymbol, 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 should use
    the subject MOD-DEL.

    When submitting an entry with DESC or RULES fields, be sure to begin
    each line with DESC or RULES and end it 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 centent 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.

    -=:{ 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.


    --- Mageia Linux v7.1 X64/Mbse v1.0.7.13/GoldED+/LNX 1.1.5-b20180707
    * Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:2/21)
  • From August Abolins@2:221/1.58 to Vince Coen on Sun Jan 26 20:21:00 2020
    Hello Vince!

    ** 26.01.20 - 22:12, Vince Coen wrote to All:

    Address netmail messages

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


    2:25/21 is not nodelisted. Do we use that anyway?


    ../|ug

    --- OpenXP 5.0.42
    * Origin: /|ug's Point, Ont. CANADA (2:221/1.58)
  • From Vince Coen@2:2/21 to August Abolins on Mon Jan 27 17:07:46 2020
    Hello August!

    Sunday January 26 2020 20:16, you wrote to me:

    Hello Vince!

    ** 26.01.20 - 22:12, Vince Coen wrote to All:

    Address netmail messages

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


    2:25/21 is not nodelisted. Do we use that anyway?


    Will be for next Firdays nodelist but please use my normal one of 2:250/1


    Thanks.



    Vince

    --- Mageia Linux v7.1 X64/Mbse v1.0.7.13/GoldED+/LNX 1.1.5-b20180707
    * Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:2/21)