Subj : Netmail in the insecure inbound To : Alan Ianson From : Kai Richter Date : Wed Apr 28 2021 00:23:54 Hello Alan! 26 Apr 21, Alan Ianson wrote to Kai Richter: [netmail compression] AI>>> Perhaps we need a standard of some sort but there is none that I AI>>> know of. KR>> You asked for this part: 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 all AI> hours of the day including ZMH. You told me that you do not know a standard for netmail compression. I tried to help you by looking into the policy and quoted the parts that could change your unknowingness. Obviously you stopped reading at the header and ignored the hooks that are linked to fts-0001 to understand what kind of minimum standard is set for fidonet. I'll talk later about the "my node accepts" because i noted "my" often. AI> We could talk about fido policy if you like, privately in netmail or AI> the FIDOPOLS or FN_SYSOP area but I would rather not do that here. There is no need for. I don't want to discuss the policy, i quoted the parts as a reference for the minimum standard. AI> There is nothing in policy or FTN standards as far as I know. And if you reject to read it in context you would never know it. AI> Echomail/netmail may arrive compressed or uncompressed. If that mail AI> is compressed I don't think any rules have been broken. I do. I think you can't see it because... AI> I can decompress ....you are focused on "i can" or "my node". KR>> Well, to be honest, i'd like to stop here but the echopol KR>> continues then: KR>> "SEA's ARC 5.1 (non-Squashing) archival storage format will be AI> I still have arc on my path to extract an arc compressed mail bundle AI> but I haven't seen an arc bundle in years. I know and i did wrote that some parts of the policies are outdated before. But the important thing was the basic concept of compression use. AI> I do have The basic concept of the policies is not focused on "i". KR>> Just like compressed netmail is not. If you receive test mails KR>> only, what size do they have that would need compression? AI> This is not my choice or configuration. Mail arrives in my inbound as AI> it is. That was not the question. The question was if the size of the incoming test mails is large enough to justify compression. And again i do see a "my" positon. AI>>> When mail arrives compressed then we simply need to decompress AI>>> it. KR>> As proved by the policies we simply do not need to agree to KR>> receive it. AI> What proof, and what policy? I qouted all relevant parts in the mail before. If your question is serious please read it. AI>>> Yes, it would. HPT works this way by default but not all AI>>> tossers/mailer do and we need to work with what we get. KR>> No, definitly not. AI> This may very well be a "Won't fix" issue. AI> In fact this is my issue and the solution must be mine. I hope I will AI> have help to solve that but maybe there is no solution. Again i see "i" and "my" and the first step for help should be to tell you to raise your head up from the narrow focus of "i and my" and get a distant point of view to see not only your system but to look what is or should go on in the fidonetwork. AI> I bring it up for discussion with other users of the husky software AI> for discussion and consideration only. And so i answered. My contribution to the discussion is now to tell a network coordinatior to step into the network coordination view mode. The question is not what a good solution for "your" system is. You already thought into the right direction when asking if there is some minimum standard. From my point of view there is a minimum standard for compression in the policies. A minimum standard that is usefull for ALL fidonet systems. KR>> Do you really want to be forced to handle anything i throw to KR>> your system? AI> What you describe is a different issue. I am not forced to handle mail AI> for any node. At the moment you are 1:153/0, and as far as i know wihout a NC-Flag in the network you are the network coordinatior that was appointed to 1.2.3 Networks and Network Coordinators [...] The Network Coordinator is responsible for maintaining the list of nodes for the network, and for *forwarding netmail sent to members of the network from other FidoNet nodes.* by policy 4.07. We are talking about the minimum standard so you need to have all systems in mind if we talk about netmail compression. You must be able to receive netmail from any node. This is the issue you brought on the table. This issue is not yours only, all NCs are effected when we are searching for a standard. KR>> What if i use an archive format that requires to pay a serious KR>> ammount of money for registration? AI> You can use any archive method I have mentioned. You put on the "i" glasses again. Btw, you are doing right in this moment what is the minimum standard as per policies, you do agree what kind of compression should be used between your systems. And now, after we both agreed, the compression is in compliance with the minimum standard. AI> If I received mail from your node that I could not decompress I would AI> let you know that and also let you know what I can decompress. Good solution. If i would know that your tosser does not unpack insecure compressed netmail i would turn off compression immediately. (Oh, wrong. I wouldn't. Because i didn't know what kind of unpacker you could handle i would never send you compressed netmails.) But back to telling, why didn't this work? Why did the other node not switched off compression if he knows that it would disturb netmail processing on your system? KR>> Do you really know who "we" are? AI> I know you and others only from what I have read from you. I have read AI> nothing from you that makes me think I should be worried. I have to say sorry if i used any wording that could be taken as offense. I still have the technical fidonet operation in mind. So "we" are any node that may send netmail. You and i doesn't have an idea what kind of systems or what kind of compression software could be out there. KR>> Do you know which machines are used for node operation? KR>> My node did run on a P1/133 with 32MB RAM for a long time. AI> I would not send mail to your node that was compressed in a way you AI> could not decompress it. You or any node. I would not do this, too. And because i do not know what kind of compression the receiving node can handle i would never turn it on for unsecure connects. And this is the working solution for any node within the network. Because it does work for any node this should be the minimum standard. And because this was known since 30+ years this spirit can be found in the policies. AI> I do not wish any node delisted, I just want to unpack and toss mail. I wish that nodes prefer interaction and find a way to create a reliable amateur electronic mail network. This includes password protected links or uncompressed insecure netmail. AI>>> I could only guess since the sysop hasn't told me, so I won't do AI>>> that. I can and do talk to this sysop at times so if there is AI>>> need to talk we will. KR>> Then talk to him. There is need. AI> There is no need, he has done nothing wrong. Then why and what about are we talking here? Without offense, from a distant all fidonet including overview, he does it wrong. It's his fault that we both are wasting our time about "no issue". AI> I will likely talk to this sysop again but I doubt we will discuss AI> this, because there is no need. Hell, my jaw is falling down, you *guess* and you see no need to talk?? Why are we talking then? Why are you searching for a solution here, are you afraid to simply ask him to turn off compression?? You are part of the fidonet *C structure, you should have a smooth network operation on your priority list. My deepest apologies but i don't understand why you are acting the way you do. AI> I cannot change the behaviour of other nodes You can and you have to. That's your job as network coordinator. AI> or software in use, and I have no desire to do that. KR>> He does annoy the network. AI> I have not been annoyed by this node. I am. I was crawling through policies again, it took hours to collect everything, including dictionary and translation time. I'd like to help, just for fun and it did make me happy as i saw that my idea to use ssh access did lead a ru developer to an us raspi what resulted into a fix for the husky build process. I'd like to see that people are still working together to keep fidonet up and running. And now this node wasted my time for nothing. Both of you will not work together, now it's my time for guessing he will continue to send other nodes unsecure compressed netmails and will cause trouble that could be avoided by a simple switch. AI> I simply bring up my experience for discussion and consideration. But you are not discussing with the source of the issue. AI> We are talking about a well respected (at least be me) fido node who AI> does indeed know what he is doing. Obviously not. His behavior is the inital trigger for this discussion. It is not my intention to blame anyone and network operation does work with respect only. In our case respect to the policies and to common sense. Network operation is based on yes or no descisions and raising the minimum standard to insecure compressed netmail support is a bad idea because the potential of systems that could not support this. We found that for that reason you and i would never send insecure compressed netmail. I call that a serious well argumented reason that will be handled by any fidonet system. KR>> Anyone and you can. TALK WITH HIM! Do what fidonet is for. KR>> Communicate! AI> That is what I do, and what I am doing. I missed that. What did he said? Why he don't turn off compression? KR>> I explained above that sending insecure compressed netmail and so KR>> he is annoying according fidonets common practice and policies. AI> I don't find netmail (compressed or not) annoying, and I don't read AI> anything in policy or fidonet standards that makes compressed netmail AI> annoying. I quoted the parts that display that. The important thing of the ZMH is not the time in this case. (The ZMH is the heart of FidoNet [...] Any system which wishes to be a part of FidoNet must be able to receive mail during this time *using the protocol defined in the current FTSC publication (FTS-0001)*) The core elements for our question are the minimum protocols per FTS-0001 and those doesn't include compression. Vice versa you need to send uncompressed mail to make sure that it will be received. Regards Kai --- GoldED+/LNX 1.1.4.7 * Origin: Monobox (2:240/77) .