Indeed, that too is annoying. The TZUTC kludge was introduced in
1997 by Odinn S›rensen per FSP-1001. TWENTY TWO YEARS AGO! It was
documented as a standard (FTS-4008) by the FTSC in 2003. SIXTEEN
YEARS ago! There is really no excuse for not implementing it. It
isn't rocket science. :(
We can live without ^AREPLY but nowadays messages go around the world
in seconds. That's why ^TZUTC would be quite nice to have when sorting messages by time/date.
We can live without ^AREPLY but nowadays messages go around the world
in seconds. That's why ^TZUTC would be quite nice to have when sorting
messages by time/date.
On 11-12-19 12:19, Michiel Van Der Vlist <=-
spoke to Terry Roati about IC and 3 symbols in msg <=-
@MSGID: 2:221/1.58@fidonet de58e816
@REPLY: 2:221/0.1 5dcb2658
@PID: OpenXP/5.0.40 (Win32)
@CHRS: ASCII 1
As far as I can tell TZUTC is well utilized in all 3.
../|ug
--- OpenXP 5.0.40
* Origin: /|ug's Point, Ont. CANADA (2:221/1.58)
As far as I can tell TZUTC is well utilized in all 3.
There is no TZUTC in this message.
--- OpenXP 5.0.40
Maybe the "boss" could add one? ;)
As far as I can tell TZUTC is well utilized in all 3.
There is no TZUTC in this message.
--- OpenXP 5.0.40
Maybe the "boss" could add one? ;)
On 13/11/2019 15:06, August Abolins -> Tommi Koivula wrote:
Maybe the "boss" could add one? ;)
Boss? What boss?
There is no TZUTC in this message.
--- OpenXP 5.0.40
That sucks. :( I can't seem to spot it in config either.
Maybe the "boss" could add one? ;)
There is no TZUTC in this message.
--- OpenXP 5.0.40
Maybe the "boss" could add one?
Sure, but the "boss" should know in which time zone you are when
you post the message.;D
--- TheBoss <== Right on!
* Origin: Point One, Colonia del Sacramento, Zone4 (2:221/0.1)
There is no TZUTC in this message.
That sucks. I can't seem to spot it in config either.--- OpenXP 5.0.40
I also didn't find anything in the sources.
Maybe the "boss" could add one?
I would ask the OpenXP developers first. I think XP's internal
message format supports time zones and there are configuration
options for the time zone (I see it in the language files..
Adding a TZUTC kludge shouldn't be that hard.
something like a TZUTCfix. It would be aMaybe the "boss" could add one?
Sure, but the "boss" should know in which time zone you are when
you post the message.;D
That could probably be announced and then automated via netmail with
very good solution to make TZUTC consistently utilized from your system.
Are you still spouting that fake news?
[Apparently even the last of the renegades has given up resistance. ;-) ]
*You* are the one who runs shit software and I'm fucking GLAD you're
OUT of the FTSC. Your whining and complaining about a kludge pair
thats flawed by design. Good riddance and I hope your Fido departure
is not far behind. It will be a day of big celebration when you and
some others are finally GONE.
Why don't you and your C buddies just fork-off and create another net
were only true old-school Fido veterans are allowed to participate. I heard that Zone 5 and 6 are available.
Why don't you and your C buddies just fork-off and create
another net were only true old-school Fido veterans are allowed
to participate. I heard that Zone 5 and 6 are available.
Well, Zone 5 and Zone 6 were from fidonet
and if them will be online one day they will be fidonet again
other nets starts from zone 10 or higher.
I'm one of the C buddies and I think that it's better that we stay
there.
Maybe you can try get the opportunity to fork-off ;)
Renegade and many others have enjoyed threaded reading that does not depend on kludging. So have TBBS, Squish, Worldgroup/MajorBBS etc. Pretty sure Synchronet can do it without kludging.
*You* are the one who runs shit software and I'm fucking GLAD you're
OUT of the FTSC. Your whining and complaining about a kludge pair
thats flawed by design. Good riddance and I hope your Fido departure
is not far behind. It will be a day of big celebration when you and
some others are finally GONE.
Why don't you and your C buddies just fork-off and create another net
were only true old-school Fido veterans are allowed to participate. I
heard that Zone 5 and 6 are available.
I know, this is the _more_ realistic option. Rebuilding a decentralized (and democratic) Fidonet from the ground up.
I know, this is the _more_ realistic option. Rebuilding a decentralized (and democratic) Fidonet from the ground up.
Maybe you should start from scratch and create such a network and fuck
off to t i...
Renegade and many others have enjoyed threaded reading that does not depend on kludging. So have TBBS, Squish, Worldgroup/MajorBBS etc. Pretty sure Synchronet can do it without kludging.
How does your bbs know that this message from outside your bbs is a reply t message in your bbs?
There are no msgid or reply kludges in this message.
I know, this is the _more_ realistic option. Rebuilding a decentralized (and democratic) Fidonet from the ground up.
I know, this is the _more_ realistic option. Rebuilding a decentralized
(and democratic) Fidonet from the ground up.
Maybe you should start from scratch and create such a network and fuck
off to t i...
I don't understand why Oli should fuck off.
Oli is just as welcome in Fidonet as you are, regardless of node number, point or user staus.
How does your bbs know that this message from outside your bbs is
a reply t message in your bbs?
It uses the Replies field in its database structure to keep track.
@MSGID: 1:229/426 C529A966
@REPLY: 2:280/5555 5dce7155
@TZUTC: -0500
[Apparently even the last of the renegades has given up
resistance. ;-) ]
It wasn't so much giving up resistance; I had the time last night
*You* are the one who runs shit software and I'm fucking GLAD you're
OUT of the FTSC. Your whining and complaining about a kludge pair
thats flawed by design. Good riddance and I hope your Fido departure
is not far behind. It will be a day of big celebration when you and
some others are finally GONE.
Thanks for the compliment. I am sure your enthousiasm will be of great help performing your task of attracting new members and make Fidonet grow again. (P4 3.6)
BTW, regarding "Encouraging new technologies in Fidonet software developmen (FTA-1000, 1.2), how is your IPv6? Any progress?
I don't understand why Oli should fuck off.
A response to his suggestion to other persons, nodelisted "members"
of Fidonet at that.
Good riddance and I [=Z1] hope your [=RC28] Fido departure is not
far behind. It will be a day of big celebration when you and some
others are finally GONE.
Points and users have no rights in Fidonet
many times that the quality of conversation in Othernets is far superior to most convo in Fidonet. Even the non-stop Mystic banter in FsxNet is tolerable.
many times that the quality of conversation in Othernets is farsuperior
to most convo in Fidonet. Even the non-stop Mystic banter in FsxNetis
tolerable.
I'm going to start another beer and bacon thread for you :)
Is there New Zealand beer? I mean, is it any of the Canadian horse piss
I had 2 weeks ago? Or better?
Is there New Zealand beer? I mean, is it any of the Canadian horse piss
I had 2 weeks ago? Or better?
Not only beer but hot/cold water and pay TV :)
You have cold water???
Even the water from my cold tap is hot :(
You have cold water???
Even the water from my cold tap is hot :(
Yeah the Chinese bottle it, send it over, and sell it in chillers in Australia.
Is there New Zealand beer? I mean, is it any of the Canadian horse piss
I had 2 weeks ago? Or better?
Well, Zone 5 and Zone 6 were from fidonet
Really?! ;)
and if them will be online one day they will be fidonet again
You are truly an optimist.
other nets starts from zone 10 or higher.
Is there document where this is defined? If FTN were fully 5D this wouldn't be an issue, unfortunately it is only partially implemented.
I'm one of the C buddies and I think that it's better that we
stay there.
You are a good friend of the ZCs? It seems not every C is best friend
with every other C.
Maybe you can try get the opportunity to fork-off ;)
I know, this is the _more_ realistic option. Rebuilding a
decentralized (and democratic) Fidonet from the ground up.
Can things be improved? Sure, but will they, highly unlikely?
If we want to encourage the use of new technology, why don't we have
flags for TLS,
I don't think we should discriminate against any transport mechanisms or strongly prefer one over the other. Whatever works.
If we want to encourage the use of new technology, why don't we
have flags for TLS,
Someone needs to introduce the flag, define it, propose it ...
If someone is interested in testing TLS connections, I will. It would
also need some discussions about the details (dns srv records?, nodelist flags?, certificates, alpn?).
Connections to a Tor hidden service are straightforward with binkd. My fsxnet node already has a user flag with the onion address in the
nodelist.
Pvt,151,Types_of_Squash_BBS,Thueringen_GER,Oliver_Thuns,- Unpublished-,300,U,ON2:boqbccnwyumttwvh
Your the only one flying the flag ON2 in FSXNET, now if only you could
get a few more sysops interested in ON2 and then document it. I hope
you succeed with this, I am sure there would be uses for it. One
thinks of HK as a for instance.
I don't have tor or an ON2 address, but I think it would be interesting
to get binkp over TLS/SSL.
I'm not sure how to go about that though, or if it's possible with
current implementations.
I don't have tor or an ON2 address, but I think it would be
interesting to get binkp over TLS/SSL.
I'm not sure how to go about that though, or if it's possible with
current implementations.
I don't have tor or an ON2 address, but I think it would be
interesting to get binkp over TLS/SSL.
I'm not sure how to go about that though, or if it's possible with
current implementations.
Even binkd has no built-in support for TLS it is possible in both directions. We already talked about it in FSX_CRY :).
For incoming connections you need to run a TLS proxy like stunnel or nginx. This should work for any binkp mailer.
If you want to test it (TLS or Tor) we can discuss it in FSX_CRY and/or BINKD. Just start a thread there, I read both areas.
I wonder generaly if binkp over SSL/TLS would be good thing or if the current way binkp works is good enough. Binkd and BinkIT (and possibly others) support the CRYPT option. Is that enough?
If you want to test it (TLS or Tor) we can discuss it in
FSX_CRY and/or BINKD. Just start a thread there, I read both
areas.
I don't mind testing either, but as I say I don't know either so you
would need to bring me up to speed.
I don't have tor or an ON2 address, but I think it would be interesting to get binkp over TLS/SSL.
Even binkd has no built-in support for TLS it is possible in both directions. We already talked about it in FSX_CRY :).
Yes, I remember but you mentioned tor and proxy. I don't know these things. Maybe I can put them together, I'm not sure.
I wonder generaly if binkp over SSL/TLS would be good thing or if the current way binkp works is good enough. Binkd and BinkIT (and possibly others) support the CRYPT option. Is that enough?
If you'd like to test this out I'd be willing. I don't know what you mean by TLS proxy so I'd need to be educated about these things before any meaningful tests could be done.. :)
I don't mind testing either, but as I say I don't know either so you
would need to bring me up to speed.
I'd be most interested in something that can be used with the binkp protocol (if that's desirable) in all it's various uses with binkd,
BinkIT and other mailers that would/could use it.
On 15 Nov 19 20:09:50, Tommi Koivula said the following to Nick Andre:t
Renegade and many others have enjoyed threaded reading that does not depend
on kludging. So have TBBS, Squish, Worldgroup/MajorBBS etc. Pretty sure
Synchronet can do it without kludging.
How does your bbs know that this message from outside your bbs is a reply
message in your bbs?
It uses the Replies field in its database structure to keep track.
On 11-25-19 10:10, Michiel Van Der Vlist <=-
spoke to Terry Roati about IC and 3 symbols in msg <=-
running a BBS with users, there must be an even greater "lot" of
users. Where are they? I don't carry all the echos, but I don't see a "lot" of users.
Perhaps that is because your main focus is in the echos that have a technical and/or sysop point of view. That's ok, but there are echos which have users who are not sysops. Those echos tend to be ones
not orientated to sysop type of interest.
As you should. It is a BBS with a different method of access.
As you should. It is a BBS with a different method of access.
Metered local calls is what killed the BBS here. (I wrote a
Fidonews article about that, but that was a long time
ago..)
Worth a read if it can be tracked down. :)
On 11-26-19 15:45, Michiel Van Der Vlist <=-
spoke to Dale Shipp about Users <=-
Perhaps that is because your main focus is in the echos that have a technical and/or sysop point of view. That's ok, but there are echos which have users who are not sysops. Those echos tend to be ones
not orientated to sysop type of interest.
On 11-27-19 05:17, August Abolins wrote to Tony Langdon <=-
[1] A work-around to that might be to fetch an nntp feed of
FNEWS_PUBLISH, (my current feed only goes as far back as 2018),
configure your nntp reader to download the messages for local usage,
and then use the built-in search features of the reader to search by subject or content as necessary.
[2] Another way to hunt for an article would be here:
http://www.fidonet.itu.se/echomail/
It archives the FIDONEWS posts as far back as 2004. It does not feature
a S)earch option, but you can L)ist the messages by Subject, and
identify the headings that represent articles using Ctrl-F in your browser.
[2] Another way to hunt for an article would be here:
http://www.fidonet.itu.se/echomail/
Well, if there's a BBS that has it further back, I could take a feed
then point a newsreader at my own NNTP server. ;)
As you should. It is a BBS with a different method of access.
From one of the last, true BBS sysops that you are, I really love to hear those words from a colleague BBS sysop. :)
[2] Another way to hunt for an article would be here:
http://www.fidonet.itu.se/echomail/
Who is currently supporting this site?
Vladimir,
[2] Another way to hunt for an article would be here:
    http://www.fidonet.itu.se/echomail/
