Text 7381, 283 rader
Skriven 2014-10-06 15:47:24 av Michiel van der Vlist (2:280/5555)
     Kommentar till en text av mark lewis (1:3634/12.0)
Ärende: FTSC-5001 question
==========================
Hello mark,

On Sunday October 05 2014 12:21, you wrote to me:

 MvdV>> That is a nono. After the folding of fidonet.net the Fidonet
 MvdV>> community realised that depening on a third party over which
 MvdV>> Fidonet has no control is a bad idea.

 ml> that's fidonet... other FTNs do use such and there is the binkp.net
 ml> which is used by default by a very widely used mailer...

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

Other that that, binkd.net is derived from the nodelist. It is just a
collection of CNAMEs. So if there is no hostname in the nodelist, bink.net
won't have a CNAME for it either.

 ml> that mailer looks up everything and i've not yet found any way to stop
 ml> it from doing any DNS lookups other than that required for the initial
 ml> outbound connection... all connections results in numerous to many DNS
 ml> lookups... especially inbound connections and even moreso those that
 ml> present large AKA lists... every one of those addresses is looked up
 ml> and several times during the same connection in some cases...

Remove the backresolv keyword from the configuration.

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

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

 ml>>  2. the first IBN applies only to site1.tld. there is no ITN or
 ml>> IVM there and the f.n.z.domain.tld doesn't handle it at all.

 MvdV>> DNS distributed nodelists are a third part service. The Fidonet
 MvdV>> nodelist clerks have no control over it. They can not stop the
 MvdV>> operator of that service to include it,.

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

That is not how it works....

 MvdV>> ,12,some_system,some_location,a_sysop,#-###-###-####,33600,XA,V
 MvdV>> 34 ,CM,
 MvdV>> INA:site3.tld,IBN,ITN,IVM,IBN:site1.tld,ITN:site2.tld,PING

 ml> i guess that would work... the question is if all nodelist parsing
 ml> software will handle it correctly...

Probably not. Most nodelist parsing software was designed in the POTS only age.
It was written under the assuption that there is just one telephone number,
host name or IP number for each node. In case of host names or IP numbers the
nodelist offers the option of listing more than one, but I doubt there is a lot
of software that can deal with it properly.

 MvdV>> It is a mystery to me why anyone would compose such an exotic
 MvdV>> system.

 ml> connection limitations is one of the first that come to mind... in the
 ml> original example, site3 was to be a final backup if the others could
 ml> not be reached...

You know, you don't HAVE to list all your connections in the nodelist. It is
not a MUST. All that is required is that you list /a/ connection method that
will let others connect to you. This is an amateur network. No one will hold it
against you if you can not offer 100% connectivity. It is OK to only publish
the more obscure connectiom methods to a limited number of selected parties.

In fact here this was not unusual in the POTS age. Several nodes/BBSs here in
The Netherlands had two telephone lines. But only one of the numbers was
published in the nodelist. The other number was only given to preferred
users/points. The second line did not need to observe ZMH of course. So users
could continuue to be served all night.

 MvdV>> Why on earth would anyone with a multihomed connection -
 MvdV>> IBN is reachable via two different paths and so is ITN, so the
 MvdV>> system is multihomed - only make some servers available via
 MvdV>> multihoming and some others only via one path?

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

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

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

Hmmm.. bad bussines..

 ml> the person they were leasing the land from had a jealous adult
 ml> daughter who kept killing the power to the tower equipment on the
 ml> leased land... she was doing this because she was mad at not getting
 ml> any of the lease $$$ being paid to her mother, the land owner... when
 ml> the connection was up, it was great... it was a family thing and the
 ml> law was not involved between them about it... eventually, the ISP
 ml> removed their equipment...

It so happens that I have a friend who owns a farm. On his land there is a 40
meter high tower for an unused wind mill, He rented it out to KPN, a major
telecom provider. He can not switch off the power to that equipment. It has its
own connection to the power grid. The boxes are locked. Forcing the locks would
be more than just a breach of contract, it would be a criminal act.

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

One system for Fidonet...

 ml> but it is not... each connection has its own firewall and internal
 ml> routing on the shared internal network... inbound traffic gets sent to
 ml> the desired internal machine and outbound traffic flows as
 ml> appropraite... no machines are multi-homed other than a laptop or two
 ml> and they have  nothing to do with any FTN ops...

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

