This one may fall outside of the scope of RSL, so consider this an RFC:

Right now all mail messaging is done completely internally via @username calls to the sqlite db. Would it be possible to implement site-to-site messaging using a username@site.domain format?

Thinking out loud: there could be a php script that accepted external POSTs from other RSL sites, which checks the postdata if username@localsite exists, and if it does, process the message like any normal mail?

--
Posted on Rocksolid Light

vga256 wrote:

> This one may fall outside of the scope of RSL, so consider this an RFC:

> Right now all mail messaging is done completely internally via @username calls to the sqlite db. Would it be possible to implement site-to-site messaging using a username@site.domain format?

> Thinking out loud: there could be a php script that accepted external POSTs from other RSL sites, which checks the postdata if username@localsite exists, and if it does, process the message like any normal mail?

This feature is something I've been preparing for for quite a while now.

Take a look at mail.php, line 215 and you will find the var $target (rcpt_target in db). This is already allowed for in the db, but everything right now is 'local'. The plan was to use this to determine 'where' the message should go.

My original plan was to send this encrypted using a group (rocksolid.data, rslight.data, just some group). It would be encrypted in that group and only readable on the target site.

The reason I wanted to use a group instead of direct transfer is that it would work over different networks. So a site only available in I2P could communicate with a clearnet site, etc.

The difficulty is security. Sites would need to be somewhat easy to configure, and hard to spoof.

If you look at the footer on news.novabbs.org, you'll see a link called rocksolidlight.rslight. If you click it you will get a public key. This is how I've been considering how to handle this. A site could collect these keys in some way, then mail sent could only be read by the site with the private key.

None of this is at all complete, but this has been my thinking on how to do this.

--
Retro Guy

On Mon, 17 Jul 2023 18:05:09 +0000
retro.guy@rocksolidbbs.com (Retro Guy) wrote:

> vga256 wrote:
>
> > This one may fall outside of the scope of RSL, so consider this an
> > RFC:
>
> > Right now all mail messaging is done completely internally via
> > @username calls to the sqlite db. Would it be possible to implement
> > site-to-site messaging using a username@site.domain format?
>
> > Thinking out loud: there could be a php script that accepted
> > external POSTs from other RSL sites, which checks the postdata if
> > username@localsite exists, and if it does, process the message like
> > any normal mail?
>
> This feature is something I've been preparing for for quite a while
> now.
>
> Take a look at mail.php, line 215 and you will find the var $target
> (rcpt_target in db). This is already allowed for in the db, but
> everything right now is 'local'. The plan was to use this to
> determine 'where' the message should go.
>
> My original plan was to send this encrypted using a group
> (rocksolid.data, rslight.data, just some group). It would be
> encrypted in that group and only readable on the target site.
>
> The reason I wanted to use a group instead of direct transfer is that
> it would work over different networks. So a site only available in
> I2P could communicate with a clearnet site, etc.
>
> The difficulty is security. Sites would need to be somewhat easy to
> configure, and hard to spoof.
>
> If you look at the footer on news.novabbs.org, you'll see a link
> called rocksolidlight.rslight. If you click it you will get a public
> key. This is how I've been considering how to handle this. A site
> could collect these keys in some way, then mail sent could only be
> read by the site with the private key.
>
> None of this is at all complete, but this has been my thinking on how
> to do this.
>

If doing site-to-site messaging both peers could use site keys (separate
from SSL) for each user. This would ensure that the sender can be
cryptographically verified as originating from the sending site. The
sending site would also sign each payload with its admin public key as
insurance against MITM. Even if SSL were not used it would be secure.

The site key for each user can be changed by the admin with a key
regeneration script. This would be useful in case of data corruption in
the keys store.

Note that such 'site keys' would be automatically handled internally by
Rocksolid Light and not presented directly to the user by default. The
user can employ any desired superencipherment prior to sending a
message.

--
SugarBug | https://sybershock.com

Syber Shock wrote:

