Hello mark,

On Monday October 06 2014 15:46, you wrote to me:

 MvdV>> If you mean binkd, no it is not. Perhaps you mean that it is
 MvdV>> enabled in the sample configuration file that comes with it. Do
 MvdV>> not use * in the host list of the node and defnode keywords and
 MvdV>> it will not use DNS distibuted nodelists.

 ml> ummm... perhaps you should be logging your DNS traffic and looking at
 ml> what binkd is doing... that's how i found out about it some years back
 ml> ;)

I may do that some day, but it is not high on my list of priorities. Also, we
are drifting from the topic at hand. Binkd's DNS is not a matter that concerns
the FTSC, the binkd echo would be a suitable place to discuss it.

 MvdV>>> The nodelist is the primary source of Fdionet connection
 MvdV>>> information. All the information to make a connection MUST be
 MvdV>>> present in the nodelist. DNS distributed nodelists as
 MvdV>>> documenetd in FTS-5004 are an /additional/ service, not a
 MvdV>>> replacement for the nodelist.

 ml>> agreed on both accounts...

 MvdV>> So a protocol flag without an associated host name or IP number
 MvdV>> in the nodelist is an error.

 ml> i guess but you can't see that by the way a commonly used and
 ml> widespread mailer operates...

Binkd does not use the nodelist, so indeed you can not see it.

 ml>> true... the way that line was laid out used the f.n.z because
 ml>> there's no IP or FQDN in the "system name" field so that flag was
 ml>> useless up to that point if the f.n.z was not performed...

 MvdV>> That is not how it works....

 ml> but that is how the software works...

Please enlighten me, what software works that way?

 ml>> again, ISP connection limitations is the first thing that comes
 ml>> to mind...

 MvdV>> How? The connection is either there or it isn't. If it is down,
 MvdV>> one can not use it at all, if it is up, why limit it to
 MvdV>> selected protocols?

 ml> metering is the first thing that comes to mind...

Please explain to me how restricting on-line times depending on protocol helps
to reduce problems causes by metered connections.

 ml> we lost numerous african nodes due to metering of international
 ml> traffic...


You have made that claim before, but never backed it up. But if it is true, how
would having different on-line times for different protocols have prevented it?

 ml>> we tested a wireless ISP a while back and there were problems
 ml>> staying connected that were out of their hands...

 MvdV>> Hmmm.. bad bussines..

 ml> the business was good... it was the circumstances that were the
 ml> problem... that and some greedy child...

The client is without a connection. The reason is irrelevant, the customer will
take his bussiness elsewhere.

But that is of no concern to the FTSC.


 ml>> we have, at various times, had several feeds into this
 ml>> location... you speak above as if you are thinking about one
 ml>> system (multi-homed)

 MvdV>> One system for Fidonet...

 ml> over here, all internal FTN systems have one and only one RFC1918
 ml> address... the multiple firewalls, one per connection, have one and
 ml> only one internal RFC1918 address with one and only one external WAN
 ml> address...

To nme that translates into "one system for Fidnet".

 MvdV>> If a machine is reacheable via different path via different
 MvdV>> providers, than it is multi-homed. The sample nodelist line you
 MvdV>> presented suggested that was actually the case.

 ml> the /machine/ is not multihomed... the internal *networks* are...

Nitpicking. From the outside one can not the layers between the machine and the
WAN interfaces on the router(s). It is a machine reachable via different
providers via different pathes. I.e mult-homed.

 ml> but that doesn't fix the inherent blackhole of BSO :/ at least FD, IM
 ml> and other traditional mailers will tell you when mail is stuck and
 ml> undeliverable...

BSO is no more inherent black hole than AMA. You just need to look at it with
different glasses. With AMA you need a mail reader to have a look at the
outbound netmail folder, with BSO you need to look at the outbound
director[y|ies].

With BSO it is actually simpeler, you do not even need a mail reader. "DIR
*.?lo" on the outbound will do it...

