https://gitlab.synchro.net/main/sbbs/-/commit/c5addbdc2fd644cff1f3e654
Modified Files:
src/sbbs3/sbbsecho.c sbbsecho.h
Log Message:
Strip Ctrl-A codes from exported NetMail messages

Ctrl-A codes aren't FidoNet-friendly. Though we've long stripped them from exported echomail messages, they weren't being stripped from exported netmail.

Increment version to 3.30

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

https://gitlab.synchro.net/main/sbbs/-/commit/fe2d6930583d7961596c3e1c
Modified Files:
src/sbbs3/sbbsecho.c sbbsecho.h
Log Message:
Don't write empty PATH: control line to exported echomail message

Points don't normally have any addresses to add to the PATH: line, so
(as was pointed out in the FIDOTEST echo), an empty PATH: line would be included in exported echomail messages from points.

Although this isn't a violation of FTS-4, it is a violation of its proposed successor: FSC-74:

"Blank" path lines shall not be transmitted

And this caused a duplicate PATH: line to be added by FMail when processing such messages.

This change also eliminates possibility of adding "\r\x01PATH:" not
followed by space (ASCII 32) character, which was also a violation of FSC-74.

I resisted the urge to clean-up this crufty bit of code here and made this commit the minimal necessary change.

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

https://gitlab.synchro.net/main/sbbs/-/commit/ffcb56c0e13b5a147c109557
Modified Files:
src/sbbs3/sbbsecho.c sbbsecho.h
Log Message:
REQ files aren't supposed to be listed in flow files

Per FTS-5005:

4.1 File request files are named using the same method as flow
files, with an extension of req. The format of request files
is documented in FTS-0006. File requests have no flavour on
their own. They DO NOT initiate a poll to the remote system,
and must be accompanied by a [reduced] flow file.

I'm not sure why "reduced" is in brackets here (implying optional?) but apparently accompanying a .req file with a full/normal FLO entry causes duplicate requests/replies as reported recently by Dan (Gamgee @ PALANTIR).

Incremented version to 3.34.

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

https://gitlab.synchro.net/main/sbbs/-/commit/eebfd74ddc924e1e98c2b159
Modified Files:
src/sbbs3/sbbsecho.c sbbsecho.h
Log Message:
Unpack bundles starting from 6 weekdays ago, not (always) Sunday

There was a conversation in the SYNCHRONET echo/conference about message
import ordering and it occurred to me that SBBSecho shouldn't always start the bundle search/unpack with Sunday (*.SU?) as we might import bundles out of order if multiple bundles spanning multiple days came in at once (or were collected over time without running SBBSecho import). Of course, the whole
"day of week" naming scheme doesn't work very well if the link is in a different time zone, but this is no less accurate than just always starting the search from Sunday (*.SU*) and will usually be more "chronologically" accurate.

Using UTC to determine the current "day of week" for creating and consuming bundles would be more deterministic, but alas, it's not how things have been done (anyone have a document/reference for the origination of the defacto bundle naming scheme?).

FSC-23 refers to this scheme as "Day-of-week bullshit", and I have to agree. UTC Day of year would've been a much better chronological and sequential
naming scheme, but I think some systems were sensistive to the size of bundles and packets and needed them split-up and the DOS 8.3 filename limitation had
to be designed around.

One solution is to just always transfer packets and never bundles since packets are usually unambiguously and sequentially named (SBBSecho supports this just fine).

Increment version to 3.35

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

https://gitlab.synchro.net/main/sbbs/-/commit/96b077d3cc75e4bdc13b6bf4
Modified Files:
src/sbbs3/sbbsecho.c sbbsecho.h
Log Message:
Treat the *last* (not first) tear line as the divider between body and tail

I was reading some echomail and noticed a message that wasn't word-wrapped.
I thought that was odd, so I looked at the (SMB) header of the message and
it indicated that the *entire* message was the *tail* of the message (it had no body text):
data_field[0] TEXT_TAIL, offset 0, length 641

Looking at the message itself made it obvious to me what had happened: the original message started with a sort of quote indicator, like this (but with no indentation):
--- Original Message ---

SBBSecho saw that leading "--- " as a tear line and imported the remainder of the message text as the message tail. Message tails are not word-wrapped when displayed in SBBS, which was my initial clue that something was amiss.

Now when adding the parsing of the "last" tear line to fmsgtosmsg(), I noticed that there was some handling of the possibility of linefeeds in the imported message text. That was going to complicate my "next" tear line parsing (I'd have to search for all permuations with both CR and CRLF). But that got me wondering: why is getfmsg() returning a buffer with linefeeds in it?
(they're supposed to be ignored, per FidoNet's oldest standard, FTS-1)

So when looking at getfmsg(), I decided I could both add the linefeed ignore/ strip there and improve it as well: getfmsg() no longer reads and seeks and reads again. The logic is now simplier and there's less file I/O (it's a stream so likely it was just dealing with memory anyway), but I thought it best to mostly rewrite getfmsg(). Now everywhere getfmsg() is used in SBBSecho doesn't need to be concerned with the possibility of there being LFs in the message text: there cannot be.

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