REPLY: 1:132/174 5fc645b4
MSGID: 2:280/464.47@fidonet 5fc697c9
PID: GED+LNX 1.1.5-b20180707
CHRS: UTF-8 4
TZUTC: 0100
TID: CrashMail II/Linux 1.7
01 Dec 20 13:15, you wrote to Marc Lewis:

 FR> AFAIK, squish computes the CRC32 of everything in the MSGID line that
 FR> comes after the colon, and uses it for dupe checking.  It shouldn't be
 FR> 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...

 FR> If for some reason Squish is trying to get the origin address from thr
 FR> MSGID line, check the pkt to see if the zone is in the header.  It
 FR> could be getting confused because of all the different packet header
 FR> versions.  Maybe Sync is using an unknown (to squish) header format
 FR> 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)
SEEN-BY: 1/123 18/200 90/1 105/81 120/340 123/131 124/5016 203/0 221/0
SEEN-BY: 226/30 227/114 702 229/101 424 426 550 664 1016 240/2100
SEEN-BY: 240/5138 5411 5832 5853 249/206 317 400 280/464 5003 292/854
SEEN-BY: 292/8125 317/3 322/757 342/200 396/45 633/280 2432/390 2454/119
PATH: 280/464 240/5832 229/426