* Copied (from: SYNC_PROGRAMMING) by Marc Lewis using timEd/2 1.10.y2k+.

If anyone here in TUB echo has any ideas relative to this, please let us know.

-Marc

Re: Problem with legacy tosser (Squish) and Sync's MSGID
By: Marc Lewis to Rob Swintell on Mon Nov 30 2020 09:35 pm

Hello Rob.

Of late, my old Squish tosser (OS/2) is having an insurmountable problem with NetMails containing data other than the Node number and the time/date code. Here is an example:

-o-o-o-o-o-o-o-o-CUT-o-o-o-o-o-o-o-o-o-
Date : Thu Nov 12, 16:04 25 pvt rcv From : Nigel Reed 7205:124/5016
To : areafix 7205:396/45
Subj : xxxxxxxx
============================================================ =================== =
TZUTC: -0600
MSGID: 7205@1:124/5016 24130381

-o-o-o-o-o-o-o-o-CUT-o-o-o-o-o-o-o-o-o-

That apparent message number followed by the @ symbol in the MSGID line completely throws Squish for a loop as far as the Zone number is
concerned.
Both the from and to address are Zone 1 addresses but for some
reason Squish
cannot fathom the xxxx@ in the MSGID line.

Is there anything that can be done to correct this? Maybe omitting the apparent message number or some kind of spacing? I am not any kind of programmer so I cannot give any suggestions. I can only say that it
is ONLY
messages coming from a Synchronet system that causes this problem and ONLY when it is NetMail. Echomail is unaffected apparently.

I am at a complete loss. Your help will be very much appreciated!

It sounds like Squish is trying to parse the source address from the MSGID? It definitely should not be doing that. Squish is open source, do you have the means to recompile it if somewhere were to supply a source code fix/patch for it?
--
digital man

Synchronet "Real Fact" #17:
"Vertrauen" (ver-trow-en) translates to "trust" in German, and was a band name.
Norco, CA WX: 64.1øF, 20.0% humidity, 2 mph WSW wind, 0.00 inches rain/24hrs --- SBBSecho 3.11-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

* Copied (from: SYNC_PROGRAMMING) by Marc Lewis using timEd/2 1.10.y2k+.

Hello Digital.

<On 30Nov2020 20:04 Digital Man (1:103/705) wrote a message to Marc Lewis regarding Problem with legacy tosser (Squish) and Sync's MSGID >

Of late, my old Squish tosser (OS/2) is having an insurmountable problem with NetMails containing data other than the Node number and the time/date code. Here is an example:

[snip]

That apparent message number followed by the @ symbol in the MSGID line completely throws Squish for a loop as far as the Zone number is
concerned. Both the from and to address are Zone 1 addresses but for
some reason Squish cannot fathom the xxxx@ in the MSGID line.

[snip]

I am at a complete loss. Your help will be very much appreciated!

It sounds like Squish is trying to parse the source address from
the MSGID? It definitely should not be doing that. Squish is open
source, do you have the means to recompile it if somewhere were to
supply a source code fix/patch for it?

First, thanks for taking a look at my message and for your suggestion. I would indeed be interested in a re-compilation of the Squish executable, but have absolutely no method of accomplishing that. I should note that on occasion I run the DOS version of the executable (though not very often) so both the OS/2 and the DOS versions would need to be re-compiled.

Next I need to ask about the @MSGID line itself. (I am still digging to find the FidoNet technical spec that covers it.) I was told *years* back that the only thing that was supposed to be in that line were the originating Node number and the hex date/time code - nothing else. Perhaps the person telling me this (long deceased) may have misinterpreted something... So let me ask you; what's the spec for that line?

As I mentioned before, and there's absolutely no disrespect intended, 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... Until the apparent message numbers started appearing in that line. What prompted the change in that line's format?

Also, if there's someone you know of that can re-compile Squish's executable with the recommended changes, please let me know. If you prefer to do it outside of EchoMail, e-mail me at marc.lewis@sursum-corda.com or marc.w@marclewis.org.

Many thanks.

Best regards,
Marc

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

Hello Marc!

01 Dec 20 09:17, Marc Lewis wrote to Digital Man:

Of late, my old Squish tosser (OS/2) is having an insurmountable
problem with NetMails containing data other than the Node number and the
time/date code.

