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[snip]
concerned. Both the from and to address are Zone 1 addresses but for
some reason Squish cannot fathom the xxxx@ in the MSGID line.
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?
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.
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.
AFAIK Squish supports FSC-0039 packets only and SSBSecho writes
FSC-0045 and FSC-0048 packets. Would this explain the problem?
One more thought... Was the NetMail sent direct or routed. That
makes a difference as far as the pkt address goes.
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 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
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.
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.).
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?
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.
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.
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
TimEd has noting to do with it.
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.
I am at a complete loss as to what to do.
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.
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.
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 (?)
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.
No, the messages are all bounced by NetMgr for a non-nodelisted address.
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...
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).
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?
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.
| Sysop: | digital man |
|---|---|
| Location: | Riverside County, California |
| Users: | 1,043 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 90:34:35 |
| Calls: | 500,954 |
| Calls today: | 3 |
| Files: | 109,377 |
| D/L today: |
1,264 files (248M bytes) |
| Messages: | 304,695 |