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