@MSGID: 55057.sync@1:103/705 2d5d2f97
@REPLY: 51995.dove-syncdisc@12:1/2 2d5ccc5d
@TZUTC: -0700
@PID: Synchronet 3.21a-Linux master/88b423313 Sep 29
2025 GCC 12.2.0
@TID: SBBSecho 3.30-Linux master/88b423313 Sep 29
2025 GCC 12.2.0
@COLS: 80
@BBSID: VERT
@CHRS: CP437 2
@FORMAT: flowed
@NOTE: FSEditor.js v1.105
  Re: sbbsecho and bad packets
  By: deon to Digital Man on Tue Oct 21 2025 10:52 am

 >   Re: sbbsecho and bad packets
 >   By: Digital Man to deon on Mon Oct 20 2025 03:48 pm
 >
 > Hey DM,
 >
 >  > FWIW, Tom Jenning`s Fido software (specifically, unpmsg() from
 >  > unpacket.c) would`ve barfed on any message without a NUL-terminated
 >  > date/time as well.
 >  > https://www.sensitiveresearch.com/Archive/FidoNet/index.html
 >
 >  > It would would even trigger a buffer overflow (off-by-one) bug in his
 >  > code! Just something I came across that was probably related to this
 >  > discussion.
 >
 > Thanks, and interesting.
 >
 > I still contend that the "standard" doesnt reflect this, which doesnt make
 > sense (at least 2 me) on many levels. 

 The standard (FTS-1) only has that one definition of the DateTime
field in packets and it includes the (single) Null byte. So I don`t
think the requirement of the Null byte has really ever been ambiguous.

 Tom`s code would always generate the 19-char date followed by the
Null byte, but it was a bit more lenient on what it would accept (but
again, the Null byte what still a requirement). Whether that leniency on
the length of the date/time field was intentional or not, I don`t know.
But it was documented in FTS-1 years later as a field-length
null-terminated field.

 > (And yes, I think there are probably many other things that are not
 > following any "standards" anymore..)

 When it comes to FidoNet, what most matters is interoperability with
existing FTN software, much of it abandonware, not what any spec says. We
can debate what was meant by whatever spec, but in the end, we just
want our messages to go through and there to be some fault-tolerance
(e.g. recognize garbage from real messages) if at all possible.

 > Not sure what (Randy?) was thinking/intending in 1995. It certainly makes
 > sense that it might be probably easier to code as a null terminated string
 > and at the end of the day the most common representation of a date
 > "yyyy-mm-dd hh:mm:ss" or "dd MMM yy  hh:mm:ss" are both 19 chars, so being
 > fixed at 19 chars (to save that byte) may have worked as well. Actually,
 > saving the extra space before the time in the later format would have saved
 > another byte, (or converting it to an unsigned int probably would have saved
 > more). I guess by 1995, 2 bytes in a packet at those modem speeds wasnt a
 > big deal, especially since it was negligble once compressed into a zip/arj
 > file.

 I think the FTN packet (including packed-message) format is certainly
older than 1995. And the unfortumate DateTime format definitely was
originated by Tom Jennings (and he has some comments about regretting that
format in his source code).

 > Anyway, I think my code handles both in case it pops up in other ways...

 Good. My code assumes the DateTime is always fixed length (and null
terminated, though that is a bit illogical) and I don`t have any plans to
change that. :-)
-- 
                                            digital man (rob)

Synchronet/BBS Terminology Definition #17:
CR = Carriage Return (ASCII 13, Ctrl-M)
Norco, CA WX: 68.3°F, 49.0% humidity, 0 mph ENE wind, 0.00 inches rain/24hrs
--- SBBSecho 3.30-Linux
 * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
SEEN-BY: 50/109 103/705 154/10 218/700 221/1
240/1120 280/464 301/1 113
SEEN-BY: 341/66 463/68 712/848 5000/111 5001/100
5020/101 715 848 1042 4441
SEEN-BY: 5020/12000 5030/49 1081 5060/900 5061/133
5075/128 5083/444
@PATH: 103/705 301/1 5020/1042 4441