ELIST Maintenance Programs
~~~~~~~~~~~~~~~~~~~~~~~~~~

These notes are mostly for a new elistmaint administrator of the Elist system and likewise the full Elist manual that provides information for the installation and set up of the full Elist system including supporting software such as the MBSE BBS system along with the compiler for building the elist programs.

These notes as a help file are also for moderators and Co-Moderators for the submission of MOD-ADD, MOD-UPD and MOD-DEL files sent direct to the elistmaintainers at 2:25/21.

All requests via MOD-ADD, MD-UPD and MOD-DEL must have keyword PASS present followed by the password on file. This is checked for on all, and for MOD-ADD the echo data record must not exist yet. At the current moment only files are accepted by being dropped off at the Elist maintainer system i.e., ECHOtag.RUL and ECHOtag.ECO the subject for the ECO file must be present (See new keywords below). ECHOtag should match up to the content of TAG keyword.

For the echo description you can also provide the optional file ECHOgroup.Echotag.DES

Note the periods / full stops. The content of this file is plain text with up to 75 characters per line and up to 15 lines and this is so that many BBS systems can operate that may still have this limitation if they use descriptions
at all, as for example MBSE does not although it does support the RULes files.

The .DES file replaces the need to use keyword DESC so that, can be removed from
a submission file. This file can be used in any BBS system being under current development but any active programmer should advise of this to myself as the Elist programmer and I will ensure that the .DES files are also provided in the
monthly archives other wise they will remain for internal Elist processing.

Once processing for JAM netmail areas are set up (as used with mbse), then this
is the file that is created for each message so that the same processing can be
used.
The same will apply to the use of email for sending and receiving elist updates
or warnings.

At this time, NO suitable software for this purpose has been found.

The important issue, is to find suitable C type libraries that can be utilised for the purpose and so far none has been found.

As and when this is implemented each Email will also have a ECHOtag.ECO file created, again to use the same processes used for file submissions.

Failure to proved one of the mandatory keyword will result in the submission being reject with the appropriate Error messages being issued.
The same applies to any other errors found but for any Warning messages the processing will continue, providing no Error messages was generated.

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.

New sub keywords:
----------------

On keyword
RESTrictions the following are accepted :
/REAl Real Names only
/SYS SYSops only

New:
/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 as these get created for the ELIST.RPT and the posted report into the ELIST echo after each echo update. Note a space between these restrictions.

Keyword Changes:
~~~~~~~~~~~~~~~

NEW Keyword that replaced COMOD
This keyword gives more control for the moderator to amend or delete
a specific CoModerator entry reducing the risk of mistakes.

COMODn Where n = 1, 2, 3 or 4. followed by :
DELETE or NONE will delete specific CoMod entry
or
A valid contact address which will update a specific CoMod entry.

Hopefully this is a better way of controlling Co-Moderator entries.
Note that a submission file can be sent (with adjusted FROM keyword)
from any recorded moderator or co-moderator. This is to safeguard the
echo in the event a moderator is ill or left Fido.

For this reason it is recommended that all Moderators have at least one
co-mod set up for ALL echos that they look after and have a current
copy of the echotag.ECO files for Updating and if available the
original for adding the echo say with the file name of echotag.ECO-ADD
where the update file is echotag.ECO-MOD

The extra extension after the word .ECO is ignored by the system but
is useful to keep what file does what for a co-mod or mod.

Contact Address
===============
Formed of three elements separated by commas in the form:
- Element one - - - - - - Element two - - - - - - Element three
FirstName LastName, Zmmm:Nmmmm.Kmmmm {.Pmmmm}{@demain} {, email@address}
Z = zone, N = Net, K = Node with {optional P = Point or/and Domain}.

Note that Domain is no longer used as serves no purpose these days but
is allowed for but, otherwise not processed.

So in practice the format is :
FirstName LastName, Zmmm:Nmmmm.Kmmmm {.Pmmmm} {, email@address}

Example : Vince Coen, 2:250/1

The first two (name and netmail address) are required for responses
posted to ELIST and if errors or expiry warnings direct to the network
address to both the mod and any co-mod on record.

Point and domain are totally optional and are not required.
Note the leading commas for elements 2 and 3.
{} Signify optional.

