Subj : Netmail in the insecure inbound To : Kai Richter From : Alan Ianson Date : Mon Apr 26 2021 16:45:34 Hello Kai, AI>> Mail arrives in my inbound as it is prepared by other nodes. This AI>> is not a configuration or choice on my part. KR> Let's say yes, true. I don't want to switch to bastard operator from KR> hell mode. That path would end in destruction. Yes it does. I do not want to be or link with the bastard operator from hell. AI>> Perhaps we need a standard of some sort but there is none that I AI>> know of. KR> If you are really interested i'd like to recommend the fidonet policy. KR> This is Fidonets initial document. It's latest approved version is KR> 4.07 of 1989. Some things may be outdated today but the basics are KR> still displayed. KR> You asked for this part: KR> "2.1.8 Exclusivity of Zone Mail Hour No, I didn't ask for that. My own node accepts and tosses mail at all hours of the day including ZMH. We could talk about fido policy if you like, privately in netmail or the FIDOPOLS or FN_SYSOP area but I would rather not do that here. KR> There are historical reasons why echomail handling with or without KR> compression is not found in the policy. There is nothing in policy or FTN standards as far as I know. Echomail/netmail may arrive compressed or uncompressed. If that mail is compressed I don't think any rules have been broken. I can decompress zip, arc, arj and rar archives if they arrive here like that but I only use zip to compress mail if a node wants it that way. That seems to be enough in my experience. KR> Well, to be honest, i'd like to stop here but the echopol continues KR> then: KR> "SEA's ARC 5.1 (non-Squashing) archival storage format will be the KR> "fallback" if either party is unable or unwilling to support an KR> alternate method. I still have arc on my path to extract an arc compressed mail bundle but I haven't seen an arc bundle in years. AI>> I periodically get/send netmail to nodes I am not linked with. AI>> It's not possible or desirable to link and secure to every node AI>> for possible periodic netmails. KR> Well, true but why don't you use your secoured links and set up KR> routing? I do have links for secure routing and it is used at times. When netmail arrives in my inbound it follows my routing rules. When I write a netmail and I want to be sure it is received in a timely way I will crash it directly to the node. That is easy to do today and it doesn't cause excessive phone bills like it did in the past. AI>> Secure links for possible periodic netmail is not necessary. KR> Just like compressed netmail is not. If you receive test mails only, KR> what size do they have that would need compression? This is not my choice or configuration. Mail arrives in my inbound as it is. 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 receive KR> it. What proof, and what policy? KR>>> This would work without any issues if the sender disables KR>>> netmail 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. KR> No, definitly not. This may very well be a "Won't fix" issue. In fact this is my issue and the solution must be mine. I hope I will have help to solve that but maybe there is no solution. I bring it up for discussion with other users of the husky software for discussion and consideration only. KR> Do you really want to be forced to handle anything i throw to your KR> system? What you describe is a different issue. I am not forced to handle mail for any node. KR> What if i use an archive format that requires to pay a serious ammount KR> of money for registration? There is none yet? I'd like to write it, it KR> should be easy merge open source zip and pgp to force you to buy the KR> decryp... decompression key. You can use any archive method I have mentioned. It's possible I could also use LHA or ZOO if a node really needed it, but I don't think anyone wants or needs it today. If I received mail from your node that I could not decompress I would let you know that and also let you know what I can decompress. KR> Do you really know who "we" are? I know you and others only from what I have read from you. I have read nothing from you that makes me think I should be worried. 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. An actual KR> compression format that would require 66MB for decompression would KR> crash the system. I would not send mail to your node that was compressed in a way you could not decompress it. You or any node. KR> If there are tossers that can not turn off compression then they do KR> not conform to the minimum standards of fidonet. Any sysop who use KR> such software risks his node number. This not my configuration or choice to make. I do not wish any node delisted, I just want to unpack and toss mail. 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. There is no need, he has done nothing wrong. I will likely talk to this sysop again but I doubt we will discuss this, because there is no need. I cannot change the behaviour of other nodes or software in use, and I have no desire to do that. KR> He does annoy the network. I have not been annoyed by this node. KR> He forces you to ask for a change in software operation. It may result KR> into developer work, wasting valueable dev time for one unwitting KR> sysop. There has been no force, or need for force. I simply bring up my experience for discussion and consideration. KR> (i found unwitting by translator. i hope that stands for "he doesn't KR> know what he's doing".) We are talking about a well respected (at least be me) fido node who does indeed know what he is doing. KR> Then why it is now? This "new" fault is no issue on your system. I don't think this is new. Once in a while I need to decompress mail in my insecure inbound. I suspect that may happen at other nodes also from time to time. KR> Anyone and you can. TALK WITH HIM! Do what fidonet is for. KR> Communicate! That is what I do, and what I am doing. KR> I explained above that sending insecure compressed netmail and so he KR> is annoying according fidonets common practice and policies. I don't find netmail (compressed or not) annoying, and I don't read anything in policy or fidonet standards that makes compressed netmail annoying. Ttyl :-), Al --- GoldED+/LNX 1.1.5-b20180707 * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757) .