The standard that describes MSGID is FTS-0009.001

Squish *can* use MSGID to do dupe checking, but it doesn't have to. Check the DupeCheck keyword in Squish.Cfg, does it say MSGID, HEADER, or both? You could try using only HEADER to see what happens.

AFAIK, squish computes the CRC32 of everything in the MSGID line that comes after the colon, and uses it for dupe checking. It shouldn't be trying to parse it.

If for some reason Squish is trying to get the origin address from thr MSGID line, check the pkt to see if the zone is in the header. It could be getting confused because of all the different packet header versions. Maybe Sync is using an unknown (to squish) header format and it can't find the zone, so it goes looking in other places.

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

01 Dec 20 13:15, you wrote to Marc Lewis:

AFAIK, squish computes the CRC32 of everything in the MSGID line that comes after the colon, and uses it for dupe checking. It shouldn't be trying to parse it.

I believe that's correct and Squish doesn't parse the MSGID line. If it is parsing the MSGID, it should be somewhere in the sources and should be easy to fix...

If for some reason Squish is trying to get the origin address from thr MSGID line, check the pkt to see if the zone is in the header. It
could be getting confused because of all the different packet header versions. Maybe Sync is using an unknown (to squish) header format
and it can't find the zone, so it goes looking in other places.

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

* Origin: kakistocracy (2:280/464.47)

Hello Oli!

01 Dec 20 20:21, Oli wrote to Fred Riccio:

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

It could be. If I remember correctly, the major difference is the offset of the zone and/or point portion of both destination and source addresses. This *could* force a tosser to look in alternate locations (ie the MSGID or INTL kludges) for them.

I believe Squish supports more than just one 'pkt type, but as I look through my logs for 2020, all I see incoming is type 2+ packets.

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

Hello Marc!

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

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

Hello Fred.

<On 01Dec2020 14:50 Fred Riccio (1:132/174) wrote a message to Marc Lewis regarding Re: Problem with legacy tosser (Squish) and Sync's MSGID >

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

Best regards,
Marc

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

Hello Fred.

<On 01Dec2020 13:15 Fred Riccio (1:132/174) wrote a message to Marc Lewis regarding Re: Problem with legacy tosser (Squish) and Sync's MSGID >

01 Dec 20 09:17, Marc Lewis wrote to Digital Man:

Of late, my old Squish tosser (OS/2) is having an insurmountable
problem with NetMails containing data other than the Node number and the
time/date code.

The standard that describes MSGID is FTS-0009.001

Squish *can* use MSGID to do dupe checking, but it doesn't have to.
Check the DupeCheck keyword in Squish.Cfg, does it say MSGID,
HEADER, or both? You could try using only HEADER to see what
happens.

Okay, I've changed the DupeCheck line to read HEADER.

I've asked one of the Nodes that feeds off me to send a NetMail to me to see what happens.

Best regards,
Marc

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

Re: Problem with legacy tosser (Squish) and Sync's MSGID
By: Oli to Fred Riccio on Tue Dec 01 2020 08:21 pm

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
--
digital man

This Is Spinal Tap quote #37:
David St. Hubbins: We are Spinal Tap from the UK - you must be the USA!
Norco, CA WX: 75.1øF, 14.0% humidity, 3 mph WSW wind, 0.00 inches rain/24hrs --- SBBSecho 3.11-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Hello Rob!

02 Dec 20 10:17, Rob Swindell wrote to Oli:

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

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.

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

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)

Hello Fred.

<On 02Dec2020 19:02 Fred Riccio (1:132/174) wrote a message to Marc Lewis regarding Re: Problem with legacy tosser (Squish) and Sync's MSGID >

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?

No, the messages are all bounced by NetMgr for a non-nodelisted address. TimEd has noting to do with it. Again, let me emphasize, NO OTHER system other than Synchronet's mail system has any kind of problem whatsoever. I have a feeling, but this may be off in left field since I'm not a programmer, that NetMail, unlike EchoMail which is unaffected by these anomalous @MSGID lines, has some restriction, perhaps like line length or permitted characters that gets fouled by the addition of the xxxx@1:999/9999 (example only) to the @MSGID line. Would that I were a programmer and/or knew the specific differences between NetMail and EchoMail @MSGID line requirements, but I don't.