> On Mon, 17 Jul 2023 18:05:09 +0000
> retro.guy@rocksolidbbs.com (Retro Guy) wrote:

>> vga256 wrote:
>>
>> > This one may fall outside of the scope of RSL, so consider this an
>> > RFC:
>>
>> > Right now all mail messaging is done completely internally via
>> > @username calls to the sqlite db. Would it be possible to implement
>> > site-to-site messaging using a username@site.domain format?
>>
>> > Thinking out loud: there could be a php script that accepted
>> > external POSTs from other RSL sites, which checks the postdata if
>> > username@localsite exists, and if it does, process the message like
>> > any normal mail?
>>
>> This feature is something I've been preparing for for quite a while
>> now.
>>
>> Take a look at mail.php, line 215 and you will find the var $target
>> (rcpt_target in db). This is already allowed for in the db, but
>> everything right now is 'local'. The plan was to use this to
>> determine 'where' the message should go.
>>
>> My original plan was to send this encrypted using a group
>> (rocksolid.data, rslight.data, just some group). It would be
>> encrypted in that group and only readable on the target site.
>>
>> The reason I wanted to use a group instead of direct transfer is that
>> it would work over different networks. So a site only available in
>> I2P could communicate with a clearnet site, etc.
>>
>> The difficulty is security. Sites would need to be somewhat easy to
>> configure, and hard to spoof.
>>
>> If you look at the footer on news.novabbs.org, you'll see a link
>> called rocksolidlight.rslight. If you click it you will get a public
>> key. This is how I've been considering how to handle this. A site
>> could collect these keys in some way, then mail sent could only be
>> read by the site with the private key.
>>
>> None of this is at all complete, but this has been my thinking on how
>> to do this.
>>

> If doing site-to-site messaging both peers could use site keys (separate
> from SSL) for each user. This would ensure that the sender can be
> cryptographically verified as originating from the sending site. The
> sending site would also sign each payload with its admin public key as
> insurance against MITM. Even if SSL were not used it would be secure.

This is my plan. The handling of sharing keys is something I have not yet
found the best solution. Manually excanging them is secure and good, but
it would be better if it could be somewhat automated. Then comes the issue
of spoofing a server, and we don't want that.

We must consider a user mailing to a site that the admin is not familiar
with. How do we handle that? Maybe all dest sites are '@domain', but the
server does not send to the 'doman', it uses it to fetch the key from a
db. If it doesn't have the key, the admin could go fetch it, or better
yet, rslight can go fetch it if at all possible.

Once servers have swapped keys, it should be pretty easy to get it working.

--
Retro Guy

fwiw, I'm reading everything in this thread with interest, just remaining silent as I have zero experience with cryptographic and anonymity practices.

once I have a sense for "this is how it needs to go, step by step", coding it is no problemo.

--
Posted on Rocksolid Light

On Tue, 18 Jul 2023 13:24:46 +0000
retro.guy@rocksolidbbs.com (Retro Guy) wrote:

