Subj : Submission Help File To : All From : Vincent Coen Date : Sun Apr 05 2020 15:50:50 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-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. 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. , [, ] 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. 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 you 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. *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. x36. *TITLe x72. *DESCription 15 lines x75. 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. [ Use COMODn instead ] 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. and will be removed within amonth or so. 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 , x36, x36. [Note the required space after the comma (',') if new password is used.] VOLume nnnnn per month. Use a realistic number. Anything after the number is ignored as per month is automatically assumed. RESTrictions x72. ORIGin x36. DISTribution Any text describing x72. GATEway Any text describing x72. *GROUP 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 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. HELP 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. This keyword was used for testing but has been left in use if needed. 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. 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. This keyword will be removed at some point as COMODn full replaces it but giving more control over co-mod placement within the block of four. 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 address see above for the exact format Can be any registered CoMod. A minimum sample ADD file might have this : SUBJ 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 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 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/03/24 Vincent Coen, 2:250/1 or vbcoen@gmail.com Updated content for readability, helpfully. --- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64) * Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1) .