Subj : hpt long subjects and bad packets
To   : Kai Richter
From : Oli
Date : Tue Jan 14 2020 08:34:03

13 Jan 20 12:27, you wrote to me:

 KR>>> Fix the source of the problem. If it can't be fixed don't allow
 KR>>> the broken to enter. That's straight, clear and simple.

 O>> Maybe we should block all PKTs generated by Mystic BBS then?

 KR> Well, i'm emotionally affected so i'm the wrong person for judgement.
 KR> If you would start a seriously vote i would mark the YES field. But
 KR> thats because some mails from that software crash my terminal output
 KR> to unreadable. I have to quit my editor then, do a terminal reset and
 KR> start again carefully skipping the broken mail. That is very annoying
 KR> sometimes.

I'm emotionally affected too. Most of the time I'm reading fido mails on my 
4.8" phone (ssh session to my headless Raspberry). The screen is a bit small to 
display 80 columns in a comfortable font size. Mystic's hard wrapping of all 
mail that passes through to 80 chars/line is very annoying.

 O>> And also PKTs from hpt itself? (which doesn't set the JAM OADDRESS
 O>> and rewrites the message date for Squish messages.

 KR> Actually i have no clue if msgbase formats are part of the FTS. I
 KR> never noticed the msgbase format of incoming mails. I can't see if you
 KR> use JAM or squish. Anyway your mail is stored in squish on my system.
 KR> That's why i can't see a reason to drop a bug report.

As far as I understand it from the documentation hpt always does import/export 
in one pass, is that correct? But What about echoareas that get rescanned? 
Around 50% of the mails (or a little bit less) will have a modified timestamp 
(DOS time format with 2 second granularity). To be clear, Squish message base 
format has a field for storing the original FTN time field, it is just not used 
by hpt (if I understand the C sources correctly).

 
* Origin: kakistocracy (2:280/464.47)

.