Support for Email is not yet available so no need for the address.
Support for receiving submissions via netmail not yet available.

RULES Processing:
----------------

Rules can be provided in one of two ways

1. Recommended to send 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 one blank lines between other text lines for readability.
(for those Bulletin Board Systems that have such restrictions).
The restriction of 75 character length is not tested for but you will see
the results of such, by text being chopped off after character 75 in all
reports and netmails.

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 one blank line can be embedded within text lines.

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 'as is', with no checking of content.

Description Processing: [ NEW ] as of v5.3.
----------------------

As the system now fully supports ALL Fido echo's for the BACKBONE using for lists of areas into BACKBONE.NA which can be used for BBS systems that support auto create echo functions, when receiving a new messages for a new Echo area and the BACKBONE.RPT that holds all FIDO areas from the ELIST system as well as
all not on that facility that is considered un-moderated.

This will also happens for any echo areas that expire and is deleted from the ELIST reporting in that each echo will be moved over to the backbone for those reports and files.

The backbone lists will be maintained and owned by elistmaint which currently has the netmail address of 2:25/21. While it will be reported as Moderated by this person, they will in fact not be moderated at all, and will remain only as
backbone echo's.

As the backbone echos in the main, does not have descriptions listed, the format of the database that holds this information within the elist software has
been changed so that details of echo descriptions are no longer held on it but in separate files in the same way that the rules are stored in files named as {echotag}.RUL so is description, but stored in files in the same format (as text
files) but with the filename of {Group}.{echotag}.DES - more later.

This along with the previous removal of rules has reduced the size of each echo
record from 4500+ bytes or characters, depending on the size of the rules to 1024 bytes, a good reduction.

This allows the number of echos that can be stored on a restricted storage system running the elist software, even to run on a SD card say within a Raspberry Pi computer although speed will be some what reduced - to put it mildly.

As a follow on from this :
------------------------

