Subj : Compressed netmail in the insecure inbound To : Kai Richter From : Alan Ianson Date : Tue May 04 2021 19:30:25 Hello Kai, KR> There is no content to transfer. You don't need a road if nobody KR> travels. That is incorrect. There is content to transfer. KR> Your actual scenario is two machines that have a road that is used for KR> nothing more that to prove "look, there is a road". In the case of ping we want to know if the road is open. To that end I just sent a ping to a node I want to communicate with and am just awaiting a reply. If I don't get a reply to that ping I will send the mail directly. KR> Do one step back and get aware that insecure compressed ping creates KR> problems for no reason other than to have a problem to be solved. Ping creates no problems at all whether it is sent/received directly or routed. It is just a tool available to us. KR> Now the cat is out of the bag. You really do want to change the KR> default behavior of the whole fidonet for insecure compressed mail. That is up to the husky developers. I am only trying to solve the issue I reported. The husky developers may have read my comments, I don't know. But I have not asked them to change anything, and I will not. AI>> I agree with you that nodes should always send netmail AI>> uncompressed KR> Then please follow this path. It is the solution with no issues. This is the path I am on, as I said. Repeatedly. KR> Be a good coordinator and teach selfish nodes why to turn off KR> compression for insecure netmail. Do not support their annoying KR> behavior by working around. Selfish nodes? I will certainly suggest this to nodes when I can do that. I think that's the right thing to do. I don't think I am in any kind of position to change the way this does happen in fidonet. KR> You are going to force the whole fidonet to support compression. I suggested nothing of the sort. Individual nodes can and will support the compression methods they choose, if any. KR> You can do what ever you will on your system but stop forcing me/us to KR> support compression. You don't know what is running on "our" side. I am not, and will not force anything on anyone. KR> There is no arc support for the Pandora, for example. KR> http://repo.openpandora.org/?page=all&search=unarc KR> What will be then? Would you simply say i'm no longer part of fidonet KR> if i can't support compression? Of course not. Why do you suggest that I would? KR> Or will you invent a "noarc" flag for the nodelist that any node does KR> know that i do not support compression? I would not invent a noarc flag for several reasons. A netmail will leave my node uncompressed but it may be compressed along the way, this is beyond my control. That may or may not be a problem for the destination node. KR> You intention for easy going with compressed insecure mail will KR> backfire then because you have to install the "unarc" flag condition KR> to the whole fidonet systems including yours. See the top of this KR> mail, you're creating issues where are none. I am creating no issues. Archived netmail is in my insecure inbound and I need to decompress it so it can be tossed. AI>> I find no policy or FTN standard that directs nodes not to do AI>> that and that is why it happens. KR> I showed you two times already. The *transfer*! format is defined by KR> FTS-0001. If a node transfers an arcmail bundle to my node (as we are discussing here), has any policy or standard been violated? KR> Compression after agreement is defined by the echopol and that is a KR> freedom i'd like to see for the whole fidonet. You can use any KR> compression tool you like if both parties agree. What echopol? My own use of compression/decompression (if needed) is not defined by echopol. It is simply used as needed. KR> If one does not agree or the parties never talked about compression KR> before then no compression is the solution that will work on the whole KR> fidonet. I agree with you. Nevertheless there is compressed mail in my insecure inbound that sits there until I find and deal with it. Ttyl :-), Al --- GoldED+/LNX 1.1.5-b20180707 * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757) .