On Mon, 06 Oct 2014, Michiel van der Vlist wrote to mark lewis:
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...
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.
ummm... perhaps you should be logging your DNS traffic and looking at what binkd is doing... that's how i found out about it some years back ;)
MvdV> Other that that, binkd.net is derived from the nodelist. It is MvdV> just a collection of CNAMEs. So if there is no hostname in the MvdV> 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...
MvdV> Remove the backresolv keyword from the configuration.
that doesn't stop it... it still looks things up... start logging your DNS traffic and try it... since i host a DNS server and all systems in my networks are forced to use my internal DNS servers, it is very easy for me to track and log this info... i brought this up in the binkd echo when i discovered it and one person made an effort to try to tighten things up but it wasn't sufficient... there is still a lot of DNS traffic from 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.
i guess but you can't see that by the way a commonly used and widespread mailer operates...
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...
MvdV> That is not how it works....
but that is how the software works...
[trim]
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...
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 selected MvdV> protocols?
metering is the first thing that comes to mind... we lost numerous african nodes due to metering of international traffic...
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..
the business was good... it was the circumstances that were the problem... that and some greedy child...
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...
MvdV> It so happens that I have a friend who owns a farm. On his land MvdV> there is a 40 meter high tower for an unused wind mill, He rented MvdV> it out to KPN, a major telecom provider. He can not switch off MvdV> the power to that equipment. It has its own connection to the MvdV> power grid. The boxes are locked. Forcing the locks would be more MvdV> than just a breach of contract, it would be a criminal act.
i don't know how this was set up on the tower end... hell, the tower might have been a very tall pine tree with an antenna in the top of it like we have a directional yagi mounted in one of ours... i don't know what they did but i do know that they planned on enhancing the infrastructure as more customers came online... but that childish person ruined things for everyone and finished destroying her relationship with her mother...
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)
MvdV> One system for Fidonet...
over here, all internal FTN systems have one and only one RFC1918 address... the multiple firewalls, one per connection, have one and only one internal RFC1918 address with one and only one external WAN address...
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...
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.
the /machine/ is not multihomed... the internal *networks* are...
MvdV> If you have your fidonet system spread out over more than one MvdV> machine, what on earth have you concocted? Any post year 2000 MvdV> hardware should have many times the processing power and storage MvdV> for even the most busy Fidonet node.
as noted over the past years, there's at least a dozen machines running here 24x7x365.25... all but one or two are repurposed throwaways still working their CPUs out and doing an excellent job of providing the services they provide...
MvdV> You'r not running a Google data centre are you?
LOLOLOLOL!! thanks but no... hahahaha...
[trim]
ml> the network has gone backwards in a bad way :/
MvdV> I disagree. The network has evolved for the better. We had to let MvdV> go of some things, but all in all it runs a lot better than in MvdV> the POTS age. The most noteworthy improvements are the tremendous MvdV> increase in speed of getting a message across the globe and the MvdV> spectacular decrease of cost.
but that doesn't fix the inherent blackhole of BSO :/ at least FD, IM and other traditional mailers will tell you when mail is stuck and undeliverable...
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
MvdV> You have not explained anything. Just mentioned it.
if you can't see it, then forget it... it is very obvious to me... if it wasn't i wouldn't have mentioned it...
ml> and consider metered connections...
MvdV> "meterd connections"??? As in "dial up Internet"? Auw c'mon..
no... metered as in you get XXGig per month and anything over that gets your connection speed forcibly reduced or you are charged outrageous $$$ for all traffic over the cap...
MvdV> dial up internet is technology on the way out. And only an idiot MvdV> would use dial up intenet for running a fidonet node on a metered MvdV> connection. If you have a POTS line and want to use it for MvdV> Fidonet run a POTS mailer.
i have one, thank you... loosen up and look around, please... i point back above to the comment about the african nodes we lost... they could have moved to another zone as Z6 entities did but the metering on their connection was causing them problems... the last african node was robbed and that was the final nail in their coffin... but the driving thing was the metering...
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...
MvdV> The smooth operation of the network is every sysop's concern...
apparently not... not by the way some assume things are to be done and how they attempt to force things on those around them... one need only look at some of our members in the old soviet areas to see this... if Z6 were still active, it could also be seen there... xxcarol related how the asian work ethic demands that all workers under a manager had to quit if the manager got fired... this carried over into their FTN operations, too... when a NC was relieved everyone under him left too...
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...
MvdV> You have failed to make me understand .
i can only try so much... after a while it gets aggrivating to keep trying and we end up loosing it and the discussion devolves into an argument... i've grown extremely weary of that kind of c4rp in recent years... i know you have too as it is apparent in both of our messages in the last years...
[trim]
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)...
MvdV> No, that was not the example given, I have lost you..
when i mentioned the Txy flags possibility of usage with positional INA or other protocol flags, that example was by connection system... apparently we lost each other...
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...
MvdV> And yet the network works very well without all that antiquated MvdV> stuff...
LOLOLOL!! if one didn't know better, one might think that binkd was older than its parent binkleyterm which does more than binkd does (eg: event scheduling) ;)
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...
MvdV> Unjustified...
no, it is not... it stems from numerous problems with the way it operates... run it as a daemon and tell me how you can tell when there is mail sitting in an outbound directory that's not going to go anywhere...
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.
no... blackholes happen for various reasons... typo problems are one where an address may be mistyped... then there are routings where a node disappears that may have been a routing bridge and no one goes back or even knows how to unpack the netmail waiting for that gone node and reroute it via another system so that it can be sent on to the destination OR to even be bounced back to the originating system so they will know that something is broken in the routing... we've seen, in recent months, several blackholes and those on the most simple of system configurations...
)\/(ark
If you think it's expensive to hire a professional to do the job, wait until you hire an amateur.