If you have your fidonet system spread out over more than one machine, what on
earth have you concocted? Any post year 2000 hardware should have many times
the processing power and storage for even the most busy Fidonet node. You'r not
running a Google data centre are you?

 ml> besides, how many out there really know how to use bonk, SonOfBonk or
 ml> similar tools that /might/ be able to unpack mail and repack it to
 ml> another system? how many really understand why that is done?
 ml> especially those that are converted from dynamic mailers like
 ml> frontdoor, intermail and (i'm guessing) IREX which do all of this for
 ml> you in the background...

I am one of those converts... I have been using dynamic mailers for well over
two decades. I started out with InterMail. It so happened that the fellow ham
who introduced me to pointing was the InterMail distributor for The Netherands,
s I got a nice deal on the full version of InterMail. I have tried FrontDoor as
well but, I did not see enough added value over InterMail to also obtain a paid
version of FrontDoor. So I continued with InterMail. When I got adsl, I added
Irex to the system. It works fine as a dynamic mailer along with InterMail, but
its nodelist processing capabilities are ... eh... limited...
Among other things it is not able to reroute mail to another destination by
itself if the first destination is unreacheable.

Anyway... The reason I finally made the plunge to switch from a dynamic to BSO
is... IPv6. It is my not so humble opinion that Fidonet will not survive if it
ignores IPv6. Here in Europe ISP's are experimenting with Carrier Grade Nats.
Several ISP's in Germany and Austria and one in The Netherlands are going DS
lite. You get a native IPv6 address plus an IPv4 adress in a private range.

That means one cannot run servers on Ipv4. Outgoing calls only. As of now no
Fidonet sysop has been affected, but that is matter of time. An IPv4 only
Fidonet is doomed.

Irex is abandonware. Has been for over a dacade, I have given up hope it will
ever do IPv6. Presently the only mailer running on Windows that does IPv6 is
binkd....

I was very reluctant to change my system to BSO and I have pestponed it for
almost two years after Andre Grueneberg added IPv6 to binkd, but earlier this
year I did the inevitable, I made the plunge.

when I do things like that, I go all the way. No compromises. No half hearted
solutions as a hybrid system. I rebuild my system from scratch. Out if the
window went Irex, in came binkd. Intermail dos not work with binkd either, so
exit InterMail. And with that exit POTS. Got no calls for the last five years
anyway.

I also threw out a lot of stuff that was seldom or never used. I leaned down my
system. You might call it dumbed down, but it has become a lot more transparent
and easier to maintan. Yes, I had to go through a learning curve again. But I
do not regret it. I will not go back to Irex and InterMail.

 ml>  the network has gone backwards in a bad way :/

I disagree. The network has evolved for the better. We had to let go of some
things, but all in all it runs a lot better than in the POTS age. The most
noteworthy improvements are the tremendous increase in speed of getting a
message across the globe and the spectacular decrease of cost.

 ml>> intelligent mailers and nodelist using software would have no
 ml>> problem with this... it should also allow for the Xx flags to be
 ml>> listed with each as well as pretty much all other flags... i can
 ml>> easily see the Txy flags being listed with INA flags indicating
 ml>> that sitex.tld is operational at certain times...

 MvdV>> Another one of your unrealistic exotic scenerios.

 ml> bite me... it is not un-realistic... see the above about ISP
 ml> connection limitations

You have not explained anything. Just mentioned it.

 ml>  and consider metered connections...

"meterd connections"??? As in "dial up Internet"? Auw c'mon.. dial up internet
is technology on the way out. And only an idiot would use dial up intenet for
running a fidonet node on a metered connection. If you have a POTS line and
want to use it for Fidonet run a POTS mailer.

And only a complete idiot would use a dial up metered connection for running
Fidonet over IP if he had an alternative like dsl or cable.

One can not expect the whole network to redifine all its flags definitions and
adapt all software just to appease the one weirdo that fits the figments of
your imagination. This is ridiculous. Let him use a separate node number for
such exotics.

 MvdV>> "Smooth operation of the network" is not served by building
 MvdV>> system with excotic combinations of on-line times.

 ml> that's not my problem...

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

 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 about
 ml> ISP connection limitations and metering...

You have failed to make me understand .

 MvdV>> A classic POTS line can handle just one connection per physical
 MvdV>> line. Internet connection do not have that limitation. One
 MvdV>> physical line can carry many connection, so time sharing
 MvdV>> between services is not needed. All services can use the line
 MvdV>> simultaneously at all times.

 ml> you misunderstand the reason for limited online times in today's
 ml> world...

Indeed I do not understand. You have failed to make it clear. Yiu espcially
have failed to make me understand why we need different on-line times for
different protocols in One and the same nodelist line.

 MvdV>> Limiting time depending on service makes no sense.

 ml> i don't know what you mean buy this... the example given was to limit
 ml> online time by system (aka nodenumber)...

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

 ml>> the sad thing is that the intelligence that mailer software used
 ml>> to have has been lost...

 MvdV>> It is those that demand that the systems covers more and more
 MvdV>> protocols in exotic scenarios that are partly to blame for
 MvdV>> that.

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

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

 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 "blackhole
 ml> mailer" that was earned by its parent...

Unjustified...

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


Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20130111
 * Origin: http://www.vlist.org (2:280/5555)