Subj : Compressed netmail in the insecure inbound To : Alan Ianson From : Kai Richter Date : Tue May 04 2021 16:47:40 Hello Alan! 03 May 21, Alan Ianson wrote to Kai Richter: KR>>>> If there is no conversation between the nodes then there is no KR>>>> problem that needs to be solved. AI>>> I don't know what that is supposed to mean. KR>> As far as i understood there was no conversation between the node KR>> with the compressed ping netmail and you. If you both don't talk KR>> then you both don't need a connect. AI> The connects do happen. That is not a problem. The issue is netmail AI> that is compressed, the recipient is irrelevant. There is no content to transfer. You don't need a road if nobody travels. Your actual scenario is two machines that have a road that is used for nothing more that to prove "look, there is a road". Do one step back and get aware that insecure compressed ping creates problems for no reason other than to have a problem to be solved. ========== I was going to split the rest to another mail, but the part above is an important context at the end of this mail. KR>> When i wrote insecure ping I had that insecure inbound in my KR>> mind, the correct binkd keywords are: KR>> inbound /secure KR>> inbound-nonsecure /insecure AI> I use those keywords in my config, for some very good reasons. I am AI> not suggesting any kind of insecure behaviour. Your suggestion increases complexity and risk level for the whole fidonet. AI> Is it desirable to decompress netmail in the insecure inbound that has AI> arrived in the form of an arcmail compressed mail bundle? AI> I am suggesting that we do that for netmail. All arguments are on the table within the last ~30K of mails. In short: No. Now the cat is out of the bag. You really do want to change the default behavior of the whole fidonet for insecure compressed mail. All nodes can handle uncompressed FTS-0001 mail because they have to to be part of the Fidonet. AI> I agree with you that nodes should always send netmail uncompressed Then please follow this path. It is the solution with no issues. Be a good coordinator and teach selfish nodes why to turn off compression for insecure netmail. Do not support their annoying behavior by working around. You are going to force the whole fidonet to support compression. See the top of this mail - you are going to create problems where are none. AI> However if I receive netmail in compressed form, and I do receive it AI> that way from time to time that we process it. You can do what ever you will on your system but stop forcing me/us to support compression. You don't know what is running on "our" side. There is no arc support for the Pandora, for example. http://repo.openpandora.org/?page=all&search=unarc What will be then? Would you simply say i'm no longer part of fidonet if i can't support compression? Or will you invent a "noarc" flag for the nodelist that any node does know that i do not support compression? You intention for easy going with compressed insecure mail will backfire then because you have to install the "unarc" flag condition to the whole fidonet systems including yours. See the top of this mail, you're creating issues where are none. AI> I find no policy or FTN standard that directs nodes not to do that AI> and that is why it happens. I showed you two times already. The *transfer*! format is defined by FTS-0001. Compression after agreement is defined by the echopol and that is a freedom i'd like to see for the whole fidonet. You can use any compression tool you like if both parties agree. If one does not agree or the parties never talked about compression before then no compression is the solution that will work on the whole fidonet. Regards Kai --- GoldED+/LNX 1.1.4.7 * Origin: Monobox (2:240/77) .