Subj : Netmail in the insecure inbound To : Kai Richter From : Alan Ianson Date : Sun May 02 2021 16:36:34 Hello Kai, KR> We are going to repeat us. You are still on the "i and my" point of KR> view. Who's point of view were you expecting? KR> You are the node that is NOT configured that way for compression. KR> The sender must not compress it. I agree with you, it is best to send insecure netmail in it's plain uncompressed format. Nevertheless, I sometimes (once or twice a month) receive netmail in my insecure inbound that is compressed so I must deal with it somehow. KR> Minimum definition in the policy is FTS-0001 type 2 packet format. These netmails were fully compliant with our minimum standards. The issue is a simple one, they were compressed into an arcmail bundle that needs to be decompressed before the packets can be tossed. The questions is "is it desirable to decompress those packets" in the insecure inbound. KR> You told us you have never talked about compression to that node, so KR> this node never got your agreement for compression and because of that KR> he must stick on FTS-0001 without compression. No, he/she didn't. They don't need my agreement. As long as they use a common archive tool I will simply decompress arcmail bundles. 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. What rule? If you can quote policy or fidonet standards that say that archiving mail is bad, or wrong I will change my position. I have not read that in policy or standards, so I can't get on board. KR> I think we made a mistake when we started the discussion with a focus KR> on compression. The more important issue is insecure inbound. Yes, I receive netmail in my insecure inbound that is not tossed until I decompress it. KR> That's too bad. So size couldn't be put on the "pro compression" list. Yes, this is not a concern. AI>> Compression is not spoken of in policy and it doesn't need to. KR> It does need because it must be sure that both parties can process the KR> mail. That's why the the format is defined by policy and compression KR> is not part of the defined format. If there is need then the policy needs to updated. That would not be an easy thing to do in fidonet. I would be agreeable to that also but in the mean time the issue I reported remains. KR> That's the point. Compressed insecure inbound does not work reliable KR> on all systems. How is that? I have not had issues decompressing mail. The only issue is that it sits in my insecure inbound until I find it there. KR> Compressed mail CAN be arranged optional AFTER agreement. Sure, node can arrange things as they need. KR> This would tell us what the minimum configuration for fidonet software KR> is and what kind of configuration is an optional enhancement. The setup of other fidonet nodes is beyond my control. I don't think arcmail bundles are good or bad. I only know that when an arcmail bundle arrives in my inbound I need to decompress it. AI>> If a node sends mail here in an arcmail bundle we can decompress AI>> it. That is not and never was a problem. KR> You told me you don't know the Pyra. What about the future? You can't KR> say we can if you don't know what we can do. I might experiment with exotic hardware or software. If I was using Pyra in Fidonet I would stick to the standards. Type 2 packets and arcmail bundles are standard Fidonet fair. KR> Sure you can. But i have to remind you that you asked for a solution KR> that does not effect your system only: I agree. The husky developers have to keep the big picture in mind and I think they have always done that. AI>> I wonder if it is possible for hpt to unpack those arcmail AI>> bundles and toss the packets within if they are netmail. KR> You want to have a change in a security feature of a software that is KR> used by many nodes. This is a change that is far beyond of "my KR> system". Yes it does. I am not a husky developer and am going to make no changes. KR>>> You must be able to receive netmail from any node. This is the KR>>> issue you brought on the table. This issue is not yours only, KR>>> all NCs are effected when we are searching for a standard. I don't think we are searching for a standard. The standards are all in place. AI>> I have not and will not abandon any standards or minimum AI>> requirements. KR> Not yet, sure. But you asked for the first step into that direction. KR> Let's say hpt does have build in support for insecure compressed mail. KR> Then this software that does send compressed mail without prior KR> agreement by both nodes will contiune with less issues. Insecure KR> compressed mail would become more common and maybe the default KR> behavior because sysops sometimes share their configuration. It would KR> be established over time as common practice or new standard. I think that is the case now. An arcmail bundle is no surprise and it may contain netmail and/or echomail. I think that has been the case for a very long time. KR> Nodes with software that can't support insecure compressed mail will KR> have issues that they can't solve by their own. That is why I don't compress netmail. Of course that doesn't mean it doesn't happen. I am familiar with a number of different software used in fidonet. Sometimes they just go ahead and compress netmail/echomail and then send it to the destination. It would be best if they didn't do that but I am in no position to change that behaviour. I don't mind discussing that with with the author of the software and asking them to consider a change but that depends on those authors listening to what I have to say and ... KR> To avoid that issues they could write a fidonews article, hello world, KR> i can't support your insecure compressed mail, please all nodes in the KR> network switch off compression first if you want to send direct mail KR> to me. Then all nodes need to check their configuration to switch of KR> compression for that node. This would be a giant effort. They could start by talking the node that sent the compressed mail and I'm sure the node would arrange uncompressed mail for them. It would be a big effort to change the habits of fidonet nodes and I don't know if that effort would be met with much success or not. Not because fidonet nodes are bad but because fidonet nodes software works the way it does along with the setup fidonet nodes have put in place. AI>> I am not the arbiter of good/bad or right and wrong. KR> You are wearing the *C hat. If you will do your best for fidonet as a KR> whole then you can't avoid a little bit of decision what is best for KR> fidonet as a whole. ;-) Yes, I have been given the NC 153 hat for now. Lets discount those responsibilities for this discussion. N153C or not, I am a fidonet node and fidonet is important to me. I will always conduct myself in a way that is good for my own node and fidonet generally. KR> I learned one reason. Becaue nobody told them that their way causes KR> trouble. Does it actually cause trouble? KR> You can. Your solution could be a batch or script file that KR> uncompresses the mail from the *.sec bundle to the inbound you prefer KR> and retrigger the hpt run again. That solution would effect your KR> system only and in case of security breaches it is your system only KR> that would be responsible. Yes, I have thought about that. Until now I am simply making my way to my insecure inbound and decompressing bundles I find there and doing what needs to be done. KR> A modification for hpt would lower the security level on all systems KR> that work with hpt. If decompressing arcmail bundles is a security risk then we don't want to do that. I am not suggesting that hpt should act in an insecure way. If it did that I wouldn't use it. KR> I do know that all other nodes have to process mail as per policy KR> approved FTS-0001 and that they have to process type 2 formated KR> packets without any differnce: We are doing that. KR> "Any system which wishes to be a part of FidoNet must be able to [...] KR> using the protocol defined in the current FidoNet Technical Standards KR> Committee publication (FTS-0001 at this writing)." KR> If they can't handle that they can't be a part of fidonet. True, but that is not the case so they can be part of fidonet. AI>> I see the minimum standards you speak of but policy doesn't get AI>> into the subject of compression. KR> "To conserve space and eliminate fields which would be meaningless KR> if sent (e.g. timesRead), messages are *packed for transmission*. As KR> this is a data structure which is *actually transferred*, its KR> definition is *critical* to FidoNet." Yes, those minimum standards are critical and they have not been set aside. KR> Packed to conserve space. Sounds exactly like compression to me. And KR> this critial structure is transferred actually. It sounds like compression because that is what it is. Compression is not a bad thing. I only compress packets when a node is configured for that and most are, even today. KR> (Looks like i have to withdraw my "no compression" term. ;) No, just KR> kidding.) (packed type 2 messages are already supported by any fidonet KR> tosser.) A packed message is not an arcmail bundle. They are two different things. 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. It is. The network is operating smoothly here, even if mail is compressed. AI>> I want to solve the simplest of issues. Not create more issues. KR> One node sending insecure compressed mail, other nodes must work KR> around. One node stops compression for sending insecure mail, other KR> nodes do nothing. There maybe troubles to be had, but arcmail bundles are not it. Ttyl :-), Al --- GoldED+/LNX 1.1.5-b20180707 * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757) .