> Syber Shock wrote:
>
> > On Mon, 17 Jul 2023 18:05:09 +0000
> > retro.guy@rocksolidbbs.com (Retro Guy) wrote:
>
> >> vga256 wrote:
> >>
> >> > This one may fall outside of the scope of RSL, so consider this
> >> > an RFC:
> >>
> >> > Right now all mail messaging is done completely internally via
> >> > @username calls to the sqlite db. Would it be possible to
> >> > implement site-to-site messaging using a username@site.domain
> >> > format?
> >>
> >> > Thinking out loud: there could be a php script that accepted
> >> > external POSTs from other RSL sites, which checks the postdata if
> >> > username@localsite exists, and if it does, process the message
> >> > like any normal mail?
> >>
> >> This feature is something I've been preparing for for quite a while
> >> now.
> >>
> >> Take a look at mail.php, line 215 and you will find the var $target
> >> (rcpt_target in db). This is already allowed for in the db, but
> >> everything right now is 'local'. The plan was to use this to
> >> determine 'where' the message should go.
> >>
> >> My original plan was to send this encrypted using a group
> >> (rocksolid.data, rslight.data, just some group). It would be
> >> encrypted in that group and only readable on the target site.
> >>
> >> The reason I wanted to use a group instead of direct transfer is
> >> that it would work over different networks. So a site only
> >> available in I2P could communicate with a clearnet site, etc.
> >>
> >> The difficulty is security. Sites would need to be somewhat easy to
> >> configure, and hard to spoof.
> >>
> >> If you look at the footer on news.novabbs.org, you'll see a link
> >> called rocksolidlight.rslight. If you click it you will get a
> >> public key. This is how I've been considering how to handle this.
> >> A site could collect these keys in some way, then mail sent could
> >> only be read by the site with the private key.
> >>
> >> None of this is at all complete, but this has been my thinking on
> >> how to do this.
> >>
>
> > If doing site-to-site messaging both peers could use site keys
> > (separate from SSL) for each user. This would ensure that the
> > sender can be cryptographically verified as originating from the
> > sending site. The sending site would also sign each payload with
> > its admin public key as insurance against MITM. Even if SSL were
> > not used it would be secure.
>
> This is my plan. The handling of sharing keys is something I have not
> yet found the best solution. Manually excanging them is secure and
> good, but it would be better if it could be somewhat automated. Then
> comes the issue of spoofing a server, and we don't want that.
>
> We must consider a user mailing to a site that the admin is not
> familiar with. How do we handle that? Maybe all dest sites are
> '@domain', but the server does not send to the 'doman', it uses it to
> fetch the key from a db. If it doesn't have the key, the admin could
> go fetch it, or better yet, rslight can go fetch it if at all
> possible.
>
> Once servers have swapped keys, it should be pretty easy to get it
> working.
>

Have you looked at NNCP? It's like UUCP on steroids. It is a kind of
Swiss army knife for peer-to-peer data exchanges. I tried to forward a
post about it but the server is rejecting it so here's a link:

https://www.complete.org/nncp/

--
SugarBug | https://sybershock.com

Syber Shock wrote:

> On Tue, 18 Jul 2023 13:24:46 +0000
> retro.guy@rocksolidbbs.com (Retro Guy) wrote:

>> Syber Shock wrote:
>>
>> > On Mon, 17 Jul 2023 18:05:09 +0000
>> > retro.guy@rocksolidbbs.com (Retro Guy) wrote:
>>
>> >> vga256 wrote:
>> >>
>> >> > This one may fall outside of the scope of RSL, so consider this
>> >> > an RFC:
>> >>
>> >> > Right now all mail messaging is done completely internally via
>> >> > @username calls to the sqlite db. Would it be possible to
>> >> > implement site-to-site messaging using a username@site.domain
>> >> > format?
>> >>
>> >> > Thinking out loud: there could be a php script that accepted
>> >> > external POSTs from other RSL sites, which checks the postdata if
>> >> > username@localsite exists, and if it does, process the message
>> >> > like any normal mail?
>> >>
>> >> This feature is something I've been preparing for for quite a while
>> >> now.
>> >>
>> >> Take a look at mail.php, line 215 and you will find the var $target
>> >> (rcpt_target in db). This is already allowed for in the db, but
>> >> everything right now is 'local'. The plan was to use this to
>> >> determine 'where' the message should go.
>> >>
>> >> My original plan was to send this encrypted using a group
>> >> (rocksolid.data, rslight.data, just some group). It would be
>> >> encrypted in that group and only readable on the target site.
>> >>
>> >> The reason I wanted to use a group instead of direct transfer is
>> >> that it would work over different networks. So a site only
>> >> available in I2P could communicate with a clearnet site, etc.
>> >>
>> >> The difficulty is security. Sites would need to be somewhat easy to
>> >> configure, and hard to spoof.
>> >>
>> >> If you look at the footer on news.novabbs.org, you'll see a link
>> >> called rocksolidlight.rslight. If you click it you will get a
>> >> public key. This is how I've been considering how to handle this.
>> >> A site could collect these keys in some way, then mail sent could
>> >> only be read by the site with the private key.
>> >>
>> >> None of this is at all complete, but this has been my thinking on
>> >> how to do this.
>> >>
>>
>> > If doing site-to-site messaging both peers could use site keys
>> > (separate from SSL) for each user. This would ensure that the
>> > sender can be cryptographically verified as originating from the
>> > sending site. The sending site would also sign each payload with
>> > its admin public key as insurance against MITM. Even if SSL were
>> > not used it would be secure.
>>
>> This is my plan. The handling of sharing keys is something I have not
>> yet found the best solution. Manually excanging them is secure and
>> good, but it would be better if it could be somewhat automated. Then
>> comes the issue of spoofing a server, and we don't want that.
>>
>> We must consider a user mailing to a site that the admin is not
>> familiar with. How do we handle that? Maybe all dest sites are
>> '@domain', but the server does not send to the 'doman', it uses it to
>> fetch the key from a db. If it doesn't have the key, the admin could
>> go fetch it, or better yet, rslight can go fetch it if at all
>> possible.
>>
>> Once servers have swapped keys, it should be pretty easy to get it
>> working.
>>