To answer your questions about the storage format for NetMail, it is in .MSG format - that's the one and only area that doesn't store in Squish format.

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

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

Hello Marc!

02 Dec 20 18:42, Marc Lewis wrote to Fred Riccio:

TimEd has noting to do with it.

But it does... Based on the initial message you posted here, It gets confused about the zone. It's not causing the problem, but it is affected by it.

Would that I were a programmer and/or knew the specific
differences between NetMail and EchoMail @MSGID line requirements,
but I don't.

FTS-0009 doesn't differentiate between NetMail and EchoMail. The format should be the same for both. Side note: Per the FTS, MsgId isn't required, but if you incllude it, It has to follow the specs.

To answer your questions about the storage format for NetMail, it is
in .MSG format - that's the one and only area that doesn't store in Squish format.

I run the same way here because I like to use the old tried-and-true utilities like AreaFix and Tick that were written way before the squish database existed.

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.

This happens if there is a "proper", MsgId, a Sync-style ID, or no ID at all.

I am at a complete loss as to what to do.

If you think it would help, I could write you a fixer-upper routine that removes the "xxxxxxx@" part of the msgid from the packed messages, but it will take some batch file magic to wedge it in between the packets being unpacked and Squish tossing them. Are you up for it?

Idea #2... A program that sorts through your NetMail folder and replaces the trash at those 4 locations with Zone & point info. That would be much easier to add to your system.

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

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.

* Origin: kakistocracy (2:280/464.47)

Hello Fred.

<On 03Dec2020 08:50 Fred Riccio (1:132/174) wrote a message to Marc Lewis regarding Re: Problem with legacy tosser (Squish) and Sync's MSGID >

[snip]

To answer your questions about the storage format for NetMail, it is
in .MSG format - that's the one and only area that doesn't store in Squish format.

I run the same way here because I like to use the old
tried-and-true utilities like AreaFix and Tick that were written
way before the squish database existed.

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.

This happens if there is a "proper", MsgId, a Sync-style ID, or no
ID at all.

I am at a complete loss as to what to do.

If you think it would help, I could write you a fixer-upper routine
that removes the "xxxxxxx@" part of the msgid from the packed
messages, but it will take some batch file magic to wedge it in
between the packets being unpacked and Squish tossing them. Are
you up for it?

I'm up for that; batch language is my *only* strong point. My MAILTOSS.BAT is a LONG fairly complicated batch, and I can fairly easily insert something before the point where Squish comes into play. (BTW, I even temporarily altered the MAILTOSS.BAT to call Squish in DOS mode rather than calling it in OS/2 mode, and it made zero difference.

In keeping with what Rob Swindell has said, I am willing to acquiesce that Squish may be having a problem with the newer @MSGID line format, though it has no problem with the very same line format in EchoMail. So if you can come up with a methodology of extracting the extra characters, I'm up for it. Again, I only wish I had the required knowledge to zoom in on what exactly is going on when Squish trys to toss one of these NetMail messages and gets totally screwed up doing so.

I was admittedly very hasty in saying I was ready to "hang it up". I am not. I just dread redesigning the toss system to a different tosser inasmuch as getting Squish re-compiled with any corrections for this "fault" are going to be difficult at best since a specific compiler and associated files are apparently few and far between. I will however post to the appropriate echo about finding someone to tackle this.

Idea #2... A program that sorts through your NetMail folder and
replaces the trash at those 4 locations with Zone & point info.
That would be much easier to add to your system.

I'm up for that too, but the only problem with that is that NetMgr has already rejected the affected NetMails after Squish has put them in the NetMail directory, as being from a non-FidoNet address. I could possibly alter the NetMgr configurations to not read NetMails any longer, but that would almost completely defeat the reason for running NetMgr.

Your first idea sounds completely do-able here... at least until a "fix" for Squish can be conjured up.

Best regards,
Marc

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

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)

Marc wrote (2020-12-07):

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 never used *.MSG netmail areas with Squish, always Squish format. Worked fine for me, but I haven't had NetMgr in my setup. I wonder if others had also problems with *.MSG areas because of missing zone and point information. Or this preserved by the INTL, FMPT and TOPT kludges within the stored messages?

---
* Origin: (2:280/464.47)