Hi All,

One of my links sent in a packet with a corrupted message, which HPT tossed and promptly sent back out.

The packet itself seemed fine date & address wise, but the message was not:

Message header ------------------------------------------------------------------------------ "rom : " 16/2047
To : " Updates previous tstm wnd dmg rep"
Subject : ""
DateTime : "00 00 00:00:00"
Attr : 0x0000
OrigAddr : 400/38
DestAddr : 400/1

I've put a couple of rules in place with HPT's filter capabilities:

If $fromname is empty or begins with whitespace then mark the message as bad
If $toname is empty or begins with whitespace then mark the message as bad
If $subject is empty or begins with whitespace then mark the message as bad

The date in the message was also all zeros, which GoldEd reads as Jan 01 1980.

I've also added some checks in there for either an invalid date or +/- 90 days then mark the message as bad.

I'd like to hear others comments on these checks, do they seem sane? Mystic or Telegard don't seem to let you send a message with an empty subject, but
GoldEd will allow you to.


Jay

... Predestination was doomed from the start

--- Mystic BBS v1.12 A49 2024/05/29 (Linux/64)
* Origin: Northern Realms (21:3/110)

Re: Corrupted Message
By: Warpslide to All on Thu Mar 19 2026 10:50 am

Howdy,

I've put a couple of rules in place with HPT's filter capabilities:

If $fromname is empty or begins with whitespace then mark the message as bad If $toname is empty or begins with whitespace then mark the message as bad If $subject is empty or begins with whitespace then mark the message as bad

I'd like to hear others comments on these checks, do they seem sane? Mystic

Clrghouz does the same regarding the "is empty" part - it goes one step further if the body of the message is empty, it discards the message.

I dont do anything to those fields if they have a value, and it starts with a whitespace though. Maybe I should?

I've also added some checks in there for either an invalid date or +/- 90 days then mark the message as bad.

I also validate the date, and if it is future dated (by more than 2 days), or older than 90 (I think), or doesnt resemble a date its discarded.


...ëîåï
--- SBBSecho 3.29-Linux
* Origin: I'm playing with ANSI+videotex - wanna play too? (21:2/116)

On 20 Mar 2026, deon said the following...

Clrghouz does the same regarding the "is empty" part - it goes one step further if the body of the message is empty, it discards the message.

Good thinking, I've added in some checks for "if empty" or "is empty after stripping out all blank lines & controls lines".

I dont do anything to those fields if they have a value, and it starts with a whitespace though. Maybe I should?

I've been going back & forth on the "begins with whitespace" thing. I'm thinking a To or From name should never begin with whitespace. I can see a subject having a higher chance of beginning with a space if someone fat-fingered it.

I also validate the date, and if it is future dated (by more than 2
days), or older than 90 (I think), or doesnt resemble a date its discarded.

Right now I'm doing a +/- of the same number of days, it would be trivial to change that to different values for past & future.

Thanks for the feedback, good to know I wasn't way off base.


If anyone is running HPT and wants to try this out, you can find the script here:

https://nrbbs.net/badcheck.pl.txt

Add it to your filter.pl file like this:

BEGIN {
require "badcheck.pl";
}

sub filter {
if (my $rc = badcheck()) {
return $rc;
}
}


Jay

... I was wondering why the ball was getting bigger. Then it hit me

--- Mystic BBS v1.12 A49 2024/05/29 (Linux/64)
* Origin: Northern Realms (21:3/110)

Hello Warpslide!

21 Mar 26 11:01, you wrote to deon:

Right now I'm doing a +/- of the same number of days, it would be
trivial to change that to different values for past & future.

Thanks for the feedback, good to know I wasn't way off base.

Have you used the "-tooold 60" statement in your echo line in the hpt config? That helps a lot.

I posted a patch to the husky echo back on 10th October last year that, covers something like what your
script is doing for the date issue.:

HPT Bug: Corrupted packets not rejected due to missing date validation



Vorlon
aka
Stephen


--- GoldED+/LNX 1.1.5-b20250409
* Origin: Dragon's Lair ---:- dragon.vk3heg.net -:--- Prt: 6800 (21:1/195)

On 22 Mar 2026, Vorlon said the following...

