MSGID: 1:132/174 5fc645b4   
   TZUTC: -0500   
   REPLY: 1:396/45.0 fc65c956   
   CHRS: IBMPC 2   
   CODEPAGE: 437   
   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)   
   SEEN-BY: 1/19 123 16/0 18/200 90/1 105/81 120/340 123/130 131 124/5016   
   SEEN-BY: 132/174 154/10 203/0 221/0 1 226/30 227/114 702 229/101 424   
   SEEN-BY: 229/426 550 664 1016 230/0 240/5832 249/110 206 317 400 261/38   
   SEEN-BY: 280/464 5003 292/854 8125 317/3 320/119 219 319 322/0 757   
   SEEN-BY: 342/200 396/45 633/280   
   PATH: 132/174 320/219 203/0 280/464 229/101 426