MSGID: 2:25/21@fidonet 6251ead6
PID: MBSE-FIDO 1.0.8 (Linux-armv7l)
CHRS: UTF-8 4
TZUTC: 0000
TID: MBSE-FIDO 1.0.8 (Linux-armv7l)
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:25/21 using a file, Only, at least for the moment.
All keyword are formed 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 and sent direct using the supplied netmail address in the FROM
keyword. As and when email support is added, a error message will also be
sent to the supplied email address using the FROM keyword.
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.
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
------- --------------------------
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 X36. Warning some older BBS systems may not
support
areatag names longer than 8 - 16 characters.
*FROM See lower for the format of this.
Details of the sender of message where any replies regarding
errors or confirmation of status of submission is made to.
X72.
*DESCription A maximum of 15 lines where the
text
is a maximum of 75 characters long (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 the GROUP keyword,
BBB = EchoTag name
Followed by '.DES' { but without the
quote'}
This file only needs to be submitted for a MOD-UPD if there
is any changes from the one currently in use or for an echo
in the BACKBONE lists (BACKBONE.NA or .RPT).
*MODerator Contact Address. See lower for the format of this.
This keyword MUST be submitted before any COMODn keywords.
For COMODn see more information below.
*LANG Language used in this echo X16 (Default is ENGLISH).
Should always be provided. Not every one reads English :)
This must be the primary language name only as other software
may search for it. This is ONE Word so it can be used with
other software.
*PASSword , X36, X36.
[Note the required space after the comma (',') if new
password is used.]
Any standard characters can be used and is case sensitive
ABCD is NOT the same as aBcD.
The following keywords can be used as required for the specific echo.
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.
The same as if the keyword is not supplied.
Can be omitted, but also see RULETEXT.
If both RULES and RULETEXT are 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.
For a multi line set of rules see keyword RULETEXT.
COMODn Where n = 1, 2, 3 or 4.
Next word/s
See below for more details of the format for this.
This keyword REPLACES the old keyword COMOD and should be
placed anywhere after the MOD keyword.
It's usage allows the moderator to control precisely where
each Co-Moderator sits in the list of four Co-Mods.
Next word can also be DELETE which will clear all contact
information for that Co-Moderator position.
[ The COMOD keyword has been removed.]
VOLume nnnn per month. X4
Use a realistic number. Anything after the number is
ignored as per month is automatically assumed.
This is only used to show a number in the ELIST.RPT
otherwise serves no real use.
RESTrictions (only first four letters
are needed) and/or other 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.
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 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., 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.
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.
Note you can submit a .RUL file at any time whenever there
is a change of text.
There is no need to also supply a MOD-UPD.
HELP
The latest version of the longer help file !
--- 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 a space will also be ignored.
Contact Address
===============
This information is the next word group after the following keywords:
FROM, MOD, COMODn.
Formed of three elements where the first two are required, and all
separated by commas in the form:
< - Element one - > < - - - - - Element two - - - - > < 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 the
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.
If the leading comma is not present the next set of address data will
be ignored and will not produce an error report.
{} Signify an optional parameter.
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 and
if
used there is no need to place anything in the body of the message
as it is totally ignored.
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:) and this
document should be considered as primary help.
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.
(the 75 character limit is 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 on demand / 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 are also included within
the
top level archive as well as the help file/s.
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. Note the use of a hyphen.
These files must be sent as the 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 course this assumes that
all Co Mods have a copy of the current MOD-ADD and/or MOD-UPD and any RULe
files including the current password using the keyword PASS.
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 replace or 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.
This, can be done by sending in two submission files where the file name has a
1, 2 etc added to that of the Echo name i.e., MBSE1.ECO MBSE2.ECO as they are
processed in alphabetically sorted order.
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 and could differ from different
keyboards on different platforms, e.g., Windows and Apple's OSX.
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.
Examples for change of moderator - the current moderator (or the new mod on
his
behalf) sends:
Submission filename ECHONAME1.ECO
SUBJ MOD-UPD
FROM 1:345/6 <<<<= note this is the current Moderator
TAG ECHONAME
PASS current-password {can also be current-password, new-password}
GROUP FIDO
COMOD1 new moderator Contact address, etc for example :
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:
Submission filename ECHONAME2.ECO
SUBJ MOD-UPD
FROM 2:234/5 <<<<<= This is the new Moderator
TAG ECHONAME
PASS current-password, new-password
GROUP FIDO
MOD Fred_Blogs, 2:234/5 <<< [ Changing the moderator name and address ]
For subsequent updates then, change PASS to reflect the new password after
receiving an acknowledgment message via ELIST or Netmail.
Remove the COMOD1 entries, adding any other keywords that require changes
if any.
Expiry Warnings
---------------
One is issued with the first one sent to the moderator on record and
in ELIST after 10 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 (GMT) on the 1st of the month.
Next is the 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 2
then the echo WILL be transferred to the BACKBONE system only with elistmaint
the new moderator. This is the only way the system can deal with it as a
moderator must always exist. The elistmaint will NOT do any moderating.
Reminder:
Any registered moderator including Co-moderators for a given echo can send in
MOD-UPD .ECO file and/or a Rules file if a change is needed or the rules need
removing by using the correct password.
Note that the content of a MOD-UPD when updating for the 10 month sequence
only requires at a minimum the following keywords :
FROM
SUBJ MOD-UPD
TAG ECHONAME
PASS Current Password
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 the details MUST be exactly
the same in both keywords MOD and FROM.
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 Vincent Coen, 2:250/1
MOD Vincent Coen, 2:250/1
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 Linux,
DESC 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 Vincent 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.
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 .
migrated to backbone
EL224 Error missing SUBJect.
EL225 Invalid (Co)MODerator given in FROM,
Echolist Update.
EL228 Error INVALID contact Address in:
EL229 Warning Invalid address changed to MODs Name
EL230 Errors found in MOD submission, see messages:
EL231 Ruletext rejected due to other reported errors
EL232 Unknown Echo Group
EL233 Error GROUP not specified.
EL234 Error Invalid SUBJect
EL235 Contact name Invalid
These are warnings only but the process has still completed.
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.
Update History:
2020/05/01 vbc - Support for new keyword CHARSet, typos & grammar.
Make sure no line exceeds CC 80.
Validate LANG to be primary language name only.
2020/05/24 vbc - COMOD discontinued
as COMODn (1 - 4) replaces it.
Removed keyword NEWPASS as pointless.
Spelling check run for typo's etc.
Cleaned up grammar and some explanations.
2021/09/10 vbc - Removed some text for keyword COMOD as now discontinued.
2021/11/01 vbc - Changed email address but not yet in use.
Added comment regarding some warming/error messages are
with/without preceding letters/numbers.
2022/01/27 vbc - Added extra space between keyword and rest of text matching
5.2.035.
2022/02/16 vbc - v5.3 - Removed keyword REPLY-TO and reduced size of RULEs
text to 36 and included note about a .DES {description text
file}.
2022/05/05 vbc - Removed a reference for 250/1 as service is 25/21.
2022/06/01 vbc - Removed references to REPLY-to keyword - its gone.
Clean up other areas that are out of date such as the life
of a update to 10 months with 1 warning and 1 Delete
warning.
Removed references to file .NO as all expiring echo's are
transferred to the BACKBONE lists.
2022/10/03 vbc - Texual and grammar clean up.
--- MBSE BBS v1.0.8 (Linux-armv7l)
* Origin: Elist Maintainer at 2:25/21 (2:25/21)
SEEN-BY: 1/123 15/0 18/200 25/0 21 90/1 105/81 106/201 120/340 123/131
SEEN-BY: 129/305 153/7715 218/700 221/1 226/30 227/114 229/110 111
SEEN-BY: 229/112 113 114 206 317 400 424 426 428 470 664 700 250/0
SEEN-BY: 250/1 3 4 5 6 8 11 12 263/0 266/512 275/1000 282/1038 292/854
SEEN-BY: 317/3 320/219 322/757 342/200 396/45 460/58 467/4 633/280
SEEN-BY: 712/848 1321 3634/12
PATH: 25/21 250/1 292/854 229/426
|