> Have you looked at NNCP? It's like UUCP on steroids. It is a kind of
> Swiss army knife for peer-to-peer data exchanges. I tried to forward a
> post about it but the server is rejecting it so here's a link:

> https://www.complete.org/nncp/

I've considered NNCP, but I'm still stuck on the idea of moving the
messages, or data, via a newsgroup. This would avoid the need to try
to connect separately to other servers as each server should already
be able to read a newsgroup. This of a signed/encrypted message similar
to a NoCeM message.

If I can't work that out, I'll consider something else, but for now
my brain is stuck on that idea :)

--
Retro Guy

> I've considered NNCP, but I'm still stuck on the idea of moving the
> messages, or data, via a newsgroup. This would avoid the need to try
> to connect separately to other servers as each server should already
> be able to read a newsgroup. This of a signed/encrypted message similar
> to a NoCeM message.

These are both very promising alternatives.

With the newsgroups approach, would this mean that all RSL servers carry a standard group called (say) rocksolid.messagingdata, which would contain all encrypted messages in the transmit queue? Does the server store-and-forward these messages to their final destination via server hops, or do servers direct-connect to swap messages via the group?

NNCP looks interesting. I've done some basic reading on it, and I'm trying to understand how it could be integrated. It looks like it would address the issue of poor or indirect connectivity, but because it is routing-agnostic, it would still require us to come up with our own routing system. As I understand it, this brings us back to what I think is the core problem: how exactly do we route private messages to unknown or unreachable systems? Via direct connections or indirect store-and-forward?

FWIW, I found this table very helpful: http://www.nncpgo.org/Comparison.html

FidoNet was one of my major influences in developing tomo. I'd like to do more reading on how its federated store-and-forward routing system works. As I understand it, it relies upon a hub-spoke arrangement, which isn't great. When I talked with Tom Jennings a few weeks ago, he implied that he had plans for a very different kind of decentralized routing system for it, but the project got out of his hands and became more centralized than he would have liked.

Anyway, food for thought!

--
Posted on Rocksolid Light

vga256 wrote:

> fwiw, I'm reading everything in this thread with interest, just remaining silent as I have zero experience with cryptographic and anonymity practices.

> once I have a sense for "this is how it needs to go, step by step", coding it is no problemo.

I think I now have a structure for remote Mail messages. It is based on NoCeM messages. This would be automated:

When a mail is sent to a remote system, the message is first signed with the source system private key, then encrypted with the destination system public key. This only happens if you specify a remote system (@something) in target user address.

The message is saved to your Mail folder (Sent), and the encrypted message is posted to the agreed upon newsgroup. I would suggest that rslight, tomo etc. installs use the same group for obvious reasons.

