Subj : hpt long subjects and bad packets
To   : Oli
From : Kai Richter
Date : Wed Jan 15 2020 01:59:12

Hello Oli!

14 Jan 20, Oli wrote to Kai Richter:

 KR>> if you use JAM or squish. Anyway your mail is stored in squish on
 KR>> my system. That's why i can't see a reason to drop a bug report.

 O> As far as I understand it from the documentation hpt always does
 O> import/export in one pass, is that correct?

I don't know. There is control for import by "hpt toss" and control for export 
via "hpt scan". But for routing i don't know if it's possible to import pkt to 
local msgbase without exporting the mail to all linked systems. That option 
doesn't make sense to me. If the user deletes mails before they are forwarded 
to the linked systems that would be censorship and against the "no modification 
of in transit mail" of the policy.

But i found another function that reveals that the date field is common for 
modification:

***
@item Syntax:
@code{processPkt <string>}
@item Example:
@code{processPkt pktdate}

Space char and name of the current file "*.pkt" will be append into end of
<string> and <string> willl be executed before tossing each pkt file. You
are able to fix your pkts using pktdate or any other tool before tossing
them. Note that pkt file may be renamed depending of @code{tossingExt}
token value.
***

In the past when i used OS/2 there was a tool called pktsort that could be hook 
at the same place to sort the mails by date. That fixed the situation that the 
answer was visible before the question in the msgbase.

For hpt scan there is an option to bypass netmail:

'When PackNetMailOnScan is "on" (default) hpt packs netmail when doing
"hpt scan" and netmail area is found in EchoTossLog file. When it is
"off" hpt leaves netmail area(s) in EchoTossLog file until "hpt pack" is
invoked.'

 O> But What about echoareas that get rescanned? Around 50% of the mails
 O> (or a little bit less) will have a modified timestamp (DOS time format
 O> with 2 second granularity).

That "adjusted" timestamp is common to me since i use fidonet. I don't know the 
decision for that, maybe it's due to 8-bit limitation of the date format on 
early fidonet computers back in the 80's?

Regards

Kai

--- GoldED+/LNX 1.1.4.7
 * Origin:  Monobox  (2:240/77)

.