Subj : Problem with legacy tosser (Squish) and Sync's MSGID
To   : Oli
From : Rob Swindell
Date : Thu Dec 03 2020 11:12 am

  Re: Problem with legacy tosser (Squish) and Sync's MSGID
  By: Oli to Fred Riccio on Thu Dec 03 2020 05:18 pm

 > 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.

The zone and pont header fields only exist for "stored message" (.msg files) and packet headers. The packed message headers themselves do not have provisions for zone and point information. Instead, the zone and point can be found in the INTL/FMPT/TOPT kludges and the "Via" kludge lines (for NetMail), the INTL/FMPT/TOPT kludges being the "correct" method - also mentioned in FTS-1. I'm not sure when the INTL/FMPT/TOPT kludges were added to FTS-1, but it's certainly been a *long* time.
-- 
                                            digital man

Rush quote #31:
Live for yourself, there's no one else more worth living for
Norco, CA WX: 66.6øF, 13.0% humidity, 8 mph NNE wind, 0.00 inches rain/24hrs

.