Just like with NoCeM messages, systems receiving the message would attempt to decrypt. I had originally planned a message header to show the target system, so as to not waste time trying to decrypt if not for you, but find this to be a security leak. Anyway, if you can decrypt it, it's for you, if not, ignore it.

Once decrypted, you have a signed message that you can check against the sending system. This is to avoid spoofing the sender. If the signature is good, and it matches the system it says it's from, then place the mail in the target user's mailbox and done.

The remaining task is to share keys. My thoughts atm are to use the newsgroup to maybe every 30 days upload your site key (automated by rslight). This allows other systems to know of your existence, and then they can either automated or manually verify that the key and data posted to the newsgoup match the actual site. If they do, they can add your key to their keyring.

Thoughts?

--
Retro Guy

vga256 wrote:

>> I've considered NNCP, but I'm still stuck on the idea of moving the
>> messages, or data, via a newsgroup. This would avoid the need to try
>> to connect separately to other servers as each server should already
>> be able to read a newsgroup. This of a signed/encrypted message similar
>> to a NoCeM message.

> These are both very promising alternatives.

> With the newsgroups approach, would this mean that all RSL servers carry a standard group called (say) rocksolid.messagingdata, which would contain all encrypted messages in the transmit queue? Does the server store-and-forward these messages to their final destination via server hops, or do servers direct-connect to swap messages via the group?

This would be a group that is agreed upon. Any group will do, as long as all the sites have access to it (it is peered well enough). Just like with a NoCeM group, you would list it in $config_dir/spoolnews/groups.txt and it would not be displayed to users, just used by the system.

> NNCP looks interesting. I've done some basic reading on it, and I'm trying to understand how it could be integrated. It looks like it would address the issue of poor or indirect connectivity, but because it is routing-agnostic, it would still require us to come up with our own routing system. As I understand it, this brings us back to what I think is the core problem: how exactly do we route private messages to unknown or unreachable systems? Via direct connections or indirect store-and-forward?

That is what leads me to using a newsgroup. We already communicate with eachothere (systems do) via newsgroups so why add another way to communicate such information?

> FidoNet was one of my major influences in developing tomo. I'd like to do more reading on how its federated store-and-forward routing system works. As I understand it, it relies upon a hub-spoke arrangement, which isn't great. When I talked with Tom Jennings a few weeks ago, he implied that he had plans for a very different kind of decentralized routing system for it, but the project got out of his hands and became more centralized than he would have liked.

I've used Fidonet in the past, and it works. But what I did not like is how I was dependent on my (sorry, can't remember the correct terminology) HUB, or the guy who I need to communicate with to get my node connected. For me anyway, it took months before he ever even replied to my emails to get set up. Being dependent on one node didn't sit too well with me.

I know it's not for technical reasons, but I eventually gave up on Fidonet due to the heavy bitching and moderation surrounding everything. (I didn't like the ppl much, lol).

--
Retro Guy

Retro Guy wrote:

> I know it's not for technical reasons, but I eventually gave up on Fidonet due to the heavy bitching and moderation surrounding everything. (I didn't like the ppl much, lol).

Lol, I'm still in the current Fidonet Nodelist. It has to be at least 15 years since I connected.

--
Retro Guy

> The message is saved to your Mail folder (Sent), and the encrypted message is posted to the agreed upon newsgroup. I would suggest that rslight, tomo etc. installs use the same group for obvious reasons.

Most definitely. Tomo will remain RSL-core compatible.

> Just like with NoCeM messages, systems receiving the message would attempt to decrypt. I had originally planned a message header to show the target system, so as to not waste time trying to decrypt if not for you, but find this to be a security leak. Anyway, if you can decrypt it, it's for you, if not, ignore it.