Have you used the "-tooold 60" statement in your echo line in the hpt config? That helps a lot.

I do have -tooOld 90 -tooNew 30 set with EchoAreaDefaults but it only seems to check the packet date, not the date on the message.

I posted a patch to the husky echo back on 10th October last year that, covers something like what your script is doing for the date issue.

I missed that, do you know if that patch also made it to github?


Jay

... He used to be fairly indecisive, but now he's not so certain

--- Mystic BBS v1.12 A49 2024/05/29 (Linux/64)
* Origin: Northern Realms (21:3/110)

Hello Warpslide!

22 Mar 26 07:18, you wrote to me:

Have you used the "-tooold 60" statement in your echo line in the
hpt config? That helps a lot.

I do have -tooOld 90 -tooNew 30 set with EchoAreaDefaults but it only seems to check the packet date, not the date on the message.

I've seen messages in my bad area with the note: "message is too old....", so it's working here.

I posted a patch to the husky echo back on 10th October last year
that, covers something like what your script is doing for the
date issue.

I missed that, do you know if that patch also made it to github?

Here it is. I've also got another one, but it hasn't been posted.
This first patch has caught 8 or so packets sofar. Most have come from a system in Z2, posting received new file messages.

'C' isn't my strength, so if it breaks your system you have to glue it back together.


=== Cut ===
= fidosoft.husky (3:633/280) ==================================================
Msg : 3782 of 3824 Snt Loc
From : Stephen Walsh 3:633/280 10 Oct 25 10:38:04
To : All
Subj : HPT Bug: Corrupted packets not rejected due to missing date validation =============================================================================== @MSGID: 3:633/280 68e847d8
@CHRS: CP437 2
@TZUTC: 1100


Hi Husky developers,

I've discovered a bug in HPT where packets with corrupted/empty message date fields are not properly rejected and renamed to .bad as they should be.

PROBLEM DESCRIPTION:
===================
When processing packets, HPT reads the 20-byte datetime field from each
message header (pktread.c:771) and calls parse_ftsc_date() to parse it
(line 777). However, the return value from parse_ftsc_date() is ignored.

The parse_ftsc_date() function returns flag_t values indicating:
- FTSC_BROKEN (2) - field cannot be parsed
- FTSC_FLAWY (1) - field has correctable errors
- FTSC_TS_BROKEN (128) - timestamp broken but date OK

Currently, even when parse_ftsc_date() returns FTSC_BROKEN, the badmsg
counter is not incremented, so the packet is not renamed to .bad and
continues to be processed.

REAL-WORLD IMPACT:
==================
I encountered a packet in the wild (from 2:341/66) that contains:
- Message 3: Empty date field (0 bytes)
- Message 4: Invalid date field (1 byte: '0')

The bad packet can be obtained at: https://vk3heg.net/badpkt.zip

HPT processed this packet instead of rejecting it.

PROPOSED FIX:
=============
After calling parse_ftsc_date(), check if the FTSC_BROKEN flag is set and increment badmsg accordingly. This ensures corrupted packets are properly renamed to .bad.

Patch attached below. Please review and consider applying to the codebase.

--- hpt/src/pktread.c.orig 2025-10-09 10:00:00.000000000 +1100
+++ hpt/src/pktread.c 2025-10-09 10:05:00.000000000 +1100
@@ -734,6 +734,7 @@
{
s_message * msg;
size_t len;
+ flag_t date_flags;
int badmsg = 0;
struct tm tm;
long unread;
@@ -774,7 +775,16 @@
}

msg->datetime[20] = 0; /* ensure it's null-terminated */
- parse_ftsc_date(&tm, (char *)msg->datetime);
+ date_flags = parse_ftsc_date(&tm, (char *)msg->datetime);
+
+ /* Check if the date field is broken and cannot be parsed */
+ if(date_flags & FTSC_BROKEN)
+ {
+ w_log(LL_ERR,
+ "wrong msg header: datetime field is broken ('%s')",
+ msg->datetime);
+ badmsg++;
+ }

/* val: make_ftsc_date((char*)msg->datetime, &tm); */
if(globalBuffer == NULL)

TESTING:
========
With this patch applied, packets with broken date fields will be properly rejected and renamed to .bad instead of being processed.

Be