
                 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
     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 how ever.
     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.
     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 ).

  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.

