Subj : Netmail in the insecure inbound To : Alan Ianson From : Kai Richter Date : Mon Apr 26 2021 20:45:54 Hello Alan! 25 Apr 21, Alan Ianson wrote to Kai Richter: AI> Mail arrives in my inbound as it is prepared by other nodes. This is AI> not a configuration or choice on my part. Let's say yes, true. I don't want to switch to bastard operator from hell mode. That path would end in destruction. AI> I always send netmail uncompressed for both secure and insecure AI> sessions. AI> Perhaps we need a standard of some sort but there is none that I know AI> of. If you are really interested i'd like to recommend the fidonet policy. This is Fidonets initial document. It's latest approved version is 4.07 of 1989. Some things may be outdated today but the basics are still displayed. You asked for this part: "2.1.8 Exclusivity of Zone Mail Hour Zone Mail Hour is the heart of FidoNet, as this is when network mail is passed between systems. 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 FidoNet Technical Standards Committee publication (FTS-0001 at this writing). It is permissible to have greater capability (for example, to support additional protocols or extended mail hours), but the minimum requirement is FTS-0001 capability during this one hour of the day. This time is exclusively reserved for netmail." FTS-0001 is on revision 16 of 1995 and is the definition of the *.pkt format. A packet is a bundle of messages that is stored in the type 2 packet format. (see line 462 and on) Within the introduction text FTS-0001 is open for the future: "2. Levels of Compliance This documents represents the most basic FidoNet implementation. A future document will define well tested extensions which are optional but provide sufficient additional function that implementors should seriously consider them. SEAdog(tm), from System Enhancement Associates, is an excellent example of such an extended FidoNet implementation." Today seadog is outdated in network operation but the minimum definition as most basic implementation for type 2 packets does still apply. There are historical reasons why echomail handling with or without compression is not found in the policy. Based on the phone line cost structure in some/many/all?? countries of the USA a local area call was free of additional cost. This is why the host structure was implemented. There was one system responsible for long distance calls and so mass transportation was done by one system only. Local systems didn't need to think about costs and so compression was never required. I'm not sure about how the echomail policy was build but this echopol shows how to handle compression: "11. ECHOMAIL SOFTWARE: EchoMail exchanges may consist of any type of archival storage format agreed upon by both parties." This is the key element, any other archival format can be used if both sysops agree. Well, to be honest, i'd like to stop here but the echopol continues then: "SEA's ARC 5.1 (non-Squashing) archival storage format will be the "fallback" if either party is unable or unwilling to support an alternate method. The continued use of Echomail software without prior agreement of both the sending and receiving nodes which interferes with the distribution of echomail shall lead to disciplinary action as described previously in this document. See Section III. Examples of prohibited software would include the use of non-standard echomail packets which can not be processed by the receiving system." With enough compression fanatism someone could shout now: "look, ARC is the fallback when the other side is unable to support my compression". But if we consider all of the text then the main purpose of the echopol would rise: Make sure that echomail can be processed. AI>>> I get/send netmail to/from that node periodically. I would be AI>>> happy to link with that node if there was any reason to. KR>> There is. A periodical link should be secured. AI> I periodically get/send netmail to nodes I am not linked with. It's AI> not possible or desirable to link and secure to every node for AI> possible periodic netmails. Well, true but why don't you use your secoured links and set up routing? AI> Secure links for possible periodic netmail is not necessary. Just like compressed netmail is not. If you receive test mails only, what size do they have that would need compression? AI> When mail arrives compressed then we simply need to decompress it. As proved by the policies we simply do not need to agree to receive it. KR>> This would work without any issues if the sender disables netmail KR>> compression. 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. No, definitly not. Do you really want to be forced to handle anything i throw to your system? What if i use an archive format that requires to pay a serious ammount of money for registration? There is none yet? I'd like to write it, it should be easy merge open source zip and pgp to force you to buy the decryp... decompression key. Do you really know who "we" are? Do you know which machines are used for node operation? My node did run on a P1/133 with 32MB RAM for a long time. An actual compression format that would require 66MB for decompression would crash the system. If there are tossers that can not turn off compression then they do not conform to the minimum standards of fidonet. Any sysop who use such software risks his node number. AI>>> This sysop, I suspect just wanted to test the route on the AI>>> return trip. No need to talk about that. KR>> Then what is this for? Why should someone do a connect if there KR>> is nothing to talk? There is no need to build a road if nobody KR>> travels. Paths build up because many are going in the same KR>> direction. AI> I could only guess since the sysop hasn't told me, so I won't do that. AI> I can and do talk to this sysop at times so if there is need to talk AI> we will. Then talk to him. There is need. He does annoy the network. He forces you to ask for a change in software operation. It may result into developer work, wasting valueable dev time for one unwitting sysop. (i found unwitting by translator. i hope that stands for "he doesn't know what he's doing".) AI> I am not asking anyone to travel anywhere they don't want/need to AI> travel. Then don't follow him if he don't want to travel with us. KR>> The problem is unsecured inbound compressed netmail. AI> I need to decompress archived netmail, that has never been a problem. Then why it is now? This "new" fault is no issue on your system. AI>>> and if there is I would like to get to work on the solution. KR>> The solution is turn off compression and/or turn off not KR>> necessary tests. AI> I don't compress netmail here. I could if a node asked for that but AI> none have so it doesn't happen here. Like any node I can control AI> output but not input. Anyone and you can. TALK WITH HIM! Do what fidonet is for. Communicate! I explained above that sending insecure compressed netmail and so he is annoying according fidonets common practice and policies. Regards Kai --- GoldED+/LNX 1.1.4.7 * Origin: Monobox (2:240/77) .