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