Hello There,

I haven't used HPT as a processor in some years. Upon setting it (Win32 1.9.0-cur 17-02-17) up I ran into a problem tossing compressed incoming mail bundles from a particular uplink. If the incoming bundles come in as say <filename>.su1 they get renamed to .sec as security violation. If I use unzip to manually uncompress the mail bundle and then manually toss the .pkt packets. The packet files get tossed fine with no security violation.

I have the uplink set on my end to use zip as a packer. And zip manually opens up the mail files ok. My wonderment is where is HPT seeing a security violation with the compressed mail files? I have the AKA's setup to specify the correct link AKA and local AKA for that link. And I have the correct group access setup for that link. Could it be an issue with the compressed filename being generated by the uplink that that HPT sees as a security violation?

Jeff

--- BBBS/Li6 v4.10 Toy-4
* Origin: Fidoneet: The Ouija Board - Anoka, MN -bbs.ouijabrd.net

On 2019 Mar 24 16:40:24, you wrote to All:

Could it be an issue with the compressed filename being generated by
the uplink that that HPT sees as a security violation?

unlikely...

are the bundles in your secure or insecure inbound?

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... Every person you meet knows something you don't. Learn!
---
* Origin: (1:3634/12.73)

Hello Mark,

Could it be an issue with the compressed filename being generated by
the uplink that that HPT sees as a security violation?

unlikely...

That was my thought too.

are the bundles in your secure or insecure inbound?

Since it is a pass worded BinkD session. The bundles are put in the secure/protected inbound. HPT sees and tosses other mail bundles from other uplink's but not from this particular uplink. I also forgot to mention until I had posted my last message that the expected mail bundle file extension from this uplink is not the usual .su[0-9,a-z], Etc. But is instead .[a-z][0-9,a-z]. If I open the oddly named mail bundles and extract the PKT's the PKT's then toss fine.

I have since requested the uplink to send only uncompressed PKT files and have gotten a confirmation of my request. In fact several PKT's have arrived and were tossed without error. That isn't going
to keep me from wanting to find the actual cause of what was happening and why.


Jeff


--- BBBS/Li6 v4.10 Toy-4
* Origin: Fidoneet: The Ouija Board - Anoka, MN -bbs.ouijabrd.net

On 2019 Mar 24 22:31:30, you wrote to me:

are the bundles in your secure or insecure inbound?

Since it is a pass worded BinkD session. The bundles are put in the secure/protected inbound. HPT sees and tosses other mail bundles from

other

uplink's but not from this particular uplink.

ok...

I also forgot to mention until I had posted my last message that the expected mail bundle file extension from this uplink is not the usual .su[0-9,a-z], Etc. But is instead .[a-z][0-9,a-z]. If I open the oddly named mail bundles and extract the PKT's the PKT's then toss fine.

ummm... i'm confused by the extension stuff... are you saying that they were coming in with only two characters and not in the normal format? please give an example of one of them... not a regex...

I have since requested the uplink to send only uncompressed PKT files
and have gotten a confirmation of my request. In fact several PKT's
have arrived and were tossed without error. That isn't going to keep
me from wanting to find the actual cause of what was happening and
why.

what software is that system running?

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... Not breaking the rules, just testing the elasticity...
---
* Origin: (1:3634/12.73)

Hello Mark,

I also forgot to mention until I had posted my last message that the
expected mail bundle file extension from this uplink is not the usual
.su[0-9,a-z], Etc. But is instead .[a-z][0-9,a-z]. If I open the oddly
named mail bundles and extract the PKT's the PKT's then toss fine.

ummm... i'm confused by the extension stuff... are you saying that they were
coming in with only two characters and not in the normal format? please give
example of one of them... not a regex...

An example filename is 0000ffe4.s0 although the filename extensions can range from 0000ffe4.a0 to 0000ffe4.z9. I have tried renaming an individual file to a more expected filename like 0000ffe4.su0 and then attempted to toss it. But HPT still considers it a security violation and renames the file to 0000ffe4.sec and moves it to a separate directory.

But.. If I manually unpack the 0000ffe4.a0 file and extract the .PKT files. The extracted .PKT file(s) will toss fine without errors.

I have since requested the uplink to send only uncompressed PKT files
and have gotten a confirmation of my request. In fact several PKT's
have arrived and were tossed without error. That isn't going to keep
me from wanting to find the actual cause of what was happening and
why.

what software is that system running?

Mystic. BUT, I am don't feel it right for me to at this point put the responsibility for the issue on the sender or the receiver of the mail files. We are both currently checking setups and testing. I also have a local installation of Mystic that I can use for testing purposes.

Jeff


--- BBBS/Li6 v4.10 Toy-4
* Origin: Fidoneet: The Ouija Board - Anoka, MN -bbs.ouijabrd.net

On 2019 Mar 26 13:58:30, you wrote to me:

ummm... i'm confused by the extension stuff... are you saying that they
were coming in with only two characters and not in the normal format?
please give a example of one of them... not a regex...

An example filename is 0000ffe4.s0 although the filename extensions
can range from 0000ffe4.a0 to 0000ffe4.z9. I have tried renaming an individual file to a more expected filename like 0000ffe4.su0 and then attempted to toss it. But HPT still considers it a security violation
and renames the file to 0000ffe4.sec and moves it to a separate
directory.

ugh! yeah, that filename looks like how a flo file is named... and the extension is definitely wrong...

But.. If I manually unpack the 0000ffe4.a0 file and extract the .PKT files. The extracted .PKT file(s) will toss fine without errors.

i'd report the problem with the archive names and extensions to the the maintainer but read moer and see becaue it may be something else... if not, then a report is surely needed...

I have since requested the uplink to send only uncompressed PKT files
and have gotten a confirmation of my request. In fact several PKT's
have arrived and were tossed without error. That isn't going to keep
me from wanting to find the actual cause of what was happening and
why.

what software is that system running?

Mystic. BUT, I am don't feel it right for me to at this point put the responsibility for the issue on the sender or the receiver of the mail files. We are both currently checking setups and testing. I also have a local installation of Mystic that I can use for testing purposes.

i would certainly be testing it... i don't have a current install of mystic so i can't really help there... i can say that my current system doesn't seem to have a problem with the few mystic systems connecting here... i'll have to dig in the logs to find some sessions and what version they are running and see what filenames they are sending...

i cannot imagine this being a configuration problem unless the sender's outbound is pointing to the wrong directory and they're sending the files before mystic has a chance to name them properly when moving them into the outbound... i've seen that before with other software... is that system using a filebox for your's instead of the normal outbound??

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... A violent, unwanted clown on the global stage.
---
* Origin: (1:3634/12.73)