As of version 5.3 (as used from 5th April 2022) you can also submit one additional file that holds the description text in the same format as the one for .RUL and for this optional file (mostly for the use of backbone echo's) is:

This optional file (if submitted), MUST be in the format of AAA.BBB.DES

Where AAA = Group name i.e., FIDO, FSXNET etc
BBB = Echo Tag name i.e., ELIST
followed by the fixed text '.DES' (without the quotes).



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. This extension can also have such text as -ADD or -UPD etc so you could
have ELIST.ECO-ADD or ELIST.ECO-UPD (to add or update the system respectively).

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 and FIDO.MBSE.DES for the description.

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.

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 overwrite one of these entries.

After that is sent in and acknowledged, the new moderator can send in a update MOD-UPD containing their contract address details via keywords MOD and with a keyword COMOD1 DELETE to remove the previously created entry.

Note you can also send in multiple changes to a echo with the submit files say called ELIST1.ECO, ELIST2.ECO.

If needed use PASS oldpassword, newpassword to change the existing password.

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 not be available on some keyboards.
Do NOT use a space character as that will mark the end of the password.

Examples are ¬`!"£$%^&*()_+-=}{[]~@:;'#?><,.

The password is case specific 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.

This 'Assumes' that the new moderator knows the password in use.

Examples for change of moderator - the current 1:345:6 or co-mod sends:
Note that the FROM and MOD must be the same and as in the system record.

as ECHONAME1.ECO
SUBJ MOD-UPD
FROM Bat Man, 1:345/6
TAG ECHONAME
GROUP FIDO
LANG ENGLISH
PASS current-password {can also be current-password, new-password}
COMOD1 new moderator Contact address, etc, Fred Blogs, 1:234/5

Note the comma separators between each segment.

At the same time send :

as ECHONAME2.ECO
SUBJ MOD-UPD
FROM Fred Blogs, 1:234/5
TAG ECHONAME
GROUP FIDO
LANG ENGLISH
MOD Fred_Blogs, 1:234/5 [ Changing the moderator name and address ]
PASS password [ using the currently existing password ]
or
PASS old-password, new-password

As the system processes all files including .ECO files, in alphabetic sorted order both submission files can be sent in, at the same time.

For subsequent updates then, change PASS to reflect the new password if changed.
Remove the COMOD1 entries, adding any other keywords that require changes
if any.

There is one abnormality in functions found, in that in the event of a Moderator
leaving the network (Fido or another) without having a co-moderator then
there is no simple way of changing by a new MOD-UPD file that can be used to change the Mod to another without a security risk unless the Co-Mod has a
copy of the MOD-UPD file that acts as a back up if something occurs with the Mods hardware or leaves the network for what ever reason.

It is recommended that ALL Moderators have a least ONE co-moderator for each echo area, along with a copy of the current MOD-ADD and MOD-UPD file with the current password present.

Therefore the only other way is to send in a msg via ELIST echo to the
Elist maintainer to manually change her/him to another so that all Mods can see
the request and if needed, object to such a request and this will help prevent echo hi-jacking, I hope.

Again:-
This hopefully will be the only reason for using the MAINT function unless I or
someone else can come up with another solution other than all moderators have at least one CoMod who is given a copy of the current MOD-ADD and MOD-UPD files
or records, so in the event of a major problem with the current moderator such as hardware, health or left fido then another can easily take over even if only
for a few months while the problem/s are sorted out.

Again if a co-mod gets these two files, and they are not in the format of : ECHOTAG.ECO-ADD and ECHOTAG.ECO-UPD they should change them so they are, just in case.

Thse files can be submitted to the elist maintainers system at 2:25/21 in this format as the extra characters after '-MOD' or '-UPD' are ignored.

Yes, I have written it twice!


Expiry Warnings
---------------

Updated as of v5.3:

Up to ONE is issued with the first one sent to moderator on record and in
ELIST after TEN months have lapsed since the last update.
This is the reason why the WARN process is not run until all MOD-ADD and MOD-UPD's file processing have finished close to 23:45 on the 1st of the month.

Warnings are sent to the moderator and all Co-Moderators on record at their registered netmail address as well as in ELIST.
These will be issued during the WARN run, which will happen on the first of each month close to midnight and after the last run of UPDATE has completed say
by 23:50 on the same day.

If an update has not arrived at the elist maintainers system before the end of the issued month then the echo WILL be deleted with the echo transferred to the
Backbone system with elistmaint, 2:25/21 as the listed moderator.

Reminder:
Any registered moderator including Co-moderators for a given echo can send in MOD-UPD .ECO file and/or a Rules file or for that matter a .DES file.
Note that the content of a MOD-UPD only requires at a minimum the following keywords :

FROM
SUBJ
TAG
GROUP
PASS

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 a message regarding the problem/s
found, sent to the sender's netmail address (as on the FROM keyword) and the ELIST echo. Any problems that cause only a warning message to be issued will still allow the Update or echo addition process to be completed.


System Data Limits :
==================

Echo Tag name - 36 character max - UPPER CASE
Echo Group - 16 characters max - UPPER CASE
Echo Title - 72 characters max - Mixed case.
Echo Volume - A monthly figure not exceeding 9999, please be realistic
e.g., 50.
Echo Restrictions - 48 characters which can be /REAL, /SYS & /MOD with a
practical maximum of any of these or NONE or other
comments. Note that the three keywords MUST be upper case.
They MUST also precede any other text (Must be first).
Any other text can be mixed case.
Echo Distribution - 36 characters. Any text.
Echo Gateway - 36 characters. Any text
Echo Lang - 16 characters - any case but converted to UPPER CASE -
Default = ENGLISH
Echo PASSword - 36 characters Mixed case, A-Z, a-z, 0-9 and any symbol
using a standard 105 key keyboard, i.e., no ALT combinations
but not '\' '/' or space.

All sizes assume that one byte equals one character so use a standard character
set as the software does !

elist Operations mini version
-----------------------------

Elist Program:
-------------
The elist program consists of three primary processes driven by one to four parameters namely -

Parameter one:
UPDATE Run 24 times per day at 30 minutes past the hour with the last at 23:30
This process will also run WARN and REPORT on the first of each month
after any updates on or after 23:30.

WARN Run monthly on first of month before REPORT - This process
will delete out of time / warning echos where there has been one
warnings issued over a month period after the 10 month time period
since the last MOD-UPD (update) has been received.
In reality, they are not deleted but transferred over to the BACKBONE
listings with elistmaint as the new so called moderator.
This means that no echo will be auto deleted unless there has been a
minimum period of 10 + 1 months + 1 from the last update or a request
to delete the echo via a MOD-DEL message and that will still stay
until the next WARN run. This runs 1st month after 23:30 after UPDATE.

REPORT Run monthly on first of the month after the 23:30 UPDATE and WARN runs.
This process create two primary files - for each group under control
such as FIDO (using the name ELIST) as ELIST.NA (a list of areas by
Echotag name and Title), and ELIST.RPT a details report for each echo
in Echo Tag order. This file ELIST.RPT for January and July a more
detailed report is generated that includes a copy of any Rules for all
echos in both the ELIST system as well as the Backbone with all
BACKBONE areas so shown.
For non ELIST and FIDO net areas a .NO file that holds deleted echo
areas that are held for 12 months before being deleted. In the event
that a deleted echo is reinstated the entry in the .NO file is removed.
As expired echo's in the ELIST system are transferred to the Backbone
and the .NO file is not created for FIDO.
Any echo that is deleted by use of a submission file from a registered
moderator, the echo is deleted as it is deemed inactive with no
postings for a period no shorter than 12 months, it is not transferred
to the backbone and not stored in the .NO file - it is gone !

Various housekeeping jobs are then run as well as creating the ELST archive for
the past previous month that is then sent to all links of the BBS system. Likewise for all ELIST echo postings by the system. Various back ups are created
and stored in a range of other systems when connected, for security.

There are other processes that are not described as they are used for system security or testing.

Emaint Program:
--------------

The emaint program has only one process.

Run Interactive Maintenance only as needed by the elist maintainer.

This will add, update or delete an existing echo entry as needed or mark a echo
as being on the BACKBONE. It also provides optional displayed listing of all echo's in the system where use of arrow down or up can move between the displayed echo's and the high-lighted one selected for examination or change.

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.


Updated:
2022/04/05 Vincent Coen. 2:250/1, vbcoen=at=gmail.com
Text, grammar, typo's and updates.
2022/05/05 Removed a reference to sending to 250/1.
2022/06/01 Minor corrections.
2022/07/01 Added Warning and Error messages and minor corrections for
processsing steps for WARN, REPORT etc.


--- MBSE BBS v1.0.8 (Linux-armv7l)
* Origin: Elist Maintainer at 2:25/21 (2:25/21)

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 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 <Abbrev. of Network; i.e. FIDO) X16.
Default is FIDO but this keyword must be provided in case
other networks are being supported.

*TAGname <areatag> X36. Warning some older BBS systems may not support
areatag names longer than 8 characters.

*FROM <Contact Address> 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.
<Node as a Netmail address format: zone:net/node{@domain}
Moderator node address (can be a registered echo Co-Moderator)
Note that text between { } 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.

*TITLe <A one line brief area description> X72.

*DESCription <Description of the echo> A maximum of 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.

*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 <Current password>, <New 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 <A one line description of the 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 <Contact Address>
See below for more details of the format for this.
This keyword REPLACES the old keyword COMOD and should be
placed any where 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 <number of messages> 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 </SYSop, /MODerator, /REAl> (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 <origination net address of the echo distribution> X36.
More used in the days where almost all posts originated
from one Netmail address, otherwise a bit redundant.

DISTribution <distribution> Any text describing X72.

GATEway <gateways> Any text describing X72.

CHARSet <Language character set> {, 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 <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.

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 nead to also supply a MOD-UPD.

HELP <Respond with help message>
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.
<blank> 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 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 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 moderatoring.

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 keywd 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 - Aded 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.


--- MBSE BBS v1.0.8 (Linux-armv7l)
* Origin: Elist Maintainer at 2:25/21 (2:25/21)

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 <Abbrev. of Network; i.e. FIDO) X16.
Default is FIDO but this keyword must be provided to support
other networks.

*TAGname <areatag> X36. Warning some older BBS systems may not support
areatag names longer than 8 - 16 characters.

*FROM <Contact Address> 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.
<Node as a Netmail address format: zone:net/node{@domain}
Moderator node address (can be a registered echo Co-Moderator)
Note that text between { } 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 as set up on your system.

*TITLe <A one line brief area description> X72.

*DESCription <Description of the echo> 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 <Current password>, <New 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 <A one line description of the 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 <Contact Address>
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 <number of messages> 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 </SYSop, /MODerator, /REAl> (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 <origination net address of the echo distribution> X36.
More used in the days where almost all posts originated
from one Netmail address, otherwise a bit redundant.

DISTribution <distribution> Any text describing X72.

GATEway <gateways> Any text describing X72.

CHARSet <Language character set> {, 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 <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.

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 <Respond with help message>
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.
<blank> 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)

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 and port 24255 at applewoodbbs.linkpc.net or applewood.linkpc.net, using a file Only. Note the port number !

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 <Abbrev. of Network; i.e. FIDO) X16.
Default is FIDO but this keyword must be provided to support
other networks.

*TAGname <areatag> X36. Warning some older BBS systems may not support
areatag names longer than 8 - 16 characters.

*FROM <Contact Address> 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.
<Node as a Netmail address format: zone:net/node{@domain}
Moderator node address (can be a registered echo Co-Moderator)
Note that text between { } 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 as set up on your system.

*TITLe <A one line brief area description> X72.

*DESCription <Description of the echo> 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 <Current password>, <New 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 <A one line description of the 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 <Contact Address>
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 <number of messages> 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 </SYSop, /MODerator, /REAl> (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 <origination net address of the echo distribution> X36.
More used in the days where almost all posts originated
from one Netmail address, otherwise a bit redundant.

DISTribution <distribution> Any text describing X72.

GATEway <gateways> Any text describing X72.

CHARSet <Language character set> {, 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 <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.

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 <Respond with help message>
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.
<blank> 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.
2022/12/14 vbc - Added 2:25/21 site contact details at text start.


--- MBSE BBS v1.0.8 (Linux-armv7l)
* Origin: Elist Maintainer at 2:25/21 (2:25/21)

On 01 Jan 2023 at 12:30a, Elistmaint pondered and said...

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 and port 24255 at applewoodbbs.linkpc.net or
applewood.linkpc.net, using a file Only. Note the port number !

Hmm 24255 or 24555 ?? Typo?


[snip]

+ 2023.01.09 17:28:14 Queued 5 files (2,094 bytes) for 2:25/21
+ 2023.01.09 17:28:14 1-Polling 2:25/21 on slot 1 via BINKP
+ 2023.01.09 17:28:14 1-Connecting to applewoodbbs.linkpc.net on port 24555
+ 2023.01.09 17:28:16 1-Using address 82.30.228.158
+ 2023.01.09 17:28:16 1-Connected by IPV4 to 82.30.228.158
+ 2023.01.09 17:28:17 1-System Elist Control
+ 2023.01.09 17:28:17 1-SysOp Elistmaint
+ 2023.01.09 17:28:17 1-Location Hatfield, UK
+ 2023.01.09 17:28:17 1-Info NDL CM,XA,IBN
+ 2023.01.09 17:28:17 1-Info TIME Mon, 09 Jan 2023 04:28:17 +0000
+ 2023.01.09 17:28:17 1-Mailer mbcico/1.0.8/Linux-armv7l binkp/1.1
+ 2023.01.09 17:28:17 1-Info PHN applewood.linkpc.net
+ 2023.01.09 17:28:17 1-Info OPM The Elist Maintain Co-Ordinator
+ 2023.01.09 17:28:18 1-Sending: MYSTIC.ECO (332 bytes)
+ 2023.01.09 17:28:19 1-Sending: RBERRYPI.ECO (503 bytes)
+ 2023.01.09 17:28:20 1-Sending: NZ_FIDONET.ECO (358 bytes)
+ 2023.01.09 17:28:21 1-Sending: CBM.ECO (556 bytes)
+ 2023.01.09 17:28:22 1-Sending: X-FILES.ECO (345 bytes)
+ 2023.01.09 17:28:23 1-Session ended (5 sent, 0 rcvd, 0 skip)

[snip]

Looks like it should be 24555

Best, Paul

Kerr Avon [Blake's 7] 'I'm not expendable, I'm not stupid and I'm not going' avon[at]bbs.nz | bbs.nz | fsxnet.nz

--- Mystic BBS v1.12 A47 2021/12/24 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)

Hello Paul!

Monday January 09 2023 17:34, you wrote to Elistmaint:

Thanks for the report - now fixed.

On 01 Jan 2023 at 12:30a, Elistmaint pondered and said...

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 and port 24255 at applewoodbbs.linkpc.net or
applewood.linkpc.net, using a file Only. Note the port number !

Hmm 24255 or 24555 ?? Typo?

[snip]

+ 2023.01.09 17:28:14 Queued 5 files (2,094 bytes) for 2:25/21
+ 2023.01.09 17:28:14 1-Polling 2:25/21 on slot 1 via BINKP
+ 2023.01.09 17:28:14 1-Connecting to applewoodbbs.linkpc.net on port
24555 + 2023.01.09 17:28:16 1-Using address 82.30.228.158 +
2023.01.09 17:28:16 1-Connected by IPV4 to 82.30.228.158 + 2023.01.09 17:28:17 1-System Elist Control + 2023.01.09 17:28:17 1-SysOp
Elistmaint + 2023.01.09 17:28:17 1-Location Hatfield, UK + 2023.01.09 17:28:17 1-Info NDL CM,XA,IBN + 2023.01.09 17:28:17 1-Info TIME Mon,
09 Jan 2023 04:28:17 +0000 + 2023.01.09 17:28:17 1-Mailer mbcico/1.0.8/Linux-armv7l binkp/1.1 + 2023.01.09 17:28:17 1-Info PHN applewood.linkpc.net + 2023.01.09 17:28:17 1-Info OPM The Elist
Maintain Co-Ordinator + 2023.01.09 17:28:18 1-Sending: MYSTIC.ECO
(332 bytes) + 2023.01.09 17:28:19 1-Sending: RBERRYPI.ECO (503 bytes)
+ 2023.01.09 17:28:20 1-Sending: NZ_FIDONET.ECO (358 bytes)
+ 2023.01.09 17:28:21 1-Sending: CBM.ECO (556 bytes)
+ 2023.01.09 17:28:22 1-Sending: X-FILES.ECO (345 bytes)
+ 2023.01.09 17:28:23 1-Session ended (5 sent, 0 rcvd, 0 skip)

[snip]

Looks like it should be 24555

Best, Paul

Kerr Avon [Blake's 7] 'I'm not expendable, I'm not stupid and I'm not
going' avon[at]bbs.nz | bbs.nz | fsxnet.nz

Vincent

--- Mageia Linux v8 X64/Mbse v1.0.8/GoldED+/LNX 1.1.5-b20180707
* Origin: The Elist Maintainer (2:250/1)

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 and port 24555 at applewoodbbs.linkpc.net or applewood.linkpc.net, using a file Only. Note the port number !

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 <Abbrev. of Network; i.e. FIDO) X16.
Default is FIDO but this keyword must be provided to support
other networks.

*TAGname <areatag> X36. Warning some older BBS systems may not support
areatag names longer than 8 - 16 characters.

*FROM <Contact Address> 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.
<Node as a Netmail address format: zone:net/node{@domain}
Moderator node address (can be a registered echo Co-Moderator)
Note that text between { } 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 as set up on your system.

*TITLe <A one line brief area description> X72.

*DESCription <Description of the echo> 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 <Current password>, <New 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 <A one line description of the 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 <Contact Address>
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 <number of messages> 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 </SYSop, /MODerator, /REAl> (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 <origination net address of the echo distribution> X36.
More used in the days where almost all posts originated
from one Netmail address, otherwise a bit redundant.

DISTribution <distribution> Any text describing X72.

GATEway <gateways> Any text describing X72.

CHARSet <Language character set> {, 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 <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.

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 <Respond with help message>
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.
<blank> 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.
2022/12/14 vbc - Added 2:25/21 site contact details at text start.
2023/01/09 vbc - Had wrong port number for 2:25/21 should have been 24555.


--- MBSE BBS v1.0.8 (Linux-armv7l)
* Origin: Elist Maintainer at 2:25/21 (2:25/21)