https://gitlab.synchro.net/main/sbbs/-/commit/c4b6a79d6f3a6b217cb87a1b
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Add subject.can (Subject filter file) support

For Trikester (DOVEMOD/BSMNTQQ)
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/e530a12cf6268ef9ab47f36c
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Fix CID 174355: Big parameter passed by value
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/726223ee8d8a7dde927fc833
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
For sub-boards configured to export "ASCII Only", convert UTF-8 correctly

This converts the body text as well as the to, from, and subject header
fields (first to CP437, then to ASCII).

This should address the issue raised in issue #386 with exporting UTF-8 sequences to some message networks.
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/bf3da76e32fbc8cd7785fa1f
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Resolve GCC warnings

Fixes isue #388 - no change in behavior
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

On 4/3/22 16:51, Rob Swindell wrote:

https://gitlab.synchro.net/main/sbbs/-/commit/726223ee8d8a7dde927fc833 Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
For sub-boards configured to export "ASCII Only", convert UTF-8 correctly

This converts the body text as well as the to, from, and subject header fields (first to CP437, then to ASCII).

This should address the issue raised in issue #386 with exporting UTF-8 sequences to some message networks.

Maybe adding a "CP437/DOS Only" option? Not sure what the underlying
value is though.
--
Michael J. Ryan - tracker1@roughneckbbs.com
---
þ Synchronet þ Roughneck BBS - roughneckbbs.com

https://gitlab.synchro.net/main/sbbs/-/commit/414d34ec8bc2c13601ce476a
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Fix packet filename in "Gruned message" log entry on Win32

e.g. "Grunged message (type 2) from 4:80/1 at offset 58 in packet: (null)"

off_t is 64-bit, but long in 32-bit (on Win32), so needs a typecast here in lprintf() call (otherwise, the upper 4 bytes of the offset are interpreted
as the string address for the corresponding '%s' argument, the filename).
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/2962e4a5bf733e4b0c3869c4
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Fix segfault when printing Bad-echo name after failing to load cfg

This is a weird one: sbbsecho ran right as I was saving msgs.cnf via
SCFG and it seems like it loaded 0-byte msgs.cnf into memory and this
segfault was a result of trying to print sub[INVALID_SUB]->code.

The use of [f]nopen() with proper share perms should have prevented this (truncated msgs.cnf read) from happening, so there's something else afoot here. ---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

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

https://gitlab.synchro.net/main/sbbs/-/commit/e76fafaae4580941b343253b
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Fix type 2.2 packet header generation

As reported by Deon on DOVE-Net: type 2.2 packet generation was not (since SBBSecho v3.0) setting the origin and destination point values correctly:
was leaving the packet type 2.0 date values in these fields.

