Subj : Netmail in the insecure inbound To : Alan Ianson From : Kai Richter Date : Mon May 03 2021 19:45:46 Hello Alan! 02 May 21, Alan Ianson wrote to Kai Richter: KR>> We are going to repeat us. You are still on the "i and my" point KR>> of view. AI> Who's point of view were you expecting? The one of an disinteressted party or a neutral observer. You already stated that you have the whole of fidonet in view. Back to the start i did understand that you were asking for a change in a security feature of hpt that would effect many nodes. Having the whole fidonet in view i started to argue. Just for confirmation and to avoid misunderstanding: I do not have any issues what your system only would do with non-secure inbound files locally. If you think that automatic process of insecure inbound is not a risk you could do what you want because at last you are responsible for what your system will send to others. The only advice i'd like to mention is that there is a reason why binkd and tossers do support security features with password protection. KR>> You are the node that is NOT configured that way for compression. KR>> The sender must not compress it. AI> I agree with you, it is best to send insecure netmail in it's plain AI> uncompressed format. KR>> Minimum definition in the policy is FTS-0001 type 2 packet KR>> format. AI> These netmails were fully compliant with our minimum standards. The AI> issue is a simple one, they were compressed into an arcmail bundle AI> that needs to be decompressed before the packets can be tossed. Mailers do not receive netmails they receive files only. The file that have been transfered to you is an arcmail archive. "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." The FTS requirement is to transfer that data structure of packed messages. That transfered arcmail archive is not in compliance with the FTS-0001 standard. AI> The questions is "is it desirable to decompress those packets" in the AI> insecure inbound. Generally spoken without further context i would answer with "No because of security reasons". KR>> You told us you have never talked about compression to that node, KR>> so this node never got your agreement for compression and because KR>> of that he must stick on FTS-0001 without compression. AI> No, he/she didn't. They don't need my agreement. As long as they use a AI> common archive tool I will simply decompress arcmail bundles. The question is what the whole fidonet can. Do you remember? We have the whole fidonet view active. And please remember "when" we are now. We are at the first connect between two nodes that do not have an idea what is working on the other side. None of them would know what archiver the other side hates and rejects to support. So both needs to stick on the FTS-0001 level to ensure that the other one could read their mail. AI>>>>> Echomail/netmail may arrive compressed or uncompressed. If AI>>>>> that mail is compressed I don't think any rules have been AI>>>>> broken. KR>>>> I do. AI> What rule? I wrote that in detail in the mail where i said i do. AI> If you can quote policy or fidonet standards that say that AI> archiving mail is bad, or wrong I will change my position. See above. 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 KR>> process the mail. That's why the the format is defined by policy KR>> and compression is not part of the defined format. AI> If there is need then the policy needs to updated. Why did you stopped reading after the first sentence? I said it does need because it must be sure that both parties can process the mail - this is the reason why something must be defined. And then i said that's why the the format is defined by policy - that is written in the policy now. Finally and compression is not part of the defined format - so there is no reason to update the policy because all important things for first connects is there. AI> That would not be an easy thing to do in fidonet. I would be AI> agreeable to that also By now i'm going to think you don't really know what you are doing. Put that on the table seriously and it would kill half of the fidonet by violent fits of laughter. ;-) KR>> That's the point. Compressed insecure inbound does not work KR>> reliable on all systems. AI> How is that? Due to the negotation of "yes, i can guarantee that -all nodes can run any archiver -all nodes allow anything for insecure inbound because it's save -all nodes check their insecure inbound every hour/day/whatever" All that is wrong and i have no idea if or when compressed insecure archives will be processed. KR>> and maybe the default behavior because sysops sometimes share KR>> their configuration. It would be established over time as common KR>> practice or new standard. AI> I think that is the case now. An arcmail bundle is no surprise and it AI> may contain netmail and/or echomail. And now the importent part: For secure links. If i do a negotiation with the other node first we can set our passwords and agree on the used compression software. We have full automatic mailflow without manual interaction because we switched to secured connects. KR>> Nodes with software that can't support insecure compressed mail KR>> will have issues that they can't solve by their own. AI> That is why I don't compress netmail. Whole fidonet view, nobody should compress netmail for insecure connects. AI> It would be best if they didn't do that but I am in no position to AI> change that behaviour. But you can talk about the problem. You could simply ask for turning off compression or you could offer a secure link. KR>> I learned one reason. Becaue nobody told them that their way KR>> causes trouble. AI> Does it actually cause trouble? 3x ~10k mails are an indicator those days. ;-) But i'm willing to correct to "can cause trouble". Edit: And after saving i see #3 is 6,5K only. KR>> (Looks like i have to withdraw my "no compression" term. ;) No, KR>> just kidding.) (packed type 2 messages are already supported by KR>> any fidonet tosser.) AI> A packed message is not an arcmail bundle. They are two different AI> things. Oh. I should keep that in mind. Regards Kai --- GoldED+/LNX 1.1.4.7 * Origin: Monobox (2:240/77) .