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