Text 30267, 142 rader
Skriven 2012-06-28 12:35:19 av mark lewis (1:3634/12.0)
  Kommentar till text 30257 av Robert Bashe (2:2448/44)
Ärende: Link requ... blah blah
==============================
ml>> binkd does not require a nodelist like frontdoor, binkleyterm, and
ml>> other "real" FTN mailers...

RB>> I'm aware of that - it's also sometimes a PIA when you want to write
RB>> to someone you haven't contacted before.

ml> this is where routing comes in...

 RB> Why route a netmail when your destination is IP capable? I never do
 RB> that if I can avoid it.

why? because you've not had contact with them before for one reason... why deal
with a PIA[sic] when you can simply let the system route it normally?

RB>> The programs I've seen for extracting IP systems from the nodelist
RB>> and putting the data into "include" files for binkd all have
RB>> limitations of one kind or the other, so you often have to enter node
RB>> data manually.

ml> you'll have to be more specific... what's wrong with the BINK.TXT file
ml> that is hatched every week?

 RB> It's not generated by my system. I don't like the idea of having to
 RB> import still another file, when the information I want is on my
 RB> system (the nodelist) and could be put in the proper form IF there
 RB> were a (simple, i.e. no extra libraries like PERL and that sort of
 RB> junk) program to do the job.

so get to scripting or writing one... i don't see how you could trust a program
you haven't written if you can't trust the results of one that someone else
wrote...

RB>> It would be nice to have a program that would scan the nodelist,
RB>> pick out _all_ the various types of IP nodes, for example...

RB>> ,44,abel.dnsalias.net,Datteln,Robert_Bashe,49-2363-56073,9600,CM,
RB>> XA ,MO,V34,V42B ,V110H,X75,IBN,U,ENC

RB>> _and_

RB>> Host,203,West_Net,Sweden,Bjorn_Felten,46-31-960447,33600,CM,XA,V3
RB>> 4, IBN,INA:felt en.yi.org,U,NEC

RB>> ... and then include the password data from the FASTLST.PWD file
RB>> for passworded nodes.

ml> they should already be defined in your binkd connection file...

 RB> Naturally, I have this data for people with whom I regularly
 RB> correspond, but not for _all_ IP capable systems.

then there won't be a password in that file for them... besides, the above
mentioned BINK.TXT already contains all that you desire for the output... i
don't recall, though, if the code is available...

ml> i have (at least) two include files... the first is "myconns.txt" (or
ml> whatever you want to call your file of known contacts) and the second
ml> is the distributed BINK.TXT i mentioned above...

 RB> I suppose that would also be a solution, but I really would rather
 RB> generate an include file of IP capable nodes (with passwords) right
 RB> here at my system. 

you've already got that! you generated it when you added them to your list with
their password... everything else is just plain non-secure connections...

RB>> But I don't know of any thing that will fo this, and runs under OS/2
RB>> as well.

ml> a REXX script might be able to handle it... or maybe a 4OS2/4DOS
ml> script... i dunno...

 RB> I don't either ;-)

what i meant by that is that i do not know the format of that file you spoke
of... you have and use that file so you would know more about it than i...

RB>> Anyway, even binkd requires the data in the nodelist to contact a
RB>> remote system, so one way or another, anyone who is a node in more
RB>> than name only needs it.

ml> actually not... all binkd requires is a FTN address... it
ml> automatically converts them to f.n.z format and will check the DNS for
ml> the default domain to see if there's a DNS entry for it (eg:
ml> f12.n3634.z1.binkp.net)...

 RB> So if you have someone listed in binkd.cfg as:

 RB> node 1:393/31.0 - - -

 RB> (just as an example), binkd will actually use this to send a
 RB> message? 

it would seem so but the binkd.txt uses an asterisk '*' at the first dash and
only has 4 fields instead of 5 like you show...

 RB> Hard to believe, but maybe it will work. Never tried anything like 
 RB> that. 

i don't know because i don't make entries like that... however, i do know that
binkd will convert to f.n.z format and perform dns lookups on that... i have
monthly dns log files over 200m in size filled with exactly this...

RB>>> A point doesn't need a nodelist,

ml>> if they don't contact anyone other than their bossnode but they still
ml>> have to have a nodelist with at least the boss and their entries...

RB>> Not really. The Boss entry in the nodelist is all that's really
RB>> required, not the entire list. Although most points I know have the
RB>> nodelist anyway, just in case they might want to contact someone
RB>> other than their Bossnode.

ml> and hopefully that connection isn't secure with their boss... but this
ml> may be properly handled now days... it wasn't for many years, though
ml> ;)

 RB> Secure? Normally, a point would have a password with the Bossnode,

you missed it... hopefully the connection between the boss node and the other
node the user wants to contact is not secure... if it is, the point will not be
able to connect without the password of the boss...

  ie: a:b/c -> x:y/z is secure
      a:b/c.d wants to connect with x:y/z directly... secure or not...

i don't know about today but this was a problem in the past... it had to do
with the idea that points only contact their boss and no one else... this is
the same as points routing all their outbound netmail thru their boss... i
don't know where this idea came from or why it was allowed to spread but it did
and AFAIK it is still in effect today... the end result was that the point
system had to have the same password with x:y/z as the boss and that's not a
good thing...

 RB> but that would be optional in the case of connections with other
 RB> systems. I'm not sure what you mean above.

is that better?

)\/(ark

 * Origin:  (1:3634/12)