TZUTC: -0800   
   MSGID: 54310.syncprog@1:103/705 2de4e7d5   
   PID: Synchronet 3.21b-Linux master/5c73d262c Jan 21 2026 GCC 12.2.0   
   TID: SBBSecho 3.35-Linux master/0bc7b3297 Jan 31 2026 GCC 12.2.0   
   BBSID: VERT   
   CHRS: ASCII 1   
   FORMAT: flowed   
   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.   
   --- SBBSecho 3.35-Linux   
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)   
   SEEN-BY: 103/705 105/81 106/201 124/5016 128/187 129/14 153/757 7715   
   SEEN-BY: 154/10 30 110 203/0 218/700 221/0 226/30 227/114 229/110   
   SEEN-BY: 229/134 206 317 400 426 428 470 700 705 240/1120 5832 263/1   
   SEEN-BY: 266/512 280/464 5003 5006 291/111 292/8125 301/1 320/219   
   SEEN-BY: 322/757 341/66 234 342/200 396/45 423/120 460/58 256 1124   
   SEEN-BY: 633/280 712/848 770/1 902/26 5020/400 8912 5054/30 5075/35   
   PATH: 103/705 280/464 460/58 229/426