REPLY: 1:132/174 5fc8a5f2
MSGID: 2:280/464.47@fidonet 5fc9263a
PID: GED+LNX 1.1.5-b20180707
CHRS: UTF-8 4
TZUTC: 0100
TID: CrashMail II/Linux 1.7
03 Dec 20 08:50, you wrote to Marc Lewis:

 ML>> I REALLY don't think that Squish is at fault.

 FR> I think Squish is partially at fault.  When messages tossed to *.Msg
 FR> files, it leaves trash at offset B0 and B2 where the orig & dest zone
 FR> 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.

 * 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/5832
SEEN-BY: 249/110 206 317 400 280/464 5003 292/854 8125 317/3 322/757
SEEN-BY: 342/200 396/45 633/280
PATH: 280/464 229/101 426