MSGID: 2:250/1@fidonet 47642a8d
PID: MBSE-FIDO 1.0.8 (Linux-x86_64)
CHRS: UTF-8 4
TZUTC: 0100
TID: MBSE-FIDO 1.0.8 (Linux-x86_64)
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.
, [, ] 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.
x36.
+*TITLe x72.
+*DESCription 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 keyword 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 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 , 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 (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 x36.
More used in the days where almost all posts originated
from one netmail address.
DISTribution Any text describing x72.
GATEway Any text describing x72.
*GROUP {, 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 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.
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.
There is no nead to also supply a MOD-UPD.
HELP
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)
SEEN-BY: 1/123 15/0 18/200 25/0 999 9999 90/1 105/81 106/201 120/340
SEEN-BY: 123/131 129/305 330 331 153/7715 218/700 221/1 226/30 227/114
SEEN-BY: 229/110 111 206 317 400 424 426 428 470 664 700 250/0 1 3
SEEN-BY: 250/4 5 6 7 8 10 11 12 263/0 266/512 282/1038 292/854 301/1
SEEN-BY: 317/3 320/219 322/757 342/200 396/45 460/58 633/280 712/848
SEEN-BY: 3634/12
PATH: 250/1 292/854 229/426
|
