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