Subj : Re: Problem with legacy tosser (Squish) and Sync's MSGID
To : Marc Lewis
From : Rob Swindell
Date : Mon Dec 07 2020 08:07 pm
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.
>
> <On 07Dec2020 11:34 Rob Swindell (1:103/705) wrote a message to Marc Lewis
> 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
