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
|