Also, zero-out the reserved bytes in the type 2.2 packet header (don't leave the type 2.0 date values in there).

Thanks for the report Deon!
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/68df9812f31add3f94430d77
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Always delete the AREASxxxxxx temp file

When there are no changes (areas added or removed) via an areafix message, the data/AREASxxxxxx temp file would be left behind. The file was only removed if areas were added or removed from the area file via areafix message.

The orphaned data/AREASxxxxxxx files were reported via DOVE-Net by Gamgee (PALANTIR)
If you have these stale files, you can safely delete them.
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/f9b0dda5a1cac371a50f9f3f
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Add more detail (e.g. line number) to various "error opening" log msgs

Some of the errors could be pretty vague since they looked the same and
we were depending on the path/file attempted to be opened in the log msg
to clue us into what exactly was being attempted. But some of these file
paths are sysop-configurable, and they can put unexpected things in there
that make it difficult to determine exactly what file was trying to be
opened and for what purpose. This should help a little bit.
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/0f0a8a1ae72c424509eaa72d
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Refactor the function: unpack_bundle()

1. When a 0-length bundle file was encountered or an unpacking error occurred,
any remaining bundles for the current search day-of-week (e.g. *.SU*) would
be skipped/ignored. This bug (issue #764, regarding the 0-length file part),
is fixed by not incrementing the day-of-week index in the main loop, but
rather only incremeting the index when all bundles for the current
day-of-week have been processed.
2. The age calculation for 0-byte/length bundle files was incorrect, so all
0-length bundle files would always be considered "less than 24-hours old"
(and thus, never auto-deleted).
This exacerbated the problem of issue #764 since it would persist until the
0-length files were manually deleted. Fixed the file age calculation and
now logging the date/timestamp of the 0-length file as well.
3. Don't do the switch/case/sprintf dance when we're not re-running a glob()
search.
4. Replace the switch/case statement with an array of week day names/patterns. 5. Ignore (with a warning log message) any sub-directories of the inbound
directory that happen to match the bundle file search pattern.
6. Use better variable naming.
7. Refer to files with a length of 0 as "0-length" instead of "0-byte" in log
messages.
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/6177a1c02241acc45a1b0858
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Fix potential null pointer dereference

strListReadFile() can return NULL upon error
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/3bcc0d624061d1833c15ecbf
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
If the area file is configured to be blank, don't try to open/read
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/faf0f4d29ca57bdcc0d130c5
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Fix handling of .msg files from IBBS doors.

IBBS doors configured for Binkley style outbound will put the
binkley directives in the subject, expecting them to pass through
to the FLO file.

SBBSEcho v2 and v3 since a3b2f9e2d have stripped the "delete file"
indication ('^') and generated an error, refusing to send messages
with #, ~, -, !, and @.

This changes the behaviour to translate '-' to '^', '!' to '~', and
strip '@', and keep the prefix that was in the .msg file.

This fixes the issue where outbound files from IBBS games configured
for Binkley style outbound would never get deleted.

Note that in this implementation, the prefix overrides the configured truncation value and any "FLAGS KFL" kludge lines.
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/377ac0563666ae3852f33cef
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Fix last commit to not include the prefix when validating the filename

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

https://gitlab.synchro.net/main/sbbs/-/commit/aa7a1b6505417cfcdcc8530b
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Previous "fix" actually broke more than it fixed.

I wouldn't call me a real developer.
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/3b527199322f25832617f964
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Fix potential buffer overflow in fmsgattr_str()

Pass it 0xffff and it overflows its local (static) string buffer.
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/41e2191514f2a45fe862b6b4
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Replace import_netmail() magic constansts with (expanded) IMPORT_* enum values

The only really important values (other than for debug-logging reasons) are
0 (success) and IMPORT_CLOSED (was -2).

One functional change included here: when fmsgtosmsg returned non-zero values, import_netmail() would log the value and still return 0 (success). This will result in more debug-level log msgs when fmsgtosmsg() returns an error value, but that's all.

The logged import_netmail() error numbers *are* changed by this commit.
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/d5b59539e7e688f57ce3c43e
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Implement Deuce's suggested fix for importing netmail messages (.msg files)

... for robots.

I thought he said he was importing packets, but in any case, we don't want to be deleting a .msg file destined for a configured robot.
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/e7b93ae3f3f8dfb24d450f1c
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Clean up import_netmail()

- No longer use special return value (IMPORT_CLOSED) to indicate the .msg
file was closed. Now we just set the FILE* to NULL if it was closed and
return IMPORT_SUCCESS.
- No longer deletes the .msg file here; expect the caller (main()) to do that. - Update the message header here (e.g. adding "RECEIVED" attribute flag),
when appropriate. Sometimes this was added here, sometimes in the main(),
and in some cases it should not have been added (e.g. for ignored and
filtered netmail messages) but it was anyway.
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/5b21df6e401a7b3071c44f8b
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Fix typo in previous commit

Weird that it compiled without warning. I didn't try linking it, so that's why it wasn't caught.
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/f8a33572e1e6fe5ac9887856
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Remove direct printf() calls from import_netmail()

... direct all output through lprintf() instead.

This insures that the helpful output may always be logged to the sbbsecho.log file and the sysop need not view the stdout to find out why a netmail message was ignored or discarded or otherwise problematic.

It appeared there may have been redundant output to stdout before anyway and trying to keep both the stdout and the log output both helpful and beautified was getting tedius.

Most sysops don't look at the console/stdout of sbbsecho when it runs and we normally expect a sysop to be able to use the sbbsecho.log file to debug any issues (possibly after increasing their log level to DEBUG).

Include the netmail message attributes value (both in hex and verbose form)
in the information logged about an incoming netmail message.
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/e69955e0e7e951634ad90f48
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Replace integer constants 0 and 1 with values of appropriate type (e.g. bool)

Code clean-up, no functional change.
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/241bd37f9feb34506c3b295d
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Better logging around area list file open failures

This also fixes the empty "Title" key/valiue lines in the echostats.ini file. ---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

Re: Re: src/sbbs3/sbbsecho.c
By: Gamgee to MRO on Tue Feb 04 2025 06:41 pm

MRO wrote to k9zw <=-

Alas my system merged this in another echo... puzzling how at the
moment... appreciate the reply!

put your data files in their own sub directory for each msg network
you have.

That isn't necessary and certainly is not the default way.

But it does keep the directories a little tidier.

... Remember how simple life was when there were only two sexes?

---
þ Synchronet þ the Outwest BBS - outwest.synchro.net - Home of BBSBASE 6.0

https://gitlab.synchro.net/main/sbbs/-/commit/9c4557e96766bb7e6b73edf4
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Fix a couple more new-GCC warnings

using gcc (GCC) 15.2.1 20260209 "assignment discards const qualifier"

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