Subj : routing issues?
To   : Kai Richter
From : Alan Ianson
Date : Mon May 03 2021 16:36:36

Hello Kai,

 KR>>> If there is no conversation between the nodes then there is no
 KR>>> problem that needs to be solved.

 AI>> I don't know what that is supposed to mean.

 KR> As far as i understood there was no conversation between the node with
 KR> the compressed ping netmail and you. If you both don't talk then you
 KR> both don't need a connect.

The connects do happen. That is not a problem. The issue is netmail that is compressed, the recipient is irrelevant.

 KR>>> Insecure ping does create hot air issues in most cases.

 AI>> Ping is neither secure nor insecure.

 KR> Wrong.

Bzzt. Wrong.

 KR> It was you who raised the term insecure inbound in your inital
 KR> question and i took it over, sorry for that.

It really doesn't matter if the recipient is ping or someone else.

 KR> When i wrote insecure ping I had that insecure inbound in my mind, the
 KR> correct binkd keywords are:

 KR> # Inbound directory for secure and non-secure links
 KR> #
 KR> inbound           /secure
 KR> inbound-nonsecure /insecure

I use those keywords in my config, for some very good reasons. I am not suggesting any kind of insecure behaviour.

We do toss netmail in the secure and insecure inbound as we should.

The question is simply..

Is it desirable to decompress netmail in the insecure inbound that has arrived in the form of an arcmail compressed mail bundle?

I am suggesting that we do that for netmail. Currently hpt checks the origin of arcmail bundles and if it comes from an unknown node it is not decompressed and tossed. Perhaps we could also check if the mail is netmail or echomail and if it is netmail then go ahead and toss it.

Echomail should never be tossed or even upacked in the insecure inbound.

Is there some kind of security risk in doing that?

I agree with you that nodes should always send netmail uncompressed and I always do that. However if I receive netmail in compressed form, and I do receive it that way from time to time that we process it.

I find no policy or FTN standard that directs nodes not to do that and that is why it happens.

 Ttyl :-),
         Al
--- GoldED+/LNX 1.1.5-b20180707
 * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)

.