https://gitlab.synchro.net/main/sbbs/-/commit/6fb20b919003c805a40c207c
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Resolve signed/unsigned compare warning with MSVC

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/ccfad124e104b09bf825392e
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
More consistent 'exact' parameter values to findnodecfg() - e.g. false, not 0

No functional change.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/15b230af547ff5932c6073e5
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Rework NetMail routing logic to handle point destinations better

With this commmit, the logic is now:

If the NetMail destination is a point and there's no linked-node for it
and the boss node for this point is not one of our AKAs
then route to the boss node (no linked-node match needed)
if the boss node matches a linked-node with a route configuration
then route to that configured route destination (2-levels of routing
and thus 2 "Routing NetMail" msgs will be logged in this scenario)

If the NetMail destination is a point and there is a linked-node for it
then the netmail will not be routed
unless that linked node has a route configuration

NetMail destined for non-points are treated the same as before this
commit.

No change in the routing of echomail for points.

I think this change fixes issue #520 which can be traced back to commit 45ced2a3b for poindexter FORTRAN (REALITY), 2 years ago almost to the
day, where that change added point->boss routing, but only if the boss
had a matching linked-node configuration (for both echomail and
netmail).

This commit also re-thinks commit ffe69b43623d (for Alterego) which
would not route a point netmail if any our local AKAs matched the
destination address, igorining the point value. I think what was
intended here (I coudln't locate the original enhancmenet request or
issue), was to not route if a local AKA was the *boss* of the point.
And with this commit, that's now how it now works.

As before, "test results appreciated".

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

Re: src/sbbs3/sbbsecho.c
By: Rob Swindell (on ChromeOS) to Git commit to main/sbbs/master on Sat Feb 18 2023 12:59 pm

As before, "test results appreciated".

Thanks for doing this. I'm relying on the nightlies, so I'll download them tomorrow and test.
---
þ Synchronet þ .: realitycheckbbs.org :: scientia potentia est :.

https://gitlab.synchro.net/main/sbbs/-/commit/227e2f4986eb0b04c05cc6ea
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Stop classifying msgs for unknown areas as security violations

When Secure EchoMail is enabled and a Bad Echo Area (*) is defined in the
area file (areas.bbs), but the packet source address is *not* listed as a
link to the Bad Echo Area (tag: *) in areas.bbs, any messages for unknown
areas in such a packet would cause the pkt to be considered a bad packet
with a security violation. Instead, the message should just be skipped.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/b185201161cd35dea8273d84
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Strip the "in-transit" attribute flag from imported packed-messages

Log a warning message when either the "local" or "in-transit" flag has been stripped from ("Sanitized") imported packed-messages.

Keyop reported a chksmb warning on a FidoNet message that contained the 'in-transit' attribute:
<Keyop> Message flagged as 'In Transit' (?): 1
<Keyop> fidonet_fidosoft Message Base has Errors!

The message in question appears just to be a corrupted echomail msg coming
from HPT:
Sender '56:43 '
To Tommi Koivula
Subject test
X-FTN-AREA FIDOSOFT.HUSKY
X-FTN-TID hpt/os2-wc 1.9.0-cur 2021-03-14

SBBSecho didn't use to convert/import the "in-transit" flag on imported
netmail or echomail messages, ... until commit 446ab0ef7e09e5c61cf, which
was needed to support the TickFix robot. So now, let's just sanitize the packed-message attributes a little sooner in the import process and log a warning when such sanitization has taken place.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/d6eadf369e7ed75248b1819c
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Truncate trailing whitespace from FidoNet message header fields

It's unclear whether trailing whitespace is supposed to be significant or not (FidoNet specs don't say), but I don't see any reason why "John Doe" and
"John Doe " should be considered unique senders or recipients. Remove any trailing whitespace from message subjects too.

This change makes the trailing whitespace truncation in SMB hash functions unnecessary (at least for SBBSecho-imported messages), but most (all?) other message transports don't allow for this nonsense in the first place.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net