Hello Oli,

I'm not convinced we convinced Alan.

Now don't get me wrong. I don't mind decompressing stuff in my inbound. I did that earlier today, and that's fine. I can't always be here at the keyboard though and that's the part I don't like. That stuff waits until I get to it.

Maybe that's important for different reasons so I'll keep on keepin' on.

There is nothing serious about Fidonet.

We have lots of room for a serious or not so serious talk. It's all good.

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

Hello Alan!

04 May 21, Alan Ianson wrote to Kai Richter:

There is no content to transfer. You don't need a road if nobody
travels.

That is incorrect. There is content to transfer.

Then it is worth a secure connection.

Your actual scenario is two machines that have a road that is
used for nothing more that to prove "look, there is a road".

In the case of ping we want to know if the road is open.

We are talking about unsecure netmail so we are talking about non-secure connects that will happen between all nodes out there excluding those you have already a secure link. So we are talking about roads from your house to any other house in the world. If you want to make sure those roads are open then your house would be surrounded by roads only. The ground is bulldozed 360 deg. around your house for roads that are not used most of the time. That sounds like a very strange szenario for me.

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.

Wait, you are sending ping netmails routed via an unsecure connect somewhere out there? Like throwing a ball into a forest and hoping it would bounce from any tree to find the right one?

Do one step back and get aware that insecure compressed ping
creates 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.

I did not talk about ping, i wrote "insecure compressed ping". And that kind of ping does create inconvienice on your system.

Now the cat is out of the bag. You really do want to change the
default behavior of the whole fidonet for insecure compressed
mail.

That is up to the husky developers.

I didn't talk about developers. They don't control what you want to "want", don't they? Their part is the opposit of want, they do or don't.

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.

You did already. Your original question targeted a change for hpt directly. Who else than developers could do that?

I agree with you that nodes should always send netmail
uncompressed

Then please follow this path. It is the solution with no issues.

This is the path I am on, as I said. Repeatedly.

I'm sorry, if i noticed that then i wouldn't wrote that way.

Be a good coordinator and teach selfish nodes why to turn off
compression for insecure netmail. Do not support their annoying
behavior by working around.

Selfish nodes?

They didn't ask you if it's ok to turn on comression for insecure netmail and they are causing inconvinience to you.

I will certainly suggest this to nodes when I can do that.

That would be great.

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.

I do think you can. Telling the background explains the reason of insecure compressed netmail issues that could be avoided easily if the sender turns off compression for insecure netmail. Any node who would like to have reliable mail transportation would turn off compression for his own advantage.

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.

Then you are truly in the position to change the way of insecure compressed netmail. Choose to give no support for insecure compressed netmail.

This would change the options for the sending node to use secure links or to send uncompressed insecure netmail. That's still the free choice of the sending node if he wants to reach you.

You can do what ever you will on your system but stop forcing
me/us to support compression. You don't know what is running on
"our" side.

I am not, and will not force anything on anyone.

You ask for a minimum standard and a change of the policy in this discussion. This would force one or the other to enable or disable compression for insecure netmail.

There is no arc support for the Pandora, for example.
http://repo.openpandora.org/?page=all&search=unarc

What will be then? Would you simply say i'm no longer part of
fidonet if i can't support compression?

Of course not. Why do you suggest that I would?

If you change the policy to support compressed insecure netmail then you chisel it into stone. It would be allowed and common to send compressed insecure netmail. Then i have to support it just like i do support FTS-0001 type 2 packets now. And because i'm no developer i have no clue how i could do that. This would force me into the same position that you are in now, i have to ask for software support.

The inconvinience is not solved by compressed insecure netmail support for the whole fidonet, it's pushed to systems that can't support compression.

Or will you invent a "noarc" flag for the nodelist that any node
does know that i do not support compression?

I would not invent a noarc flag for several reasons.

Thanks.

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.

Sigh... You have to eat all of the pie. Compress netmail is a problem for insecure inbound only. If the route is a route of secure links the problem does not exist. This is why i said "arrange a secure link".

Sigh again... and i struggle for words. If that situation really happens then you just told me that you send via unsecured routes. Compressed netmail can be a problem on insecure tranfers only. What kind of network does not have secure routing? What is going on there?

You intention for easy going with compressed insecure mail will
backfire then because you have to install the "unarc" flag
condition to the whole fidonet systems including yours. See the
top of this 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.

Dingdong the bell rings. We are not talking about your system, we are talking about the whole network.

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

I showed you two times already. The *transfer*! format is defined
by FTS-0001.

If a node transfers an arcmail bundle to my node (as we are discussing here), has any policy or standard been violated?

I showed you to times and it is, but this time you can look for yourself.

Compression after agreement is defined by the echopol and that is
a freedom i'd like to see for the whole fidonet. You can use any
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.

Dingdong the bell rings. We are not talking about your system, we are talking about the whole network.

Sending compression to others is not your own use.

If one does not agree or the parties never talked about
compression before then no compression is the solution that will
work on the whole fidonet.

I agree with you. Nevertheless there is compressed mail in my insecure inbound that sits there until I find and deal with it.

Best practice: Delete it.

This is that BOFH solution i mentioned before but it really is the best solution if you have the whole fidonet in mind.

[long ago]

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

Let's say yes, true. I don't want to switch to bastard operator from hell mode. That path would end in destruction.

[now:]
That insecure mail bundle would be destroyed but the sender will see that his method did not work. If he complains you will force him by kindly asking for his support in trouble shooting within you would ask for a test with no compression. And wow, look, it does work without compression.

Regards

Kai

--- GoldED+/LNX 1.1.4.7
* Origin: Monobox (2:240/77)

Hello Alan!

04 May 21, Alan Ianson wrote to Matthias Hertzog:

My goal in testing is to fix what's broken or to make things work
better when that is possible.

I'm sorry but that's very hard to see from my point of view.

It does remind my to a guy who said "There is no e-mail spam, the spamfilter removes all.". My question is "When there is no e-mail spam, why do we have spamfilters?".

I think that is compareable to what you are doing with insecure compressed netmail. You are trying to fix the symptoms instead of fixing the reasons.

The symptom fix would fix your system.
The reason fix would fix the whole fidonet.

Regards

Kai

--- GoldED+/LNX 1.1.4.7
* Origin: Monobox (2:240/77)

Hello Kai,

That is incorrect. There is content to transfer.

Then it is worth a secure connection.

We've been over this so I'll make this short.

insecure inbound that sits there until I find and deal with it.

Best practice: Delete it.

Thank you for your advice.

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

Hello Alan!

That is incorrect. There is content to transfer.

Then it is worth a secure connection.

We've been over this so I'll make this short.

Yes, we've been over this. The concept is fine as it is now.
No reason to change.

insecure inbound that sits there until I find and deal with it.

Best practice: Delete it.

You can do with your inbound whatever you want. So do i
and i don't intend to change anything on this. System
is open enough for newcomers, system is secure enough for
sysops.

Never change a winning team.

Matthias
--- GoldED+/W64-MSVC 1.1.5-b20180707
* Origin: MHS Systems (2:301/1)