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