Subj : Netmail in the insecure inbound To : Kai Richter From : Alan Ianson Date : Thu Apr 29 2021 04:48:28 Hello Kai, KR>>> "2.1.8 Exclusivity of Zone Mail Hour AI>> No, I didn't ask for that. My own node accepts and tosses mail at AI>> all hours of the day including ZMH. KR> You told me that you do not know a standard for netmail compression. I KR> tried to help you by looking into the policy and quoted the parts that KR> could change your unknowingness. Policy takes no position on compression, and rightly so. KR> Obviously you stopped reading at the header and ignored the hooks that KR> are linked to fts-0001 to understand what kind of minimum standard is KR> set for fidonet. No, I read everything in your message. KR> I'll talk later about the "my node accepts" because i noted "my" KR> often. I will skip it for brevity. I am speaking to you from my thoughts and experiences I have had over time. 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. I have not rejected it. Every input and output from my node is compliant with our minimum standards. I may compress it for storage/delivery if a node is configured that way but I have not rejected anything in policy or fidonet standards and I never will. Why would I do that? 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". I say that because, I can (within reasonable limits). KR> That was not the question. The question was if the size of the KR> incoming test mails is large enough to justify compression. Neither is the size of these netmails. I forgot to answer that question last time. They were 0.5KB or so. They were simply packed into an arcmail bundle because that is the way some software works, not because they were large in size. KR>>> As proved by the policies we simply do not need to agree to KR>>> receive it. I don't see that in policy or fidonet standards. AI>> What proof, and what policy? KR> I qouted all relevant parts in the mail before. If your question is KR> serious please read it. Yes, you have spoken of ZMH and our minimum standards. All that is good and it has not been rejected. AI>> I bring it up for discussion with other users of the husky AI>> software for discussion and consideration only. KR> From my point of view there is a minimum standard for compression in KR> the policies. A minimum standard that is usefull for ALL fidonet KR> systems. Compression is not spoken of in policy and it doesn't need to. Fidonet nodes can arrange their links in a way that works for them. If a node sends mail here in an arcmail bundle we can decompress it. That is not and never was a problem. If my tosser can't/won't do it then I'll do it myself! KR> At the moment you are 1:153/0, and as far as i know wihout a NC-Flag KR> in the network you are the network coordinatior that was appointed to Yes, there are responsibilities that go with that. I find that all a pleasure and not a burden and while I am NC of net 153 I'll always do my best for the nodes in net 153, and as long as I am a node in fidonet I will do my best for fidonet as a whole. KR> by policy 4.07. We are talking about the minimum standard so you need KR> to have all systems in mind if we talk about netmail compression. You KR> must be able to receive netmail from any node. This is the issue you KR> brought on the table. This issue is not yours only, all NCs are KR> effected when we are searching for a standard. I have not and will not abandon any standards or minimum requirements. 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> Good solution. If i would know that your tosser does not unpack KR> insecure compressed netmail i would turn off compression immediately. KR> (Oh, wrong. I wouldn't. Because i didn't know what kind of unpacker KR> you could handle i would never send you compressed netmails.) But back KR> to telling, why didn't this work? Why did the other node not switched KR> off compression if he knows that it would disturb netmail processing KR> on your system? I am not the arbiter of good/bad or right and wrong. I am not remotely qualified to make these kind of judgments. Different nodes and software do things differently. I don't know why. I was not at the table when these decisions were made. I am just trying to get things done on my node in a good a reliable way. KR> And this is the working solution for any node within the network. It may be a solution for you and your software but other nodes do things differently. KR> Because it does work for any node this should be the minimum standard. What you are saying makes sense but there is no such standard that I have seen. If there was one then maybe we would not be having this conversation. KR> And because this was known since 30+ years this spirit can be found in KR> the policies. I see the minimum standards you speak of but policy doesn't get into the subject of compression. I don't think we need or want it to. KR> Hell, my jaw is falling down, you *guess* and you see no need to KR> talk?? I did actually write that sysop. I apologized to him for the delay and explained what happened. KR> Why are we talking then? I explained my problem with netmail not being tossed in the insecure inbound and here we are. If you don't reply I will understand. KR> Why are you searching for a solution here, That's what I have been wondering too. KR> are you afraid to simply ask him to turn off compression?? Why should I ask him to do that? KR> You are part of the fidonet *C structure, you should have a smooth KR> network operation on your priority list. My deepest apologies but i KR> don't understand why you are acting the way you do. I want to solve the simplest of issues. Not create more issues. KR> You can and you have to. That's your job as network coordinator. I think you are wrong and I am going to drop the rest of this here and now. Ttyl :-), Al --- GoldED+/LNX 1.1.5-b20180707 * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757) .