Who is currently supporting this site?
My guess would be 'nobody'... very outdated it seems ... 15 years?
On 11-27-19 20:11, Terry Roati wrote to Tony Langdon <=-
Hello Tony
On Nov 27, 2019 07:06pm, Tony Langdon wrote to August Abolins:
Well, if there's a BBS that has it further back, I could take a feed
then point a newsreader at my own NNTP server. ;)
I have Fidonews from 1985 to present, I did a search for ipv6 and got
220 hits, need to refine the search.
Your more than welcome to login and download what you want.
It is Michael Cronsten at 2:203/412. The site seems to be on auto-pilot.My guess would be 'nobody'... very outdated it seems ... 15 years?[2] Another way to hunt for an article would be here:Who is currently supporting this site?
    http://www.fidonet.itu.se/echomail/
by TLS proxy so I'd need to be educated about these things before any meaningful tests could be done.. :)
If you want to test it (TLS or Tor) we can discuss it in FSX_CRY and/or BINKD. Just start a thread there, I read both areas.
I don't mind testing either, but as I say I don't know either so you
would need to bring me up to speed.
I'd be most interested in something that can be used with the binkp
protocol (if that's desirable) in all it's various uses with binkd,
BinkIT and other mailers that would/could use it.
Having Synchronet/BinkIT listen/accept BINKP/TLS connections is a
piece of cake. Simply add the following to your ctrl/services.ini
file:
[BINKPS]
Enabled=true
Port=24555
Command=binkit.js
LogLevel=debug
Options=TLS
Now, having BinkIT support *outbound* BINKP/TLS connections will
require some (not a ton of) work (in JS); something I'll have to look into. But if anyone wants to experiment, both vert.synchro.net and cvs.synchro.net are answering BINKP/TLS connections on TCP port 24555 right now.
Also, I picked that TCP port number (24555) without a lot of debate,
so consider that a temporarly "assignment" until such time as BINKP
over TLS is more of a standard and an "official" port number is
assigned.
I have Equinox BBS listening with standard binkp on port 24554 and
secure binkps on port 24554.
Now, having BinkIT support *outbound* BINKP/TLS connections will require some (not a ton of) work (in JS); something I'll have to look into. But if anyone wants to experiment, both vert.synchro.net and cvs.synchro.net are answering BINKP/TLS connections on TCP port 24555 right now.
Also, I picked that TCP port number (24555) without a lot of debate,
so consider that a temporarly "assignment" until such time as BINKP
over TLS is more of a standard and an "official" port number is
assigned.
Hello Rob,
Having Synchronet/BinkIT listen/accept BINKP/TLS connections is a
piece of cake. Simply add the following to your ctrl/services.ini
file:
[BINKPS]
Enabled=true
Port=24555
Command=binkit.js
LogLevel=debug
Options=TLS
I have that setup now and binkit.js is listening also on port 24555 with the TLS option.
A couple questions about sessions over TLS. Are session passwords required, and is there anything else I need like a cert of some kind?
Now, having BinkIT support *outbound* BINKP/TLS connections will require some (not a ton of) work (in JS); something I'll have to look into. But if anyone wants to experiment, both vert.synchro.net and cvs.synchro.net are answering BINKP/TLS connections on TCP port 24555 right now.
When that is ready I'll gladly test it out.
I have Equinox BBS listening with standard binkp on port 24554 and secure binkps on port 24554.
Equinox BBS
1:153/757.2
equinoxbbs.ddns.net
Just sent a netmail over binkp/tls. Seemed to work fine.
Just sent a netmail over binkp/tls. Seemed to work fine.
Just sent a netmail over binkp/tls. Seemed to work fine.
Hello Rob,
Just sent a netmail over binkp/tls. Seemed to work fine.
I did receive it and replied. Both over TLS if I'm not mistaken. :)
Without BinkpTLS=true in the node section for 153/757 binkit doesn't
send to 153/757, and with it set to true it attempts to send it but
fails because of a bad password. 153/757 is running binkd and doesn't
have TLS support.
Re: Ialternaernaernative transports
By: Alan Ianson to Rob Swindell on Wed Dec 11 2019 02:32 pm
Hello Rob,
Just sent a netmail over binkp/tls. Seemed to work fine.
I did receive it and replied. Both over TLS if I'm not
mistaken. :)
Cool. That might be a FidoNet-first! :-)
my binkd listens to TLS at binkps-test.uk.to:443 - 2:280/464.47
Just sent a netmail over binkp/tls. Seemed to work fine.
I did receive it and replied. Both over TLS if I'm not
Cool. That might be a FidoNet-first! :-)
my binkd listens to TLS at binkps-test.uk.to:443 - 2:280/464.47
On Wed, 11 Dec 2019 14:02:32 -0800
"Alan Ianson -> Rob Swindell" <0@757.153.1> wrote:
Use a proxy ;)
Re: Ialternaernaernative transports
By: Oli to Rob Swindell on Thu Dec 12 2019 10:05 am
my binkd listens to TLS at binkps-test.uk.to:443 -
2:280/464.47
Do you have a special version of binkd? Where did you get it, I
wouldnt mind playing with it too. (I just got SBBS working with
binkps.) ..deon
On 12.12.2019 7:00, Oli - Alan Ianson wrote:
On Wed, 11 Dec 2019 14:02:32 -0800
"Alan Ianson -> Rob Swindell" <0@757.153.1> wrote:
doesn't AI>> send to 153/757, and with it set to true it attempts to
send it but AI>> fails because of a bad password. 153/757 is running
binkd and doesn't AI>> have TLS support.
Use a proxy ;)
Maybe someone wants to try 2:221/6:
binkps://news.fidonet.fi:24567
I did receive it and replied. Both over TLS if I'm not mistaken. :)
Cool. That might be a FidoNet-first! :-)
Hello Rob,
I did receive it and replied. Both over TLS if I'm not mistaken. :)
Cool. That might be a FidoNet-first! :-)
Yep.. I have tested with a few nodes at this point and all seems to work well. It's simple, easy and painless to do with Synchronet/BinkIT.
Thanks for your work on that.. :)
I'm about to try linking up my Synchronet with it's boss node running binkd. I haven't done that yet but I see others have so I'll see if I can follow their examples.
I'm about to try linking up my Synchronet with it's boss node
running binkd. I haven't done that yet but I see others have so
I'll see if I can follow their examples.
Cool. Next steps are probably to define (or get IANA to assign) an "official" binkps TCP port number. And then maybe a nodelist flag
should be defined so nodes supporting binkps (instead-of or
in-addition-to binkp) can be automatically identified.
On Fri, 13 Dec 2019 17:59:30 -0800
"Rob Swindell -> Alan Ianson" <0@705.103.1> wrote:
I'm about to try linking up my Synchronet with it's boss node
running binkd. I haven't done that yet but I see others have so
I'll see if I can follow their examples.
Cool. Next steps are probably to define (or get IANA to assign) an "official" binkps TCP port number. And then maybe a nodelist flag should be defined so nodes supporting binkps (instead-of or in-addition-to binkp) can be automatically identified.
There is much more to do for the standardization. An IANA number is the least important.
Do we really need an official port number?
Or is it better to rely on other
ways as many nodes use a non-standard port number anyway:
- SRV records (_binkps._tcp should be mandatory)
- Nodelist flag (INBS ?)
- should we allow self-signed certificates? (yes)
- which TLS version are allowed? (>= TLS v1.3)
- should the client use alpn?
Cool. Next steps are probably to define (or get IANA to assign) an
"official" binkps TCP port number. And then maybe a nodelist flag
should be defined so nodes supporting binkps (instead-of or
in-addition-to binkp) can be automatically identified.
There is much more to do for the standardization. An IANA number is the least important.
Do we really need an official port number? Or is it better to rely on other ways as many nodes use a non-standard port number anyway:
- SRV records (_binkps._tcp should be mandatory)
- Nodelist flag (INBS?)
- should we allow self-signed certificates? (yes)
- which TLS version are allowed? (>= TLS v1.3)
- should the client use alpn?
You mean IBNS: ? Most flags seem to be a 3 letter combination, so maybe use: IBS: ?
You mean IBNS: ? Most flags seem to be a 3 letter combination, so
maybe use: IBS: ?
I don't think there's any standard nor guideline how a flag should be structured.
"PING" has 4 characters and "TRACE" 5.
But given the line length limits that still seem to exist in some
nodelist processing software, we shouldn't use more characters than necessary?
But given the line length limits that still seem to exist in some
nodelist processing software, we shouldn't use more characters than
necessary?
Like "which" products are we talking about ?
* Originally in FIDONEWS
* Crossposted in BINKD
Hi Oli,
On 2019-12-14 08:29:58, you wrote to Rob Swindell:
Cool. Next steps are probably to define (or get IANA to assign) an
"official" binkps TCP port number. And then maybe a nodelist flag
should be defined so nodes supporting binkps (instead-of or
in-addition-to binkp) can be automatically identified.
There is much more to do for the standardization. An IANA number is the least important.
But we should agree in fidonet on the default/preferred port to use! So it doesn't have to be specified in the nodelist if you use the default.
(24553 is unassigned by IANA)
detailsBut we should agree in fidonet on the default/preferred port to use! So
it doesn't have to be specified in the nodelist if you use the default.
(24553 is unassigned by IANA)
I requested an IANA port assignment for "binkps" today, requested tcp/24553. I Will update on progress as I learn it or you can check for yourself at:
https://tools.iana.org/public-view/viewticket/1158485 (not a lot of
there though).
; But we should agree in fidonet on the default/preferred port to use! So it
; doesn't have to be specified in the nodelist if you use the default.
; (24553 is unassigned by IANA)
I requested an IANA port assignment for "binkps" today, requested tcp/24553. I Will update on progress as I learn it or you can check
for yourself at:
https://tools.iana.org/public-view/viewticket/1158485 (not a lot of details there though).
There is much more to do for the standardization. An IANA number
is the least important.
Do we really need an official port number?
Since there's already a standard plaintext TCP port, there should
also be a standard TLS/TCP port.
Or is it better to rely on other
ways as many nodes use a non-standard port number anyway:
- SRV records (_binkps._tcp should be mandatory)
That doesn't work for look-ups using binkp.net however.
- Nodelist flag (INBS ?)
I don't care much (I don't use a nodelist here).
Do we really need an official port number? Or is it better to
rely on other ways as many nodes use a non-standard port number
anyway:
- SRV records (_binkps._tcp should be mandatory)
Not everyone's dns "interface" is able to set this I think.
- Nodelist flag (INBS?)
You mean IBNS: ?
Most flags seem to be a 3 letter combination, so
maybe use: IBS: ?
- should the client use alpn?
If necessary. ;)
But I have access to a lot of linux machines, older and newer. But
none of the openssl and ncat versions I checked seem to support it...?
But we should agree in fidonet on the default/preferred port to
use! So it doesn't have to be specified in the nodelist if you
use the default. (24553 is unassigned by IANA)
I requested an IANA port assignment for "binkps" today, requested tcp/24553. I Will update on progress as I learn it or you can check
for yourself at:
https://tools.iana.org/public-view/viewticket/1158485 (not a lot of details there though).
- Nodelist flag (INBS?)
You mean IBNS: ?
Yes
Most flags seem to be a 3 letter combination, so
maybe use: IBS: ?
Irritating bowel syndrome?
should- should the client use alpn?
If necessary. ;)
But I have access to a lot of linux machines, older and newer. But
none of the openssl and ncat versions I checked seem to support
it...?
Okay. I didn't know that. ALPN is required for http/2 and http/3, it
be supported by any recent TLS library. But I'm not sure how important it is to (for example) share port 443 for http, xmpp and binkp.
Or is it better to rely on other
ways as many nodes use a non-standard port number anyway:
- SRV records (_binkps._tcp should be mandatory)
That doesn't work for look-ups using binkp.net however.
That is binkp.net problem. The specification clearly states that the mailer has to make a SRV query first.
We shouldn't develop standards around broken implementations.
- Nodelist flag (INBS ?)
I don't care much (I don't use a nodelist here).
others do :)
On Sat, 14 Dec 2019 13:41:37 -0800
"Rob Swindell -> Wilfred van Velzen" <0@705.103.1> wrote:
But we should agree in fidonet on the default/preferred port to
use! So it doesn't have to be specified in the nodelist if you
use the default. (24553 is unassigned by IANA)
I requested an IANA port assignment for "binkps" today, requested tcp/24553. I Will update on progress as I learn it or you can check
for yourself at:
https://tools.iana.org/public-view/viewticket/1158485 (not a lot of details there though).
I don't understand why you are rushing it?
It would be nice, if you had wait
a bit longer how the discussion develops. That said, I also used 24553 in my tests a few weeks ago.
I don't consider it rushed. There's plenty of examples of plain-text
TCP application protocols that have had secure (*s over TLS/SSL) alternative port assignments. It's not rocket science.
I don't consider it rushed. There's plenty of examples of
plain-text TCP application protocols that have had secure (*s
over TLS/SSL) alternative port assignments. It's not rocket
science.
Instead of having binkp tunneled through external TLS connection, something like STARTTLS should be implemented in binkp proto, removing
the need of an additional port. This is how TLS works in SMTP on
standard 25 port. This way no changes would be needed in either
nodelist flags or DNS. If a node supports TLS, it will be negotiated
and used. If not, plain-text protocol will be used, unless it is configured to use TLS-only on a supporting node.
So, what is the rush here? Why trying to push a very poor
implementation as soon as possible without involving binkd developers
at least?
Hello Rob!
On Sun, 15 Dec 2019 at 12:26 -0800, you wrote to Oli:
I don't consider it rushed. There's plenty of examples of plain-text TCP application protocols that have had secure (*s over TLS/SSL) alternative port assignments. It's not rocket science.
Instead of having binkp tunneled through external TLS connection, something like STARTTLS should be implemented in binkp proto, removing the need of an additional port.
This is how TLS works in SMTP on standard 25 port.
This way
no changes would be needed in either nodelist flags or DNS. If a node supports TLS, it will be negotiated and used. If not, plain-text protocol will be used, unless it is configured to use TLS-only on a supporting node.
So, what is the rush here?
Why trying to push a very poor implementation as
soon as possible without involving binkd developers at least?
Instead of having binkp tunneled through external TLS connection,I prefer running TLS on it's own port.
something like STARTTLS should be implemented in binkp proto,
removing the need of an additional port. This is how TLS works in
SMTP on standard 25 port. This way no changes would be needed in
either nodelist flags or DNS. If a node supports TLS, it will be
negotiated and used. If not, plain-text protocol will be used,
unless it is configured to use TLS-only on a supporting node.
STARTTLS is not a bad thing and would be better than nothing but
leaves room for a man in the middle attack.
So, what is the rush here? Why trying to push a very poorI don't think anyone is rushing anything, just moving in that
implementation as soon as possible without involving binkd
developers at least?
direction.
Synchronet's implementation is looking good to me. Direct TLS and is working in my experience.
The binkd developers are most welcome although I am not sure who they
are. Alexey perhaps but I am not sure. There is some discussion of all this in the BINKD area that I have been following and hoping to see
the binkd developers there.
Instead of having binkp tunneled through external TLS connection,STARTTLS and other forms of Explicit/Opportunistic TLS has been
something like STARTTLS should be implemented in binkp proto,
removing the need of an additional port.
deprecated by the IETF in favor of Implicit TLS, for all protocols: https://tools.ietf.org/html/rfc8314
This wayGo for it. You can have both Implicit and Opportunist/Less-secure TLS support. I choose the former.
no changes would be needed in either nodelist flags or DNS. If a
node supports TLS, it will be negotiated and used. If not,
plain-text protocol will be used, unless it is configured to use
TLS-only on a supporting node.
So, what is the rush here?It's the established "best practice" solution for transport layer
security (trust and privacy) for TCP application protocols. Nobody is reinventing the wheel here.
Why trying to push a very poor implementation asDo you consider https to be a "very poor implementation"?
soon as possible without involving binkd developers at least?
binkps is to binkp as https is to http. I don't need to ask anyone's permission. You don't like it? Don't use it.
STARTTLS is not a bad thing and would be better than nothing but
leaves room for a man in the middle attack.
No it doesn't. MitM attack can only fool client into thinking that TLS
is not supported. But you can require TLS on a client side and it will just disconnect, no harm done.
That's a wrong direction. Before moving into some direction it is nice
to weight all opinions, especially ones from current binkd developers.
Synchronet's implementation is looking good to me. Direct TLS and
is working in my experience.
Still it requires modification to configurations, nodelist changes and probably DNS changes as well. STARTTLS would eliminate all of that.
The binkd developers are most welcome although I am not sure who
they are. Alexey perhaps but I am not sure. There is some
discussion of all this in the BINKD area that I have been
following and hoping to see the binkd developers there.
In fact this doesn't look like a good place to discuss technical
stuff, BINKD seems like a better one.
No it doesn't. MitM attack can only fool client into thinkingI believe it does.
that TLS is not supported. But you can require TLS on a client
side and it will just disconnect, no harm done.
That's why STARTTLS has been depricated.
I don't think the binkd developers are going to bring STARTTLS to the table but we need to hear from them.
Synchronet's implementation is looking good to me. Direct TLS
and is working in my experience.
Still it requires modification to configurations, nodelistIt requires a binkps listener to receive and "BinkpTLS=true" in the
changes and probably DNS changes as well. STARTTLS would
eliminate all of that.
node section of sbbsecho.ini for nodes you want to poll with binkps.
In fact this doesn't look like a good place to discuss technicalI have eyes on the area so we can move the discussion there if you
stuff, BINKD seems like a better one.
like.
Or is it better to rely on other
ways as many nodes use a non-standard port number anyway:
- SRV records (_binkps._tcp should be mandatory)
That doesn't work for look-ups using binkp.net however.
That is binkp.net problem. The specification clearly states that
the mailer has to make a SRV query first.
Which specification is that?
We shouldn't develop standards around broken implementations.
I'm not sure what you're implying here.
What sort of problem does the above cause?
Especially when the TZUTC kludge is also missing.
How do Wards useless nodelist flags affect your system?
What common tech specs will they use?
The ones people agree to. I mean we already have a tech specs.
Who keeps them maintained in a central library? Why should anyone
agree to any?
Because! Without any agreement, no communication. I'm also not sure how coordinators are responsible for any standardization (apart from Ward inventing useless nodelist flags that are not part of any central specification library)?
One of the essential specifications is still hiding between completely irrelevant proposals.
One of the essential specifications is still hiding between
completely irrelevant proposals.
And that specificatien is?
!WimpLink Point software package for Acorn RISC OS.
| Sysop: | Weed Hopper |
|---|---|
| Location: | Clearwater, FL |
| Users: | 14 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 235:06:11 |
| Calls: | 55 |
| Calls today: | 1 |
| Files: | 50,128 |
| D/L today: |
47 files (7,109K bytes) |
| Messages: | 275,441 |