Subj : Re: Join DiscipleNet To : Gary McCulloch From : Dan Clough Date : Thu Oct 08 2026 10:03 pm -=> Gary McCulloch wrote to All <=- GM> Wilfred, GM> You were right and I was wrong, so let me deal with that first. GM> Ten nodes plus three administrative entries is thirteen. You took the GM> nodelist off my own website, which is the correct place to take it GM> from, and it was the current one. My post said your scan was hitting GM> stale or unrelated entries. That was not true, and I should have GM> checked before I wrote it rather than after. I have no complaint about GM> the test. GM> WHAT WAS ACTUALLY BROKEN GM> 12:1/0 and 12:12/0 answering "No such AKA" was a real fault and it was GM> mine. My nodelist advertised the Zone and Region entries at GM> call.rofbbs.com:24556 and my hub held only the Host address. I checked GM> the other four networks before replying and the same fault was in all GM> of them - ten addresses advertising an endpoint I did not hold. GM> That is fixed. The hub now holds all sixteen and announces them in the GM> session greeting. Same for a second fault you did not see: thirty-one GM> of my nodes were subscribed to no nodelist file base at all, so the GM> weekly hatch had never sent them a nodelist. On DiscipleNet that was GM> four of the nine. Fixed as well, in time for tomorrow's run. GM> THE UNSECURED SESSION, AND MARK'S QUESTION GM> You are right that this needed declaring, and I had no business GM> calling it correct without saying why. GM> My hub accepts sessions only from systems listed in its own nodelist. GM> Applications do not arrive by netmail here - they come through a web GM> form at rofbbs.com/rofftn/application.php - so the hub never needs to GM> take a session from a system it does not already know, and I would GM> rather it did not. Mark, that is the answer to yours: a new sysop does GM> not have to netmail me, and does not have to get past the hub to GM> apply. GM> What was missing is that the nodelist said none of this. IBN:24556 GM> promises binkp and says nothing about who may call, so your scan was GM> right to read the refusal as a fault rather than as policy. The flag GM> for it already exists - LO, "accepts calls Only from Listed GM> addresses", FTS-5001 section A - and twenty-five nodes in the Zone 1 GM> nodelist carry it. Mine carried it nowhere. It is now on all fifteen GM> hub entries across the five networks and ships in tomorrow's lists. GM> WHAT IS STILL WRONG GM> Several member entries advertise IBN and do not answer one. Those GM> systems are moving mail - they poll me rather than accept calls - so GM> the boards are fine and my nodelist is the thing that overstates them. GM> I am sampling each of them daily for a week rather than acting on one GM> probe, and then correcting the flags for the ones that are genuinely GM> poll-only. That is my data to fix, not theirs. GM> So: the list you scanned deserved most of what it got. GM> One thing that would otherwise confuse the comparison. Tomorrow's GM> rebuild is still day number 282, because MakeNL names its output for GM> the coming Friday and that is tomorrow - same filename, different GM> contents. The header CRC is what tells builds apart. Yours was 36180. GM> The copy on the website now is 40361, rebuilt this morning for a GM> couple of entries with a missing _BBS and a location in capitals, and GM> tomorrow's will differ again for the LO flag. I mention it only so the GM> filename does not mislead you, not to suggest you tested the wrong GM> thing - you did not. GM> If you run the same test against tomorrow's I would genuinely like to GM> see the output, and I will say so publicly either way. At least you owned up to the mistakes that were all on YOUR side. I'll give you credit there for acknowledging that. GM> Thanks for the sweep. It found more in an afternoon than I had found GM> in a year of looking at it myself. Nothing it found was something that anyone running a network shouldn't have already known. Very obvious to anyone who knows anything about FTNs. Basic "101 level" knowledge. One minor point - nodes/downlinks aren't required to receive any files via TIC distribution. You adding every node that wasn't subscribed is not the right thing to do. Some of them may have not been connected to that by their own choice. That's what FileFix is for. If they don't have things configured for that (TIC processor of some sort), the files aren't going to get through anyway. See? .... So easy, a child could do it. Child sold separately. === MultiMail/Linux v0.52 --- SBBSecho 3.37-Linux * Origin: Palantir * palantirbbs.ddns.net * Pensacola, FL * (1:135/115) .