REPLY: 1:3634/12.73 61d577f1
MSGID: 2:250/1@fidonet 61d5bee9
CHRS: UTF-8 2
TZUTC: 0000
TID: MBSE-FIDO 1.0.7.22 (GNU/Linux-x86_64)
Hello mark!

Wednesday January 05 2022 04:55, you wrote to me:


 >  On 2022 Jan 04 21:52:16, you wrote to Dallas Hinton:

 VC>> Where does it come from - i.e., file area may be it need to be
 VC>> taken over.

 > the backbone.na, backbone.no, backbone.dst, backstat.na and bofaq (i
 > was mistakenly calling it BOP) documents were all distributed in the
 > BACKBONE FDN by the backbone chairperson when they were updated or
 > simply needed to be refreshed...

 > here is the last listing and descriptions i can find on them as
 > hatched in the BACKBONE FDN by former backbone chairpersons...

 =====>> 8 snip 8<=====

 > backbone.na   List Of Active Echoes Available On The North American
 > Backbone
 > ftp://sestar.synchro.net/file.dist.net/BACKBONE/BACKBONE.NA

 > backbone.no   List Of Inactive Echoes Available On The North American
 > Backbone

 > backbone.dst  List Of Echoes No Longer Available On The North American
 > Backbone

 > backstat.na   Latest Changes and Info On The North American Backbone
 > ftp://sestar.synchro.net/file.dist.net/BACKBONE/BACKSTAT.NA

 > bofag.txt     Authorized May 04, 2003 Issue of BOFAQ.TXT
 > ftp://sestar.synchro.net/main/FIDO-GEN/bofaq.txt

 =====>> 8 snip 8<=====

 > i finally found my latest copy of the BOFAQ in my fido-general file
 > area but it should be in BACKBONE, really... on my old system i had
 > combined some FDNs into what i called FIDO-GEN... it is where my
 > copies of fido's policy documents, two different FTN-Zx<->FTN-Zy
 > gating tools, fidonet history documents, the nobogus tool, the vote
 > manager tool, and an echomail paths mapping tool all reside...

 > there was also a backbone.int file that contained a list of areas
 > reported to be gated from the internet... these were almost all
 > newsgroups... it was apparently dropped at some point and, while i
 > still have a description of it, i don't have the actual last file that
 > was distributed...

 > at some point, gated news groups with slightly altered group names
 > (eg: ALT-POLITICS, ALT-BBS-ADS, ALT-COMP-ANTI-VIRUS) were listed in
 > the backbone.na file with "[GNG]" prepended to their description...
 > fidonet administrative echo also have their descriptions in the
 > backbone.na prepended with "[ADM]"... there might be one other prefix
 > in use but i don't recall it, ATM...

 > so the flow of echotags and descriptions through the various
 > backbone.* files went like this...

 >   1. moderator request for cartage in Z1_BACKBONE...

 >   2. echotag accepted for cartage...

 >   3. echotag and description from the echolist added to backbone.na...

 >   4. at some random point in time, the backbone chairperson would look
 >      over their system and find the backbone areas that had no traffic
 >      over the last X time period or had been dropped from the
 > echolist...

 >   5. echotags that matched in #4 were then moved to backbone.no for
 > some
 >      period of time...

 >   6. after the period of time elapsed and the echotag was still
 > matching
 >      #4 plus the additional period the echotag and description were
 > moved
 >      to the backbone.dst (dst == destroyed) file... it was at this
 > point
 >      that the stars would remove the area from their configs or maybe
 >      move it to their own private distribution list/group...

 >   7. the backstat.na file would be updated with newly added, pending
 > drop,
 >      and destroyed echotags and hatched in the BACKBONE FDN... any
 > other
 >      changes to the backbone would also be noted in this file...

It looks like that BACKBONE.NA is no longer maintained - at least by date and 
cannot find any examples of this file in by BBS files database only on my
internal directory for files of this type (var/arealists).

 > the periods of time in the above steps was random... this to thwart
 > nefairious individuals from trying to game the system... this is much
 > like the echolist having a random time before dropped echotags were
 > actually purged from the echolist database which was to stop nefarious
 > individuals attempting to hijack echotags as soon as they expired...
 > that gave the real moderators/owners of the echotags a chance to
 > update the echotag data so as to keep it under their control...

ELIST uses 6 months as a period for a valid registration then a period of 4
more months giving 4 warnings followed 1 month with a warning it will be
deleted then one more before it is removed so around 12 months in all.

I was thing of reducing the to first warning one day or later for 1st warning
and after the forth up to one month before deleting it with no futher warning
just the announcement that it has been deleted but that only reduces by at 
most
2 months - just not worth the programming effort :)


 > ok, my c0ffee cup is empty so i guess i'll stop here for now ;)

Sounds like a plan,

Vincent

--- Mageia Linux v8 X64/Mbse v1.0.7.22/GoldED+/LNX 1.1.5-b20180707
 * Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1)
SEEN-BY: 25/0 21 153/7715 229/426 250/0 1 10 21 263/0 275/100 640/1321
SEEN-BY: 3634/12
PATH: 250/1 153/7715 229/426