Subj : Sorry for being so silent for the past couple of months.
To   : Ozz Nixon
From : mark lewis
Date : Tue Nov 21 2017 03:32:58

 On 2017 Nov 20 19:49:24, you wrote to me:

 ml>> i'm not aware of a FTN spec concerning RE:... some software may strip
 ml>> it off on importation into the local message bases... some drop it on
 ml>> replies... it isn't that critical and software really shouldn't be
 ml>> linking on subject lines these days anyway... especially considering
 ml>> how the subject rarely ever gets changed when the topic drifts from
 ml>> one thing to another... then there are some users that specifically
 ml>> change the subject so as to try to ensure that their posts are fully
 ml>> distributed and not caught as dupes by older brain dead software...

 ON> Okay, my counter point to this is some environemnts are not posting
 ON> the msgid of their reply to as "REPLY". This is where my re-threading
 ON> code is failing over to "by subject", "by RE:" and "by timestamp" to
 ON> try to keep the integrity / sanity of the reader.

make it simple... if it has RE: import it but ignore it during thread 
linking... but wait... i thought you said you were using SQUish message base? 
it has several limits that you might want to know of... message time stamps are 
limited to 2 second imcrements (because of using DOS file time stamp format)... 
a max of ten messages linked to one... in this age of dupes flying about to try 
to ensure full distribution of a message, the time stamp may result in false 
negatives... maybe someone rescanned a message and sent it back out into the 
network... if it came from a SQUish base, the time stamp will be even and may 
very well not be the same as the original time stamp... that means that two 
copies of the message may be identical in every way except the time stamp... at 
least one BBS package had this problem... when it was discovered and the search 
ended, that package was fixed... so it is possible that you have some of those 
messages that you're trying to work with in your archives...

 ON> I have kept the PKTs for the this whole year to help me stress test my
 ON> tosser and message base classes for performance. And I have noticed 
certain
 ON> (keeping the names private for now) systems are posting replies with 
either
 ON> NEWMSGID in the REPLY instead of the original (like it was renumbered
 ON> somewhere along the way to them or durring their system's TOSS phase), and
 ON> I happen to fail to by subject/re/timestamp and do not find re on the
 ON> subject - so I fail to "must be a new thread same subject".

 ON> Am I missing something??

no, you're seeing the schtuff... some of those without REPLY lines are QWK 
offline mail uploads... QWK doesn't know about FTN control lines so it is 
possible that the door adds the MSGID but it may not know which message a new 
post is a reply to so it can't/doesn't created a REPLY line... not much you can 
do about that... linking on subject is just bad... sorting on time is also 
bad... you can't really tell if the time in a message is the originator's local 
time or UTC or what... you can try to figure it out and possibly use the TZUTC 
control line to help but it is still rough... back when the HMB was all the 
rage, we decided to not worry about sorting the messages... just toss them as 
they arrive... it isn't that big a deal anyway... we read from the first unread 
message to the last in whatever order they arrive...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it 
wrong...
.... Poor Mexico, so far from God and so near the United States - P Diaz
---
 * Origin:  (1:3634/12.73)

.