And for those who want more: as Kees mentioned there are tools available.

 ml> i have one, thank you... loosen up and look around, please... i point
 ml> back above to the comment about the african nodes we lost... they
 ml> could have moved to another zone as Z6 entities did but the metering
 ml> on their connection was causing them problems... the last african node
 ml> was robbed and that was the final nail in their coffin... but the
 ml> driving thing was the metering...

Abnd how would redefining the format of the nodelist have stopped that?

 MvdV>> The smooth operation of the network is every sysop's concern...
 MvdV>>

 ml> apparently not... not by the way some assume things are to be done and
 ml> how they attempt to force things on those around them... one need only
 ml> look at some of our members in the old soviet areas to see this... if
 ml> Z6 were still active,

If, if, bimblebiff....

 ml> it could also be seen there... xxcarol related how the asian work
 ml> ethic demands that all workers under a manager had to quit if the
 ml> manager got fired... this carried over into their FTN operations,
 ml> too... when a NC was relieved everyone under him left too...

And what coild the FTSC have done to prevent that?

 MvdV>>> Limited on-line times in addition of ZMH only makes sense for
 MvdV>>> POTS systems where a singes line is shared between Fidonet and
 MvdV>>> another service such as voice or fax.

 ml>> respectfulyl, that is shortsighted and incorrect... see above
 ml>> about ISP connection limitations and metering...

You keep repeating that mantra, but still fail to explain whatthe FTSC coukd
have done to relieve the prolems wth metered connections.

 MvdV>> You have failed to make me understand .

 MvdV>> No, that was not the example given, I have lost you..

 ml> when i mentioned the Txy flags possibility of usage with positional
 ml> INA or other protocol flags, that example was by connection system...
 ml> apparently we lost each other...

I still do not see how that solves the problems with metered connections.

 ml>> i disagree... it is the dumbing down of and especially the
 ml>> failure of newer software to even touch the capabilities of the
 ml>> traditional software used in the heyday of FTN...

 MvdV>> And yet the network works very well without all that antiquated
 MvdV>> stuff...

 ml> LOLOLOL!! if one didn't know better, one might think that binkd was
 ml> older than its parent binkleyterm which does more than binkd does (eg:
 ml> event scheduling) ;)

Event scheduling is no longer needed. The modern OS's all have buid in
schedulers (Windows calls it that task manager)  that are far more flexible
than what I have ever seen in a mailer. InterMail's event manager does not look
furher ahead that a week. The window task manager can schedule an event on
03:00 on the last Sunday in October (end of DST). Or every second Monday in
June, July and August.

Swiss Army knives are usefull when you are on the road. In the workshop, you
are better of with a dedicated tool for each job.

 MvdV>>> The popularity of binkd can be partly ascribed to it NOT being
 MvdV>>> a Swiss army knife and only covering the basics needed to
 MvdV>>> exchange files between systems.

 ml>> yet, it emphasizes, enhances and extends the moniker of
 ml>> "blackhole mailer" that was earned by its parent...

 MvdV>> Unjustified...

 ml> no, it is not...

Yes it is. See above about lookingat it with the right glasses.

 ml> it stems from numerous problems with the way it operates...

Only for those that can't get rid of their FD style way of looking at things.

 ml> run it as a daemon and tell me how you can tell when there is mail
 ml> sitting in an outbound directory that's not going to go anywhere...

DIR *.?lo

 MvdV>> Black holes in Fidonet are found where sysops have made their
 MvdV>> systems so complicated that they have lost track and no longer
 MvdV>> know what is under the hood.

 ml> no... blackholes happen for various reasons... typo problems are one
 ml> where an address may be mistyped... then there are routings where a
 ml> node disappears that may have been a routing bridge and no one goes
 ml> back or even knows how to unpack the netmail waiting for that gone
 ml> node and reroute it via another system so that it can be sent on to
 ml> the destination OR to even be bounced back to the originating system
 ml> so they will know that something is broken in the routing...

All that can be done with BSO as well as with AMA. In both cases one needs to
know how the system operates.

 ml> we've seen, in recent months, several blackholes and those on the most
 ml> simple of system configurations...

One should blame the sysops not the tools...


Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20130111