Hello Alan!

25 Apr 21, Alan Ianson wrote to Kai Richter:

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.

According to my nodelist you are responsible for ten nodes in the network. They are all flagged CM and IP, except the pvts. This would be ten routing statements. What kind of problems there could be??

Regards

Kai

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

Hello Kai,

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.

According to my nodelist you are responsible for ten nodes in the
network. They are all flagged CM and IP, except the pvts. This would
be ten routing statements. What kind of problems there could be??

There are none that I know of and none have been brought to my attention.

The only issue in net 153 at the moment is a node with hardware issues and other gone missing. Both of those nodes have been commented out of the nodelist pending their return and I hope they will both return when that is possible.

Ping is not something I put in place because of problems in net 153.

Ttyl :-),
Al

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

Hello Alan!

26 Apr 21, Alan Ianson wrote to Kai Richter:

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.

What kind of problems there could be??

There are none that I know of and none have been brought to my
attention.

Then there is no ongoning battle? No own configuration problem?
Then about what kind of configuration problems did you talked above?

The only issue in net 153 at the moment is a node with hardware
issues and other gone missing. Both of those nodes have been
commented out of the nodelist pending their return and I hope they
will both return when that is possible.

This is common in all networks, sadly.

Ping is not something I put in place because of problems in net 153.

I didn't want to put 153 on the table. I'm interessted to learn what kind of problems ping would solve that can't be solved without ping.

Regards

Kai

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

Hello Kai,

Then there is no ongoning battle?

No.

No own configuration problem?

Not currently, not that I know of.

Then about what kind of configuration problems did you talked above?

I'll save you the gory details. ;)

I didn't want to put 153 on the table. I'm interessted to learn what
kind of problems ping would solve that can't be solved without ping.

Ping cannot solve any problems. It is an informational tool. Sysops can solve problems with information.

Ttyl :-),
Al

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

Hello Alan!

29 Apr 21, Alan Ianson wrote to Kai Richter:

Then about what kind of configuration problems did you talked
above?

I'll save you the gory details. ;)

My translator told me to write "Nothing but hot air." ;)

what kind of problems ping would solve that can't be solved
without ping.

Ping cannot solve any problems. It is an informational tool. Sysops
can solve problems with information.

That is what i was aiming for. You need a sysop to solve a problem.

If there is no conversation between the nodes then there is no problem that needs to be solved. Insecure ping does create hot air issues in most cases.

Regards

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

Hello Kai,

I'll save you the gory details. ;)

My translator told me to write "Nothing but hot air." ;)

I've had issues with my own config just because I didn't see the outcome. They are all fixed now as far as I know.

Nothing to report today. ;)

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

I don't know what that is supposed to mean. I converse with sysops on a fairly regular basis in netmail and echomail. Sometimes we just banter and if there are issues we solve them.

Insecure ping does create hot air issues in most cases.

Ping is neither secure nor insecure. It is just a tool you can use if you need it.

Ttyl :-),
Al

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

Hello Alan!

02 May 21, Alan Ianson wrote to Kai Richter:

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

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

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

Insecure ping does create hot air issues in most cases.

Ping is neither secure nor insecure.

Wrong. It was you who raised the term insecure inbound in your inital question and i took it over, sorry for that. When i wrote insecure ping I had that insecure inbound in my mind, the correct binkd keywords are:

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

Regards

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

Hello Kai,

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

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

As far as i understood there was no conversation between the node with
the compressed ping netmail and you. If you both don't talk then you
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.

Insecure ping does create hot air issues in most cases.

Ping is neither secure nor insecure.

Wrong.

Bzzt. Wrong.

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

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

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

# Inbound directory for secure and non-secure links
#
inbound /secure
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)

Alan wrote (2021-05-03):

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?

no, it isn't.

you don't decompress netmail, you unpack files from an archive which might be netmail pkts or something else.

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

There is also no policy or standard that directs the anonymous idiot not to send highly compressible garbage in an "arcmail compressed mail bundle" that blows up on the DOS partition on unpack.

But we don't have to discuss the failures of Policy 4.bollocks or the FTSC.

Which software does deliver netmail as a compressed mail bundle? Is it all kinds of different tossers or some specific software that does it by default?

---
* Origin: . (2:280/464.47)

Hello Oli,

you don't decompress netmail,

That is the only way to do it if you are dealing with an mail bundle.

There is also no policy or standard that directs the anonymous idiot
not to send highly compressible garbage in an "arcmail compressed mail bundle" that blows up on the DOS partition on unpack.

I would call that excessively annoying.

But we don't have to discuss the failures of Policy 4.bollocks or the FTSC.

OK.

Which software does deliver netmail as a compressed mail bundle? Is it
all kinds of different tossers or some specific software that does it
by default?

I don't know why mail arrives sometimes compressed. My own software will do that if I direct it so. Someone, or some software compressed that mail before I received it.

My issue is a simple one. Mail arrives in my insecure inbound in that form and it gets renamed to .sec and stays there until I decompress it myself and toss it.

Ttyl :-),
Al

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

Hello Alan!

03 May 21, Alan Ianson wrote to Kai Richter:

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

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

As far as i understood there was no conversation between the node
with the compressed ping netmail and you. If you both don't talk
then you 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.

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

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

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.

==========

I was going to split the rest to another mail, but the part above is an important context at the end of this mail.

When i wrote insecure ping I had that insecure inbound in my
mind, the correct binkd keywords are:
inbound /secure
inbound-nonsecure /insecure

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

Your suggestion increases complexity and risk level for the whole fidonet.

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.

All arguments are on the table within the last ~30K of mails. In short: No.

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.

All nodes can handle uncompressed FTS-0001 mail because they have to to be part of the Fidonet.

I agree with you that nodes should always send netmail uncompressed

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

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.

You are going to force the whole fidonet to support compression.

See the top of this mail - you are going to create problems where are none.

However if I receive netmail in compressed form, and I do receive it
that way from time to time that we process it.

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.

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? Or will you invent a "noarc" flag for the nodelist that any node does know that i do not support compression?

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 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.

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.

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.

Regards

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

Hello Kai,

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

That is incorrect. There is content to transfer.

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.

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.

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.

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 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.

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.

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?

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.

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.

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.

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?

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. 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.

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.

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?

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.

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.

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 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)