Hello Kai,

 AI>> Netmail that arrives uncompressed is tossed from the insecure
 AI>> directory.

 KR> There your solution is. Get the netmail uncompressed.

Mail arrives in my inbound as it is prepared by other nodes. This is not a configuration or choice on my part.

 KR> Tossing uncompressed insecure netmail is the lowest level to establish
 KR> first communication with the other sysop. It needs to work on any
 KR> system.

Yes, it does.

 KR> Even if your mailer log told you that you are connecting to a linux
 KR> binkd that doesn't force the tosser to be on a linux machine. Some
 KR> systems are sharing the inbound to another system where the tosser
 KR> works. You have no idea if the other side can handle the compression
 KR> format that you use. You need to find a minimum standard and the
 KR> easiest minimum standard is no compression.

Yes, it is.

I always send netmail uncompressed for both secure and insecure sessions.

Perhaps we need a standard of some sort but there is none that I know of. I sometimes receive netmail compressed. In the fidoverse a lot of netmail is compressed, with zip in most cases. I have no problem decompressing those files.

 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.

I periodically get/send netmail to nodes I am not linked with. It's not possible or desirable to link and secure to every node for possible periodic netmails.

 KR> Negeotation with the other sysop would set your passwords, the
 KR> compression format and the route. I recommend to set a private
 KR> nodelist too, just to avoid any further troubles with the official
 KR> nodelist.

Secure links for possible periodic netmail is not necessary. Even when linked the choice to archive or not is left with the node to make that choice. When mail arrives compressed then we simply need to decompress it.

 KR> This would work without any issues if the sender disables netmail
 KR> compression.

Yes, it would. HPT works this way by default but not all tossers/mailer do and we need to work with what we get.

 AI>> This sysop, I suspect just wanted to test the route on the return
 AI>> trip. No need to talk about that.

 KR> Then what is this for? Why should someone do a connect if there is
 KR> nothing to talk? There is no need to build a road if nobody travels.
 KR> Paths build up because many are going in the same direction.

I could only guess since the sysop hasn't told me, so I won't do that. I can and do talk to this sysop at times so if there is need to talk we will.

I am not asking anyone to travel anywhere they don't want/need to travel.

In the case of ping/trace we are trying to find and solve issues with netmail routing. This seems to be an ongoing battle. In my own case the problem has been my own configuration and these pings can help me identify and fix those problems.

As it stands today I believe my route files is in good condition and in every case mail that arrives here will be sent towards it's destination via a secure and trusted link.

 KR> As far as i noticed there was a testing run by someone visible at
 KR> enet.sysop. According to my logfiles i was effected too. I received a
 KR> netmail from a point system that was destinated to another point
 KR> system. Why?? If we all throw our mails to anyone how could we believe
 KR> that it would ever reach it's destination? This sysop simply wasted
 KR> our time because he didn't use the standard secured routing. And he
 KR> doesn't know the networks structure and function of hosts. From my
 KR> point of view he does need someone to talk and who gives an
 KR> introduction for ftn based networks.

Looking at that from the outside that seems a useless test, something to be avoided. The ping functionality available here is advertised in the nodelist and available to any node who would like to use it in the hopes it will be useful and productive.

 KR> The problem is unsecured inbound compressed netmail.

I need to decompress archived netmail, that has never been a problem.

 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 necessary
 KR> tests.

I don't compress netmail here. I could if a node asked for that but none have so it doesn't happen here. Like any node I can control output but not input. It arrives in my inbound as prepared by other tossers and mailers and they can and do behave differently than my own tosser/mailer.

 Ttyl :-),
         Al

--- GoldED+/LNX 1.1.5-b20180707