Text 7383, 288 rader
Skriven 2014-10-06 15:46:46 av mark lewis (1:3634/12.71)
Kommentar till text 7381 av Michiel van der Vlist (2:280/5555)
Ärende: FTSC-5001 question
==========================
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.
--- FMail/Win32 1.60
* Origin: (1:3634/12.71)
|