> Once decrypted, you have a signed message that you can check against the sending system. This is to avoid spoofing the sender. If the signature is good, and it matches the system it says it's from, then place the mail in the target user's mailbox and done.
> The remaining task is to share keys. My thoughts atm are to use the newsgroup to maybe every 30 days upload your site key (automated by rslight). This allows other systems to know of your existence, and then they can either automated or manually verify that the key and data posted to the newsgoup match the actual site. If they do, they can add your key to their keyring.

Thinking out loud here, so forgive me if I have some obvious misunderstandings of how cryptographic protocols work:

So as I understand it - the public keys are shared in the newsgroup monthly. Destination server hangs on to the key, and tries to decrypt all incoming messages from the group using the keys it has in its keychain.

Here's the part I don't quite understand - when we have say, 1000 keys, in the keychain, does the destination system try to decrypt each and every incoming private message using all 1000 keys? What happens when they are 10,000 keys and 10,000 messages?

Afterwards, does the destination server send a message-cancellation command to remove the now-received-and-verified message from rocksolid.messagedata?

--
Posted on Rocksolid Light

vga256 wrote:

>> Just like with NoCeM messages, systems receiving the message would attempt to decrypt. I had originally planned a message header to show the target system, so as to not waste time trying to decrypt if not for you, but find this to be a security leak. Anyway, if you can decrypt it, it's for you, if not, ignore it.

>> Once decrypted, you have a signed message that you can check against the sending system. This is to avoid spoofing the sender. If the signature is good, and it matches the system it says it's from, then place the mail in the target user's mailbox and done.
>> The remaining task is to share keys. My thoughts atm are to use the newsgroup to maybe every 30 days upload your site key (automated by rslight). This allows other systems to know of your existence, and then they can either automated or manually verify that the key and data posted to the newsgoup match the actual site. If they do, they can add your key to their keyring.

> Thinking out loud here, so forgive me if I have some obvious misunderstandings of how cryptographic protocols work:

> So as I understand it - the public keys are shared in the newsgroup monthly. Destination server hangs on to the key, and tries to decrypt all incoming messages from the group using the keys it has in its keychain.

> Here's the part I don't quite understand - when we have say, 1000 keys, in the keychain, does the destination system try to decrypt each and every incoming private message using all 1000 keys? What happens when they are 10,000 keys and 10,000 messages?

The destination only tries to decrypt with it's own private key. If the public key used to send matches their private key (it decrypts), then it's for that server. It does not try other keys, just the one.

> Afterwards, does the destination server send a message-cancellation command to remove the now-received-and-verified message from rocksolid.messagedata?

That could be done. Sort of like a NoCeM cancel? Not sure if it's necessary but it certainly is possible. Doing so would show what the target server was of the message, so I'm not sure it's a good idea. I would lean toward just expiring articles in that group more quickly than other groups. Once a message is posted, it really never goes away unless every single peer deletes it, as no peer is required to honor a cancel or NoCeM or any other delete message.

--
Retro Guy

Retro Guy wrote:

> Lol, I'm still in the current Fidonet Nodelist. It has to be at least 15 years since I connected.

Hahaha... tells you a lot about how healthy that network is now. I haven't connected to Fido/echomail in 25 years. I just liked the *idea* behind it more than anything else. How it turned out was a political/social disaster.

> The destination only tries to decrypt with it's own private key. If the public key used to send matches their private key (it decrypts), then it's for that server. It does not try other keys, just the one.

OHHHkay! That makes a lot of sense now. So no biggie - just a bunch of message checking/testing on one side.

> That could be done. Sort of like a NoCeM cancel? Not sure if it's necessary but it certainly is possible. Doing so would show what the target server was of the message, so I'm not sure it's a good idea. I would lean toward just expiring articles in that group more quickly than other groups. Once a message is posted, it really never goes away unless every single peer deletes it, as no peer is required to honor a cancel or NoCeM or any other delete message.

Yeah, that's exactly what I had in mind - NoCeM-based cancels. But what you pointed out makes a hell of a lot more sense, and it's easier to implement.

--
Posted on Rocksolid Light