Subj : Netmail in the insecure inbound
To   : Alan Ianson
From : Kai Richter
Date : Wed Apr 28 2021 04:12:44

Hello Alan!

26 Apr 21, Alan Ianson wrote to Kai Richter:

 AI>>> I know that it is inconvenient for me.
 KR>> That is reason enough.

 AI> That is not reason enough. Decompressing an archive (within reasonable
 AI> limits) is not a problem.

The problem is the combination of insecure and compression.

 KR>> But it's not only for you, it's for any other node that will
 KR>> receive insecure compressed netmail from that node. You are in
 KR>> the first line and responsible to defend systems with no or
 KR>> limited compression support.

 AI> I will work with such a node if there is one.

I don't understand. No matter what you will work around it would never solve the ongoing problems that other nodes could have with insecure compressed netmail.

 AI> I will deliver mail and files to a node in a way they can work with
 AI> even if that causes me extra steps to do.

So why does your respected node not do that? Why does he cause inconvenice to you?

 AI> To date I have not heard from any nodes that they could not
 AI> decompress any mail or files sent to them.

 KR>> Could you tell me what de+compression software is available for
 KR>> the OpenPandora or the Dragonbox Pyra?

 AI> I do not know what works with Dragonbox Pyra. If someone is using
 AI> exotic hardware or software then I may not be able to communicate with
 AI> them if they cannot work with plain packets.

 AI> This is far from the issue I have seen and reported.

This exactly the issue you have. An insecure connect is for the first contact with a fidonet system, you as sender do not have any idea what kind of compression is supported. Thus insecure connects must be without compression.

Regards

Kai

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

.