Subj : Re: Is binkp/d's security model kaputt?
To   : apam
From : deon
Date : Wed Sep 22 2021 11:31 pm

  Re: Re: Is binkp/d's security model kaputt?
  By: apam to deon on Wed Sep 22 2021 06:22 pm

Howdy,

 > Are you already working on a way to use HTTPS etc? I knew you had a
 > project you're working on, but didn't realize what it was..

Not HTTPS specifically (at this stage anyway). What I've created so far is an FTN mailer and tosser using:
* mongodb for mail storage. I'm not settled on mongo, but tried it out because I wanted to try it out - never having used it before, and I wanted to see what all the fuss was about. Also I want to try out active-active replication, so that multiple systems (me and anothers) could be an authoritive hub for mail. The idea being if one of us is down, DNS could flick you to another site to deliver and get your mail. When you come back online, the backend re-syncs automatically with what it missed out on.

* postgresql - I started out on psql only because I may go to CockroachDB (which talks psql). Also with an SQL DB, DB constraints help ensure data integrity (something that mongo, a nosql DB doesnt provide) and actually helps me iron out silly bugs. CochroachDB is something I may play with, because it to supports active-active in lieu of mongo.

In theory I could ditch the idea of an SQL DB and just use mongodb completely, which is also an option still at the moment.

Now that I have a working environment (it is currently exchanging BINKP mail with Hub 3, and EMSI mail with my old dos BBSes), I am ironing out the bugs. Al's test message the other day (from his point) wasnt handled correctly so that's next to fix.

When this is stable, I can support "legacy BBS" mailers and tossers (which is the current status quo).

With bugs sorted, I then have a base that I can spin up new ideas (protocols, packet formats, distrution models) fairly easy and quickly. Pulling mail out of an sql/nosql db is just a simple query.

My goals for "the new way" is security (which is where HTTPS may come in, or TLS in general I guess), improved authentication (HTTPS can help here), improved integrity (that a bundle comes from a known system), and effeciency (aka no bloat, lean and mean). (There's probably other ideas there too.) I think there are many advanced techniques (that didnt exist in 1990) that could be leveraged for the value that they provide.

 > You and tenser are probably much more clued up on secure, scalable...
 > etc.. do you think JSON is the way to go for stored / transmitted
 > messages?

No. One of my goals is effeciency - ie: I want to play with low bandwidth communication and so mail exchange between 2 systems needs to be as small as possible. Taking into account all the ideas of improved security and improved integrity, I'm going to be working at the bit level to squeeze out as many wasted bits as possible.

But, that said, if others create a JSON way to exchange mail, then I'll be able to adopt it too pretty easily (and happy to do so as well).

I actually dont think there is a single way forward and a new way of exchanging mail will only be one new way. I think the way forward is to support multiple distrubution techniques (until I guess there is mass adoption of one). So now that I can talk the old way, I'm up for creating new ways - and OK if there are more than one, and hopefully not break anything going forward.

 > I'm thinking if you're doing something and I'm doing something it'd be
 > good if those somethings could talk to each other :)

I'd like somebody to play with :) Playing alone is no fun at all :(


....лоеп
--- SBBSecho 3.14-Linux
 * Origin: I'm playing with ANSI+videotex - wanna play too? (21:2/116)

.