TZUTC: -0800   
   MSGID: 1901.tub@1:103/705 24343987   
   REPLY: 1:396/45.0 fcef4bb1   
   PID: Synchronet 3.18c-Win32  Nov 30 2020 MSC 1927   
   TID: SBBSecho 3.11-Linux r3.179 Nov 30 2020 GCC 8.3.0   
   COLS: 80   
   CHRS: CP437 2   
   NOTE: FSEditor.js v1.104   
     Re: Re: Problem with legacy tosser (Squish) and Sync's MSGID   
     By: Marc Lewis to Rob Swindell on Mon Dec 07 2020 09:36 pm   
      
    > Hello Rob.   
    >   
    >  regarding RE: Problem with legacy tosser (Squish) and Sync's MSGID >   
    >   
    >   
    >  > Synchronet's NetMail messages are the ONLY ones that cause Squish to go   
    >  > nuts... In fact, only a couple years ago or so, Squish had zero problems   
    >  > with NetMail messages from Synchronet...   
    >   
    >  RS> So is the problem software Squish or NetMgr or both? From the more   
    >  RS> recent messages you posted, it seems the problem program is called   
    >  RS> "NetMgr".   
    >   
    >  RS> Looking through the Squish and sqafix source code on github, I   
    >  RS> could not locate any inappropriate message-ID "origaddr" parsing   
    >  RS> (although I did find some in the Maximus source).   
    >   
    > Rob, the way my system works is Squish first tosses stuff to the appropriate   
    > directory.  In the case of NetMail it goes into the NetMail directory.   
    > NetMgr then reads the message(s) and checks its destination Node number   
    > against the current NodeList. Messages bound for an unlisted address (NOT   
    > including the Point address) are bounced. So, it comes into play after   
    > Squish has done it's thing.   
      
   So then Squish is likely handling the NetMail messages correctly (?). You   
   could send one of the NetMail messages (.msg files) my way for a look-see or   
   use a tool, such as fmsgdump.exe to dump the message header and kludge/control   
   lines and paste those here. But I suspect there's no incompatibility with   
   Squish involved here.   
      
    > One thing I'm going to do as a test, is convert the NetMail area to Squish   
    > format. Not sure how the attendant programs that work on NetMail messages   
    > will react, but I'm going to give it a shot.   
      
   Or just get rid of NetMgr as it appears to be the program that is trying to   
   parse the MSGID's. (?).   
      
    > I'm going to as another question relative to the actual @MSGID line that   
    > Synchronet generates.  Since it contains a message number and an @ symbol   
    > with no spaces, what would happen if you separated the ####@ from the rest   
    > of the line with a space?   
      
   Then the MSGID would be 3 fields, separated by spaces. I tried that once and   
   got a lot of flack on FidoNet about it and indeed: the spec is 2   
   space-separated fields with the second/last field being 8 hexadecimal digits.   
   That's it. So I complied.   
   --    
                                               digital man   
      
   Synchronet/BBS Terminology Definition #43:   
   IMAP = Internet Message Access Protocol   
   Norco, CA WX: 68.9øF, 13.0% humidity, 0 mph SSW wind, 0.00 inches rain/24hrs   
   --- SBBSecho 3.11-Linux   
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)   
   SEEN-BY: 1/19 123 10/0 1 15/0 16/0 18/200 19/36 90/1 102/401 103/705   
   SEEN-BY: 105/81 106/201 116/18 120/340 123/130 131 140 124/5016 132/174   
   SEEN-BY: 153/7715 154/10 203/0 214/22 218/0 1 401 410 700 720 802   
   SEEN-BY: 218/820 840 221/0 1 222/2 226/30 227/114 702 229/101 424   
   SEEN-BY: 229/426 550 664 1016 230/0 150 152 240/1120 5832 249/110   
   SEEN-BY: 249/206 317 400 250/1 261/38 100 1466 266/512 267/155 275/100   
   SEEN-BY: 280/464 5003 282/1031 1056 291/100 111 292/854 8125 317/3   
   SEEN-BY: 320/119 219 319 322/0 757 340/400 341/66 342/200 396/45 633/280   
   SEEN-BY: 640/1321 712/848 801/161 189 2320/105 3634/12 5020/715 1042   
   PATH: 103/705 218/700 261/38 320/219 203/0 280/464 229/101 426