Hello Rob!

02 Dec 20 14:54, Fred Riccio wrote to Rob Swindell:

Rob,

Would you be able to send a test NetMail to me? I'd like to see how Squish handles it on this end. Use whatever settings you use for
Marc.

Received your NetMail. Since it was sent routed I was unable to examine the packet header from your system. It probably doesn't come into play here anyway... Once I started digging I remembered something that didn't come to me as I wrote the last couple of messages here.

The packed message described in FTS-0001 has NO field for the zone, which leaves it up to the tosser to come up with it on its own while converting it to a locally stored message (in Squish's case FTS-0001 or FSP-1037). Your packed message had MSGID and INTL control lines, so there was sufficient information to come up with the correct zone (both source and destination). I have yet to dig into the stored message to determine if the correct zone number was put in the stored message header. I'll look at that tomorrow.

BTW, one odd thing I noticed that Squish did... The INTL kludge was dropped from the stored message (at least my message reader doesn't display it). That leaves only the MSGID to get the zone from.

FTS-0009 describes the MSGID kludge, saying it has 2 arguments, origaddr and serialno, not specifing anything about the format of the address except that it should be "a valid return address for the originating network". Is 19884@1:103/705 a valid address? I'm not going to judge you on that.

More tomorrow after I see what Squish stored.

--- Msged/NT 6.0.1
* Origin: Somewhere in New Hampshire's White Mountains (1:132/174)

Hello Marc!

01 Dec 20 14:29, Marc Lewis wrote to Fred Riccio:

One more thought... Was the NetMail sent direct or routed. That
makes a difference as far as the pkt address goes.

These mostly are direct to me or my system programs (SEAL, Areafix, Allfix, etc.).

Do messages to AreaFix work? Maybe it's TimEd that is getting confused with the zone. BTW, What stored message format is your NetMail in, Squish or SDM?

--- Msged/NT 6.0.1
* Origin: Somewhere in New Hampshire's White Mountains (1:132/174)

Re: RE: Problem with legacy tosser (Squish) and Sync's MSGID
By: Marc Lewis to Fred Riccio on Wed Dec 02 2020 06:42 pm

I REALLY don't think that Squish is at fault. NEVER had this kind of problem until they (Synchronet) stated adding those extraneous characters to that line.

As I already told you, Synchronet (actually, SBBSecho) only recently started even adding MSGIDs to FTN NetMail messages. "that line" didn't even exist in Synchronet-generated FTN NetMail messages before June of this year.

I am at a complete loss as to what to do. I've written to the author
of Synchronet, but he's adamant that Squish is wrong and his program isn't. Rubbish.

Not rubbish. I even offered to help patch the Squish source to fix it. Um... you're welcome?
--
digital man

Sling Blade quote #2:
Karl (re: killing Doyle): I hit him two good whacks in the head with it.
Norco, CA WX: 67.8øF, 14.0% humidity, 10 mph ESE wind, 0.00 inches rain/24hrs --- SBBSecho 3.11-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

02 Dec 20 10:17, you wrote to me:

AFAIK Squish supports FSC-0039 packets only and SSBSecho writes
FSC-0045 and FSC-0048 packets. Would this explain the problem?

SBBSecho can generate 4 flavors of type-2 packets: http://wiki.synchro.net/ref:fidonet_packets

Thanks for the clarification. So it's just a matter of configuring SBBSecho to use a compatible packet flavor for Squish (?)

* Origin: kakistocracy (2:280/464.47)

Re: Problem with legacy tosser (Squish) and Sync's MSGID
By: Oli to Rob Swindell on Thu Dec 03 2020 11:11 am

02 Dec 20 10:17, you wrote to me:

AFAIK Squish supports FSC-0039 packets only and SSBSecho writes
FSC-0045 and FSC-0048 packets. Would this explain the problem?

SBBSecho can generate 4 flavors of type-2 packets: http://wiki.synchro.net/ref:fidonet_packets

Thanks for the clarification. So it's just a matter of configuring SBBSecho to use a compatible packet flavor for Squish (?)

I doubt the packet format has anything to do with the reported problem, but it's worth a try, at least as an experiment. Looking at the Squish source would answer the question more definitively.
--
digital man

Rush quote #37:
Ignorance and prejudice and fear go hand in hand
Norco, CA WX: 66.5øF, 13.0% humidity, 7 mph WNW wind, 0.00 inches rain/24hrs --- SBBSecho 3.11-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: Problem with legacy tosser (Squish) and Sync's MSGID
By: Oli to Fred Riccio on Thu Dec 03 2020 05:18 pm

03 Dec 20 08:50, you wrote to Marc Lewis:

I REALLY don't think that Squish is at fault.

I think Squish is partially at fault. When messages tossed to *.Msg files, it leaves trash at offset B0 and B2 where the orig & dest zone should be. Same with ofs B4 & B6 where the point number should be.

The documentation in the Squish Developers Kit (Version 2.00) agrees:

Certain message systems, such as the FTSC-0001 *.MSG format,
do not store zone information with each message. When the
API encounters such a message and no zone is present, the
specified zone will be used instead. A 'def_zone' of 0
indicates that nothing is to be inferred about the zone
number of a message, and in that case, the API functions
will return 0 as the zone number for any message with an
unknown zone.

But FTS-0001 defines zone and point fields since 1989.

The zone and pont header fields only exist for "stored message" (.msg files) and packet headers. The packed message headers themselves do not have provisions for zone and point information. Instead, the zone and point can be found in the INTL/FMPT/TOPT kludges and the "Via" kludge lines (for NetMail), the INTL/FMPT/TOPT kludges being the "correct" method - also mentioned in FTS-1. I'm not sure when the INTL/FMPT/TOPT kludges were added to FTS-1, but it's certainly been a *long* time.
--
digital man

Rush quote #31:
Live for yourself, there's no one else more worth living for
Norco, CA WX: 66.6øF, 13.0% humidity, 8 mph NNE wind, 0.00 inches rain/24hrs --- SBBSecho 3.11-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: RE: Problem with legacy tosser (Squish) and Sync's MSGID
By: Marc Lewis to Digital Man on Tue Dec 01 2020 09:17 am

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...

So is the problem software Squish or NetMgr or both? From the more recent messages you posted, it seems the problem program is called "NetMgr".

Looking through the Squish and sqafix source code on github, I could not locate any inappropriate message-ID "origaddr" parsing (although I did find some in the Maximus source).
--
digital man

Synchronet "Real Fact" #39:
Synchronet first supported Windows NT v6.x (a.k.a. Vista/Win7) w/v3.14a (2006). Norco, CA WX: 69.7øF, 13.0% humidity, 5 mph E wind, 0.00 inches rain/24hrs
--- SBBSecho 3.11-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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...

So is the problem software Squish or NetMgr or both? From the more
recent messages you posted, it seems the problem program is called "NetMgr".

Looking through the Squish and sqafix source code on github, I
could not locate any inappropriate message-ID "origaddr" parsing
(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.

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.

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?

Best regards,
Marc

--- timEd/2 1.10.y2k+
* Origin: Sursum Corda! BBS-Huntsville,AL-bbs.sursum-corda.com (1:396/45)

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...

So is the problem software Squish or NetMgr or both? From the more recent messages you posted, it seems the problem program is called "NetMgr".

Looking through the Squish and sqafix source code on github, I
could not locate any inappropriate message-ID "origaddr" parsing (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)