ELIST Maintenance Program
~~~~~~~~~~~~~~~~~~~~~~~~~
This document is to show the basic format what is needed to submit a MOD-ADD
or
MOD-UPD or a rules file submission to the elist maintainer at
2:250/1 or 2:25/21 using a file only, at least for the moment.
All keyword are formed as as two primary elements where the first is the
keyword
itself followed by space then the next element that will depend on the keyword
itself.
There are a few keywords that MUST always be used and are therefore mandatory
for all submissions.
These are listed below along with all others and marked by an * at the
beginning
of the keyword name. The keywords consist of two segments, the characters that
are tested for, in upper case (capitalised) and the remainder in lower case
that makes them more readable.
You must always supply the characters in capitals, the rest are ignored.
References to Xnn means the maximum size in characters of the field after the
keyword, i.e.,
X75 means you can use up to 75 characters a to z, A to Z and 0 to 9 with
full stop, comma and hyphen ( - ) etc.
Using larger will, at best mean that any characters outside the limit will
be ignored and at worst will result in a error report and the submission
being rejected.
The entire content of the submission is examined and all errors and
warnings
noted where at the end, any such problems are reported in the ELIST echo.
List of keywords that can be used in any submission, the first block are the
one's that MUST be always supplied in the suggested order.
Keyword Sub keywords or other text
------- --------------------------
Always required:
*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.
*GROUP 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.
The following are accepted :
/REAl [ Real Names only ]
/SYS [ SYSops only ]
/MOD [ Moderators (and Co-Mods) only) ]
NONE or Blank - No restrictions - Use NONE to remove any
others present and make it NONE.
The restrictions can be cumulative, i.e., you could have
/REL /SYS /MOD which implies:
Only for moderators who have a registered nodelist entry and
they must use their real names.
Do not use the other additional descriptions in the [ ] as
these get created for the ELIST.RPT and the posted report
into
the ELIST echo after each echo update.
ORIGin X36.
More used in the days where almost all posts originated
from one Netmail address, otherwise a bit redundant.
DISTribution Any text describing X72.
GATEway Any text describing X72.
CHARSet {, Language Character set } X16
One or more character sets used for a specific language other
than English. If more than one specified seperated by a
comma.
This is to offer extra support when the language used needs
special char sets to spport 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
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 even if consisting of spaces will be
included.
HELP
The latest version of the longer help 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 in case it is needed.
--- Or "-+-" terminates a RULETEXT keyword block.
Also useful as you can place other text after, such as
unused keywords, as they will be totally ignored.
# Comment text, Ignore rest of the line.
a Line starting with spaces will also be ignored.
Contact Address
===============
This information is the next word group after the following keywords:
FROM, MOD, COMODn, REPLY.
Formed of three elements where the first two are required, separated
by
commas in the form:
< Element three
FirstName LastName, Zmmmm:Nmmmm.Kmmmm {.Pmmmm}{@demain}{,
email@address}
Z = zone, N = Net, K = Node with {optional P = Point or/and Domain}.
mmmm = A number between 0 and 4095.
The first two are required for responses posted to ELIST and if errors
or expiry warnings also issued direct to the network address of
MOD and to all Comod's if the warning # is above 1.
Point and domain are totally optional and are not required.
Note the leading commas are required for elements 2 and 3.
{} Signify optional.
You can use the characters {at} or =at= in place of the @ in
the
email address. They will be replaced by the @ symbol.
Support for Email is not yet available.
Support for receiving submissions via Netmail other than as files
is not yet available but you CAN use Netmail file attachments.
Redundant keywords
------------------
COMODerator Contact Address. [ Use COMODn instead ]
This keyword must always appear at any point AFTER a
MOD keyword.
See notes on New Keywords below and above.
This keyword has been replaced by COMODn
For HELP (to be sent via Netmail, no other keywords are needed other than
FROM
but the file must have the .ECO extension but the name could be anything.
You will be sent the current version of file elisthlp.txt which may well go
into more detail than this document but there again it might not:)
Notes on RULES Processing:
-------------------------
Rules can be provided in one of two ways,
1. Recommended by sending a rules file with the file name of Echo Tag as
upper case plus extension of .RUL, i.e., MBSE.RUL
It can be ANY number of lines but each line must not EXCEED 75
characters
but can include blank lines for readability.
(for those Bulletin Board Systems that have such width restrictions).
2. Sending as part of a MOD-ADD or MOD-UPD file where the rules text lines
follow immediately after the keyword RULETEXT and before the last line
which is the terminator '---' or '-+-', or the end of the file.
Again blank lines can be embedded within the text for readability.
Note the same text block can be transferred to a ECHOtag.RUL file as is
but WITHOUT the terminator line '---' or '-+-'.
In any event, all RULETEXT content IS transferred to a ECHOtag.RUL file
overwriting any existing file. These rule files are stored in the rules
directory found inside the weekly / month edition of ERyymmww.zip or
ERULyymm.ZIP that are in turn in the archive ELyymmww.zip or
ELSTyymm.ZIP.
These along with the files ELST.RPT, ELIST.NA and if exists ELIST.NO
are also included within the top level archive as well as the help
files.
Further Notes on Submissions
----------------------------
If your submission has unknown keywords or contains bad data in place of such,
the warning message 'EL219 Error Unknown keyword found' followed by the word
found. If the word printed is of a valid word then there are bad characters
before, caused by not using a text editor. You must never use any other type
of editor and only use a TEXT editor as found on Windows, Linux and other *nix
systems.
For a full list of such messages that can appear as a response of a submission
please see the end of this document.
All MOD-ADD, MOD-UPD and MOD-DEL files use the extensions '.ECO'.
You MUST include the keyword SUBJ in each of the above i.e., MOD-ADD, MOD-UPD
or
MOD-DEL.
These files must be sent as echo tag name as the filename, for example the
echo
MBSE the file would be : MBSE.ECO and if needed MBSE.RUL for the rules.
Note that any moderator and this includes a co-moderator can submit a MOD-UPD
or
MOD-DEL providing they are on record as one, in the echo being changed. This
is
so that if the moderator has a major system problem or leaves the network for
any reason, another can take over and send a MOD-UPD submission even as a
one off. This method can also be used for a Co-Mod can take over an echo in
the
event of the Moderator being permanently unavailable. OF source this assumes
that all Co Mods have a copy of the current MOD-ADD and/or MOD-UPD and any
RULe
files. It is recommended that for this reason alone, that all echo's have at
least one Co Mod.
A moderator taking over from a previous one should get the existing moderator
to send in a MOD-UPD with their contact address as a CoMODn (1 through 4) and
if
all are in use just over write one of these entries.
After that is sent in and acknowledged, the new moderator can send in a update
MOD-UPD containing their contact address details via keywords MOD and with a
keyword COMOD1 DELETE to remove the previously created entry.
If needed use PASS oldpassword, newpassword to change the existing password or
use :
PASS oldpassword
NEWPASS anewpassword
The password, as a one word string with the letters 0 - 9, a - z, A - Z
and any standard symbol character as found on a standard keyboard using one
key
stroke (shift allowed), i.e., no key sequences using the ALT or CTL keys as
they
can interfere with file processing.
Do NOT use a space character as that will mark the end of the password.
Examples are ¬`!"£$%^&*()_+-=}{[]~@:;'#?><,.
The password is case sensitive so ABCD is not the same as abcd which is not
the
same as AbCd.
Maximum size is 36 characters.
Note that the slash keys \ and / MUST not be used in case of file processing
using a database such as Mysqld or Mariadb etc and no, they do not like them
for some reason.
A Reminder, a change of password can also be done using the PASS keyword i.e.,
PASS old-password, new-password Note the space after the comma ','.
Examples for change of moderator - the current moderator sends:
SUBJ MOD-UPD
FROM 1:345/6
TAG echoname
PASS current-password {can also be current-password, new-password}
GROUP FIDO
COMOD1 new moderator Contact address, etc :
COMOD1 Fred Blogs, 2:234/5, fboggs@gmailcom
Note the comma separators between each segment.
Then the new moderator sends after the previous MOD-UPD has been acknowledged
in the echo ELIST:
SUBJ MOD-UPD
FROM 1:234/5
TAG echoname
PASS old-password, new-password
GROUP FIDO
MOD Fred_Blogs, 1:234/5 [ Changing the moderator name and address ]
COMOD1 DELETE [ To remove all comod details as should not have a
duplicate address if not done by previous
moderator. ]
For subsequent updates then, change PASS to reflect the new password after
receiving an acknowledgment message via ELIST or Netmail.
Remove the NEWPASS and COMOD entries, adding any other keywords that require
changes if any.
Expiry Warnings
---------------
Up to four are issued with the first one sent to the moderator on record and
in
ELIST after six months have lapsed since the last update.
This is the reason why the WARN process is not run until all MOD-UPD processes
have finished after 23:30 on the 1st of the month.
Warnings 2, 3 & 4 (the final followed by a Delete warning) is sent to the
moderator and all Co-Moderators on record at their registered Netmail address
as well as in ELIST.
If an update has not arrived at the elist maintainer before the end of month 5
then the echo WILL be deleted with the tag and title transferred to the
ELIST.NO
file. This file contains the Echotag date deleted and the Title one line per
echo
Reminder:
Any registered moderator including Co-moderators for a given echo can send in
MOD-UPD .ECO file and/or a Rules file using the correct password.
Note that the content of a MOD-UPD only requires at a minimum the following
keywords :
FROM
SUBJ
TAG
PASS
GROUP FIDO
Providing the contact address in the FROM keyword is one of the registered
moderators then the Update will be considered valid proving there is no errors
within any keyword or secondary parameters.
Note that each MOD-ADD, UPD or DEL is validated for correctness and if any
errors are found, the request is rejected with message/s regarding the
problem/s
found and sent to the sender's Netmail address (as on the FROM keyword) and
the
ELIST echo.
Example for a new echo :
SUBJ MOD-ADD
TAG MBSE
FROM Vince Coen, 2:250/1, vbcoen@gmail.com
MOD Vince Coen, 2:250/1, vbcoen@gmail.com
COMOD1 Fred Bloggs, 1:234/5
GROUP FIDO
LANG ENGLISH
TITL The Linux/FreeBSD/OSX MBSE BBS Support Echo
DESC The main aim of this echo is to help provide support and to pass on
DESC problems regarding the Mbse BBS system software that runs under
DESC Linux/FreeBSD/OSX operating systems between users and the programmers.
DIST All Official Fidonet Backbones
GATE NONE.
VOLume 10
ORIG 2:250/1
PASS YourPaSsWord
REST /Real
If just updating in full, replace the above MOD-ADD with MOD-UPD
If just updating to reset the warnings etc then this will do:
SUBJ MOD-UPD
TAG MBSE
FROM Vince Coen, 2:250/1
GROUP FIDO
PASS YourPaSsWord
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.
==> 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 echo I will if needed update this file.
Updated 2020/05/1 Vincent Coen - Support for new keyword CHARSet, typos &
grammar.
Make sure no line exceeds CC 80.
--- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
* Origin: The Elist Maintainer (2:250/1)
|