Subj : Netmail in the insecure inbound To : Alan Ianson From : Kai Richter Date : Sun May 02 2021 22:00:36 Hello Alan! 29 Apr 21, Alan Ianson wrote to Kai Richter: KR>> You told me that you do not know a standard for netmail KR>> compression. I tried to help you by looking into the policy and KR>> quoted the parts that could change your unknowingness. AI> Policy takes no position on compression, and rightly so. AI>>> There is nothing in policy or FTN standards as far as I know. KR>> And if you reject to read it in context you would never know it. AI> I have not rejected it. Every input and output from my node is AI> compliant with our minimum standards. We are going to repeat us. You are still on the "i and my" point of view. You and your system are not part of your problem as noted on the subject line. Btw, didn't you told us you have no control about the input to your system? (*) AI> I may compress it for storage/delivery if a node is configured that AI> way but I have not rejected anything in policy or fidonet standards AI> and I never will. Why would I do that? To fulfill your responsibiliy as part of the fidonet *C structure. Let's reflect your point starting above at (*) to your initial situation: AI> I received netmail in my insecure inbound addressed to Ping. This AI> netmail arrived in an arcmail bundle and it was not unpacked, it was AI> renamed to .sec and left in the insecure inbound You are the node that is NOT configured that way for compression. The sender must not compress it. Minimum definition in the policy is FTS-0001 type 2 packet format. You told us you have never talked about compression to that node, so this node never got your agreement for compression and because of that he must stick on FTS-0001 without compression. AI>>> Echomail/netmail may arrive compressed or uncompressed. If that AI>>> mail is compressed I don't think any rules have been broken. KR>> I do. I think you can't see it because... AI>>> I can decompress KR>> ...you are focused on "i can" or "my node". AI> I say that because, I can (within reasonable limits). Like we see now. You can't do automatic decompression for insecure inbounds. I think we made a mistake when we started the discussion with a focus on compression. The more important issue is insecure inbound. KR>> That was not the question. The question was if the size of the KR>> incoming test mails is large enough to justify compression. AI> question last time. They were 0.5KB or so. They were simply packed AI> into an arcmail bundle because that is the way some software works, AI> not because they were large in size. That's too bad. So size couldn't be put on the "pro compression" list. KR>> From my point of view there is a minimum standard for compression KR>> in the policies. A minimum standard that is usefull for ALL KR>> fidonet systems. AI> Compression is not spoken of in policy and it doesn't need to. It does need because it must be sure that both parties can process the mail. That's why the the format is defined by policy and compression is not part of the defined format. AI> Fidonet nodes can arrange their links in a way that works for them. That's the point. Compressed insecure inbound does not work reliable on all systems. Compressed mail CAN be arranged optional AFTER agreement. This would tell us what the minimum configuration for fidonet software is and what kind of configuration is an optional enhancement. AI> If a node sends mail here in an arcmail bundle we can decompress it. AI> That is not and never was a problem. You told me you don't know the Pyra. What about the future? You can't say we can if you don't know what we can do. AI> If my tosser can't/won't do it then I'll do it myself! Sure you can. But i have to remind you that you asked for a solution that does not effect your system only: AI> I wonder if it is possible for hpt to unpack those arcmail bundles AI> and toss the packets within if they are netmail. You want to have a change in a security feature of a software that is used by many nodes. This is a change that is far beyond of "my system". AI> I find that all a pleasure and not a burden and while I am NC of net AI> 153 I'll always do my best for the nodes in net 153, and as long as I AI> am a node in fidonet I will do my best for fidonet as a whole. Thanks, i'm happy to read that, the last part especially. ;-) Could we keep going on with the "as a whole" hat on? KR>> You must be able to receive netmail from any node. This is the issue KR>> you brought on the table. This issue is not yours only, all NCs are KR>> effected when we are searching for a standard. AI> I have not and will not abandon any standards or minimum requirements. Not yet, sure. But you asked for the first step into that direction. Let's say hpt does have build in support for insecure compressed mail. Then this software that does send compressed mail without prior agreement by both nodes will contiune with less issues. Insecure compressed mail would become more common and maybe the default behavior because sysops sometimes share their configuration. It would be established over time as common practice or new standard. Nodes with software that can't support insecure compressed mail will have issues that they can't solve by their own. To avoid that issues they could write a fidonews article, hello world, i can't support your insecure compressed mail, please all nodes in the network switch off compression first if you want to send direct mail to me. Then all nodes need to check their configuration to switch of compression for that node. This would be a giant effort. AI>>> If I received mail from your node that I could not decompress I AI>>> would let you know that and also let you know what I can AI>>> decompress. KR>> Why did the other node not switched off compression if he knows KR>> that it would disturb netmail processing on your system? AI> I am not the arbiter of good/bad or right and wrong. You are wearing the *C hat. If you will do your best for fidonet as a whole then you can't avoid a little bit of decision what is best for fidonet as a whole. ;-) AI> I am not remotely qualified to make these kind of judgments. I did not judge at that point, i asked why. Trying to understand why people do something is the best way to learn about my own mistakes of prejustice. AI> Different nodes and software do things differently. I don't know why. I learned one reason. Becaue nobody told them that their way causes trouble. AI> I am just trying to get things done on my node in a good a reliable AI> way. You can. Your solution could be a batch or script file that uncompresses the mail from the *.sec bundle to the inbound you prefer and retrigger the hpt run again. That solution would effect your system only and in case of security breaches it is your system only that would be responsible. A modification for hpt would lower the security level on all systems that work with hpt. [always send uncompressed mail to insecure connects] KR>> And this is the working solution for any node within the network. AI> It may be a solution for you and your software but other nodes do AI> things differently. I do know that all other nodes have to process mail as per policy approved FTS-0001 and that they have to process type 2 formated packets without any differnce: "Any system which wishes to be a part of FidoNet must be able to [...] using the protocol defined in the current FidoNet Technical Standards Committee publication (FTS-0001 at this writing)." If they can't handle that they can't be a part of fidonet. AI> I see the minimum standards you speak of but policy doesn't get into AI> the subject of compression. "To conserve space and eliminate fields which would be meaningless if sent (e.g. timesRead), messages are *packed for transmission*. As this is a data structure which is *actually transferred*, its definition is *critical* to FidoNet." Packed to conserve space. Sounds exactly like compression to me. And this critial structure is transferred actually. (Looks like i have to withdraw my "no compression" term. ;) No, just kidding.) (packed type 2 messages are already supported by any fidonet tosser.) KR>> are you afraid to simply ask him to turn off compression?? AI> Why should I ask him to do that? KR>> You are part of the fidonet *C structure, you should have a KR>> smooth network operation on your priority list. My deepest KR>> apologies but i don't understand why you are acting the way you KR>> do. AI> I want to solve the simplest of issues. Not create more issues. One node sending insecure compressed mail, other nodes must work around. One node stops compression for sending insecure mail, other nodes do nothing. Pick the one with lesser issues. Regards Kai --- GoldED+/LNX 1.1.4.7 * Origin: Monobox (2:240/77) .