I received netmail in my insecure inbound addressed to Ping. This
netmail arrived in an arcmail bundle and it was not unpacked, it was renamed to .sec and left in the insecure inbound for me to unpack and toss.
It is normal to receive netmail in the insecure inbound.
I wonder if it is possible for hpt to unpack those arcmail bundles
and toss the packets within if they are netmail.
Echomail should not be tossed from the insecure inbound, but netmail
in the insecure inbound should?
I wonder if it is possible for hpt to unpack those arcmail bundles
and toss the packets within if they are netmail.
Yes, it is. Negotiate a password with the sending sysop.
Insecure bundles/archives should not be unpacked because of a mailbomb risk.
It is normal to receive netmail in the insecure inbound.
Yes, because it's the only way to establish a first contact with the sysop. At this point the netmail is still not tossed and stored in the insec inbound.
I wonder if it is possible for hpt to unpack those arcmail
bundles and toss the packets within if they are netmail.
Yes, it is. Negotiate a password with the sending sysop.
Echomail should not be tossed from the insecure inbound, but
netmail in the insecure inbound should?
Unsecured echomail bundles are a configuration error in most cases.
Sending echomail bundles without negotating with the sysop first is annoying behavior if it's "wanted" echomail and xab if it's any form
of spam.
In any case there is need to talk to the sending sysop.
And that is why i do dislike the existence of PING. It's results are mostly useless. A PING result would tell me that mailer, tosser and
PING bot are up and running - but for any other problems i do need a contact with the sysop. I need a human being on the other side or we
are generating a network of lonley PING bots.
No one should send netmail as arcmail, but there are systems that do
it.
No one should send netmail as arcmail, but there are systems
that do it.
Is there any reason not to archive netmail?
Is there any reason not to archive netmail?
To make sure the destination will process it?
Is there any reason not to archive netmail?
To make sure the destination will process it?
That is the truth in my my case at least, uncompressed netmails will be processed.
But in the general day to day task of transferring mail I don't think
one is better than the other. They just look different.
I wonder if it is possible for hpt to unpack those arcmail
Yes, it is. Negotiate a password with the sending sysop.
It may be quite a job to negotiate a password with all sysops and
points in the world. :D
No one should send netmail as arcmail, but there are systems that do
it.
Netmail that arrives uncompressed is tossed from the insecure
directory.
If echomail is found it should be so, if netmail is found it should be tossed?
I wonder if it is possible for hpt to unpack those arcmail
bundles and toss the packets within if they are netmail.
Yes, it is. Negotiate a password with the sending sysop.
I get/send netmail to/from that node periodically. I would be happy to link with that node if there was any reason to.
We only exchange netmail once in a while so we have never setup a
secure link.
This sysop, I suspect just wanted to test the route on the return
trip. No need to talk about that.
Unless there is a problem
and if there is I would like to get to work on the solution.
Hello Tommi,
No one should send netmail as arcmail, but there are systems that
do it.
Is there any reason not to archive netmail? Some tossers I have used
did that and some didn't. No reason to archive it or not that I know
of.
Outgoing echomail to this net works fine, just incoming is
problematic.
Here's a wild guess, an unknown archiver.
Netmail that arrives uncompressed is tossed from the insecure
directory.
There your solution is. Get the netmail uncompressed.
Tossing uncompressed insecure netmail is the lowest level to establish first communication with the other sysop. It needs to work on any
system.
Even if your mailer log told you that you are connecting to a linux
binkd that doesn't force the tosser to be on a linux machine. Some
systems are sharing the inbound to another system where the tosser
works. You have no idea if the other side can handle the compression format that you use. You need to find a minimum standard and the
easiest minimum standard is no compression.
I get/send netmail to/from that node periodically. I would be
happy to link with that node if there was any reason to.
There is. A periodical link should be secured.
Negeotation with the other sysop would set your passwords, the
compression format and the route. I recommend to set a private
nodelist too, just to avoid any further troubles with the official nodelist.
This would work without any issues if the sender disables netmail compression.
This sysop, I suspect just wanted to test the route on the return
trip. No need to talk about that.
Then what is this for? Why should someone do a connect if there is
nothing to talk? There is no need to build a road if nobody travels.
Paths build up because many are going in the same direction.
As far as i noticed there was a testing run by someone visible at enet.sysop. According to my logfiles i was effected too. I received a netmail from a point system that was destinated to another point
system. Why?? If we all throw our mails to anyone how could we believe that it would ever reach it's destination? This sysop simply wasted
our time because he didn't use the standard secured routing. And he doesn't know the networks structure and function of hosts. From my
point of view he does need someone to talk and who gives an
introduction for ftn based networks.
The problem is unsecured inbound compressed netmail.
and if there is I would like to get to work on the solution.
The solution is turn off compression and/or turn off not necessary
tests.
Is there any reason not to archive netmail? Some tossers I have
used did that and some didn't. No reason to archive it or not
that I know of.
Wrong, you already know it. ;)
Compressing adds a layer of complexity.
Mail arrives in my inbound as it is prepared by other nodes. This is
not a configuration or choice on my part.
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 get/send netmail to/from that node periodically. I would be
happy to link with that node if there was any reason to.
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.
Secure links for possible periodic netmail is not necessary.
When mail arrives compressed then we simply need to decompress it.
This would work without any issues if the sender disables netmail
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.
This sysop, I suspect just wanted to test the route on the
return trip. No need to talk about that.
Then what is this for? Why should someone do a connect if there
is nothing to talk? There is no need to build a road if nobody
travels. 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.
The problem is unsecured inbound compressed netmail.
I need to decompress archived netmail, that has never been a problem.
and if there is I would like to get to work on the solution.
The solution is turn off compression and/or turn off not
necessary 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.
No reason to archive it or not that I know of.
Wrong, you already know it. ;)
I don't know that. What is wrong?
I know that it is inconvenient for me.
Compressing adds a layer of complexity.
It does. The choices here are zipped or not zipped. I have a few other unpack lines just in case but I hope folks will stick to zip or use
plain packets.
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.
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.
Perhaps we need a standard of some sort but there is none that I
know of.
If you are really interested i'd like to recommend the fidonet policy. This is Fidonets initial document. It's latest approved version is
4.07 of 1989. Some things may be outdated today but the basics are
still displayed.
You asked for this part:
"2.1.8 Exclusivity of Zone Mail Hour
There are historical reasons why echomail handling with or without compression is not found in the policy.
Well, to be honest, i'd like to stop here but the echopol continues
then:
"SEA's ARC 5.1 (non-Squashing) archival storage format will be the "fallback" if either party is unable or unwilling to support an alternate method.
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.
Well, true but why don't you use your secoured links and set up
routing?
Secure links for possible periodic netmail is not necessary.
Just like compressed netmail is not. If you receive test mails only,
what size do they have that would need compression?
When mail arrives compressed then we simply need to decompress
it.
As proved by the policies we simply do not need to agree to receive
it.
This would work without any issues if the sender disables
netmail 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.
No, definitly not.
Do you really want to be forced to handle anything i throw to your
system?
What if i use an archive format that requires to pay a serious ammount
of money for registration? There is none yet? I'd like to write it, it should be easy merge open source zip and pgp to force you to buy the decryp... decompression key.
Do you really know who "we" are?
Do you know which machines are used for node operation?
My node did run on a P1/133 with 32MB RAM for a long time. An actual compression format that would require 66MB for decompression would
crash the system.
If there are tossers that can not turn off compression then they do
not conform to the minimum standards of fidonet. Any sysop who use
such software risks his node number.
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.
Then talk to him. There is need.
He does annoy the network.
He forces you to ask for a change in software operation. It may result into developer work, wasting valueable dev time for one unwitting
sysop.
(i found unwitting by translator. i hope that stands for "he doesn't
know what he's doing".)
Then why it is now? This "new" fault is no issue on your system.
Anyone and you can. TALK WITH HIM! Do what fidonet is for.
Communicate!
I explained above that sending insecure compressed netmail and so he
is annoying according fidonets common practice and policies.
I don't know that. What is wrong?
I know that it is inconvenient for me.
That is reason enough.
But it's not only for you, it's for any other node that will receive insecure compressed netmail from that node. You are in the first line
and responsible to defend systems with no or limited compression
support.
Could you tell me what de+compression software is available for the OpenPandora or the Dragonbox Pyra? Great if you ever heard of them
before but bad because i'd liked to give an expample of surprizing hardware out there.
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??
Perhaps we need a standard of some sort but there is none that I
know of.
You asked for this part:
"2.1.8 Exclusivity of Zone Mail Hour
No, I didn't ask for that. My own node accepts and tosses mail at all hours of the day including ZMH.
We could talk about fido policy if you like, privately in netmail or
the FIDOPOLS or FN_SYSOP area but I would rather not do that here.
There is nothing in policy or FTN standards as far as I know.
Echomail/netmail may arrive compressed or uncompressed. If that mail
is compressed I don't think any rules have been broken.
I can decompress
Well, to be honest, i'd like to stop here but the echopol
continues then:
"SEA's ARC 5.1 (non-Squashing) archival storage format will be
I still have arc on my path to extract an arc compressed mail bundle
but I haven't seen an arc bundle in years.
I do have
Just like compressed netmail is not. If you receive test mails
only, what size do they have that would need compression?
This is not my choice or configuration. Mail arrives in my inbound as
it is.
When mail arrives compressed then we simply need to decompress
it.
As proved by the policies we simply do not need to agree to
receive it.
What proof, and what policy?
Yes, it would. HPT works this way by default but not all
tossers/mailer do and we need to work with what we get.
No, definitly not.
This may very well be a "Won't fix" issue.
In fact this is my issue and the solution must be mine. I hope I will
have help to solve that but maybe there is no solution.
I bring it up for discussion with other users of the husky software
for discussion and consideration only.
Do you really want to be forced to handle anything i throw to
your system?
What you describe is a different issue. I am not forced to handle mail
for any node.
What if i use an archive format that requires to pay a serious
ammount of money for registration?
You can use any archive method I have mentioned.
If I received mail from your node that I could not decompress I would
let you know that and also let you know what I can decompress.
Do you really know who "we" are?
I know you and others only from what I have read from you. I have read nothing from you that makes me think I should be worried.
Do you know which machines are used for node operation?
My node did run on a P1/133 with 32MB RAM for a long time.
I would not send mail to your node that was compressed in a way you
could not decompress it. You or any node.
I do not wish any node delisted, I just want to unpack and toss mail.
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.
Then talk to him. There is need.
There is no need, he has done nothing wrong.
I will likely talk to this sysop again but I doubt we will discuss
this, because there is no need.
I cannot change the behaviour of other nodes
or software in use, and I have no desire to do that.
He does annoy the network.
I have not been annoyed by this node.
I simply bring up my experience for discussion and consideration.
We are talking about a well respected (at least be me) fido node who
does indeed know what he is doing.
Anyone and you can. TALK WITH HIM! Do what fidonet is for.
Communicate!
That is what I do, and what I am doing.
I explained above that sending insecure compressed netmail and so
he is annoying according fidonets common practice and policies.
I don't find netmail (compressed or not) annoying, and I don't read anything in policy or fidonet standards that makes compressed netmail annoying.
I know that it is inconvenient for me.
That is reason enough.
That is not reason enough. Decompressing an archive (within reasonable limits) is not a problem.
But it's not only for you, it's for any other node that will
receive insecure compressed netmail from that node. You are in
the first line and responsible to defend systems with no or
limited compression support.
I will work with such a node if there is one.
I will deliver mail and files to a node in a way they can work with
even if that causes me extra steps to do.
To date I have not heard from any nodes that they could not
decompress any mail or files sent to them.
Could you tell me what de+compression software is available for
the OpenPandora or the Dragonbox Pyra?
I do not know what works with Dragonbox Pyra. If someone is using
exotic hardware or software then I may not be able to communicate with them if they cannot work with plain packets.
This is far from the issue I have seen and reported.
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.
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.
"2.1.8 Exclusivity of Zone Mail Hour
No, I didn't ask for that. My own node accepts and tosses mail at
all hours of the day including ZMH.
You told me that you do not know a standard for netmail compression. I tried to help you by looking into the policy and quoted the parts that could change your unknowingness.
Obviously you stopped reading at the header and ignored the hooks that
are linked to fts-0001 to understand what kind of minimum standard is
set for fidonet.
I'll talk later about the "my node accepts" because i noted "my"
often.
There is nothing in policy or FTN standards as far as I know.
And if you reject to read it in context you would never know it.
Echomail/netmail may arrive compressed or uncompressed. If that
mail is compressed I don't think any rules have been broken.
I do. I think you can't see it because...
I can decompress
...you are focused on "i can" or "my node".
That was not the question. The question was if the size of the
incoming test mails is large enough to justify compression.
As proved by the policies we simply do not need to agree to
receive it.
What proof, and what policy?
I qouted all relevant parts in the mail before. If your question is serious please read it.
I bring it up for discussion with other users of the husky
software for discussion and consideration only.
From my point of view there is a minimum standard for compression in
the policies. A minimum standard that is usefull for ALL fidonet
systems.
At the moment you are 1:153/0, and as far as i know wihout a NC-Flag
in the network you are the network coordinatior that was appointed to
by policy 4.07. We are talking about the minimum standard so you need
to have all systems in mind if we talk about netmail compression. You
must be able to receive netmail from any node. This is the issue you brought on the table. This issue is not yours only, all NCs are
effected when we are searching for a standard.
If I received mail from your node that I could not decompress I
would let you know that and also let you know what I can
decompress.
Good solution. If i would know that your tosser does not unpack
insecure compressed netmail i would turn off compression immediately.
(Oh, wrong. I wouldn't. Because i didn't know what kind of unpacker
you could handle i would never send you compressed netmails.) But back
to telling, why didn't this work? Why did the other node not switched
off compression if he knows that it would disturb netmail processing
on your system?
And this is the working solution for any node within the network.
Because it does work for any node this should be the minimum standard.
And because this was known since 30+ years this spirit can be found in
the policies.
Hell, my jaw is falling down, you *guess* and you see no need to
talk??
Why are we talking then?
Why are you searching for a solution here,
are you afraid to simply ask him to turn off compression??
You are part of the fidonet *C structure, you should have a smooth
network operation on your priority list. My deepest apologies but i
don't understand why you are acting the way you do.
You can and you have to. That's your job as network coordinator.
Then there is no ongoning battle?
No own configuration problem?
Then about what kind of configuration problems did you talked above?
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.
You told me that you do not know a standard for netmail
compression. I tried to help you by looking into the policy and
quoted the parts that could change your unknowingness.
Policy takes no position on compression, and rightly so.
There is nothing in policy or FTN standards as far as I know.
And if you reject to read it in context you would never know it.
I have not rejected it. Every input and output from my node is
compliant with our minimum standards.
I may compress it for storage/delivery if a node is configured that
way but I have not rejected anything in policy or fidonet standards
and I never will. Why would I do that?
I received netmail in my insecure inbound addressed to Ping. This
netmail arrived in an arcmail bundle and it was not unpacked, it was renamed to .sec and left in the insecure inbound
Echomail/netmail may arrive compressed or uncompressed. If that
mail is compressed I don't think any rules have been broken.
I do. I think you can't see it because...
I can decompress
...you are focused on "i can" or "my node".
I say that because, I can (within reasonable limits).
That was not the question. The question was if the size of the
incoming test mails is large enough to justify compression.
question last time. They were 0.5KB or so. They were simply packed
into an arcmail bundle because that is the way some software works,
not because they were large in size.
From my point of view there is a minimum standard for compression
in the policies. A minimum standard that is usefull for ALL
fidonet systems.
Compression is not spoken of in policy and it doesn't need to.
Fidonet nodes can arrange their links in a way that works for them.
If a node sends mail here in an arcmail bundle we can decompress it.
That is not and never was a problem.
If my tosser can't/won't do it then I'll do it myself!
I wonder if it is possible for hpt to unpack those arcmail bundles
and toss the packets within if they are netmail.
I find that all a pleasure and not a burden and while I am NC of net
153 I'll always do my best for the nodes in net 153, and as long as I
am a node in fidonet I will do my best for fidonet as a whole.
You must be able to receive netmail from any node. This is the issue
you brought on the table. This issue is not yours only, all NCs are
effected when we are searching for a standard.
I have not and will not abandon any standards or minimum requirements.
If I received mail from your node that I could not decompress I
would let you know that and also let you know what I can
decompress.
Why did the other node not switched off compression if he knows
that it would disturb netmail processing on your system?
I am not the arbiter of good/bad or right and wrong.
I am not remotely qualified to make these kind of judgments.
Different nodes and software do things differently. I don't know why.
I am just trying to get things done on my node in a good a reliable
way.
And this is the working solution for any node within the network.
It may be a solution for you and your software but other nodes do
things differently.
I see the minimum standards you speak of but policy doesn't get into
the subject of compression.
are you afraid to simply ask him to turn off compression??
Why should I ask him to do that?
You are part of the fidonet *C structure, you should have a
smooth network operation on your priority list. My deepest
apologies but i don't understand why you are acting the way you
do.
I want to solve the simplest of issues. Not create more issues.
Then about what kind of configuration problems did you talked
above?
I'll save you the gory details. ;)
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.
We are going to repeat us. You are still on the "i and my" point of
view.
You are the node that is NOT configured that way for compression.
The sender must not compress it.
Minimum definition in the policy is FTS-0001 type 2 packet format.
You told us you have never talked about compression to that node, so
this node never got your agreement for compression and because of that
he must stick on FTS-0001 without compression.
Echomail/netmail may arrive compressed or uncompressed. If that
mail is compressed I don't think any rules have been broken.
I do.
I think we made a mistake when we started the discussion with a focus
on compression. The more important issue is insecure inbound.
That's too bad. So size couldn't be put on the "pro compression" list.
Compression is not spoken of in policy and it doesn't need to.
It does need because it must be sure that both parties can process the mail. That's why the the format is defined by policy and compression
is not part of the defined format.
That's the point. Compressed insecure inbound does not work reliable
on all systems.
Compressed mail CAN be arranged optional AFTER agreement.
This would tell us what the minimum configuration for fidonet software
is and what kind of configuration is an optional enhancement.
If a node sends mail here in an arcmail bundle we can decompress
it. That is not and never was a problem.
You told me you don't know the Pyra. What about the future? You can't
say we can if you don't know what we can do.
Sure you can. But i have to remind you that you asked for a solution
that does not effect your system only:
I wonder if it is possible for hpt to unpack those arcmail
bundles and toss the packets within if they are netmail.
You want to have a change in a security feature of a software that is
used by many nodes. This is a change that is far beyond of "my
system".
You must be able to receive netmail from any node. This is the
issue you brought on the table. This issue is not yours only,
all NCs are effected when we are searching for a standard.
I have not and will not abandon any standards or minimum
requirements.
Not yet, sure. But you asked for the first step into that direction.
Let's say hpt does have build in support for insecure compressed mail. Then this software that does send compressed mail without prior
agreement by both nodes will contiune with less issues. Insecure compressed mail would become more common and maybe the default
behavior because sysops sometimes share their configuration. It would
be established over time as common practice or new standard.
Nodes with software that can't support insecure compressed mail will
have issues that they can't solve by their own.
To avoid that issues they could write a fidonews article, hello world,
i can't support your insecure compressed mail, please all nodes in the network switch off compression first if you want to send direct mail
to me. Then all nodes need to check their configuration to switch of compression for that node. This would be a giant effort.
I am not the arbiter of good/bad or right and wrong.
You are wearing the *C hat. If you will do your best for fidonet as a whole then you can't avoid a little bit of decision what is best for fidonet as a whole. ;-)
I learned one reason. Becaue nobody told them that their way causes trouble.
You can. Your solution could be a batch or script file that
uncompresses the mail from the *.sec bundle to the inbound you prefer
and retrigger the hpt run again. That solution would effect your
system only and in case of security breaches it is your system only
that would be responsible.
A modification for hpt would lower the security level on all systems
that work with hpt.
I do know that all other nodes have to process mail as per policy
approved FTS-0001 and that they have to process type 2 formated
packets without any differnce:
"Any system which wishes to be a part of FidoNet must be able to [...] using the protocol defined in the current FidoNet Technical Standards Committee publication (FTS-0001 at this writing)."
If they can't handle that they can't be a part of fidonet.
I see the minimum standards you speak of but policy doesn't get
into the subject of compression.
"To conserve space and eliminate fields which would be meaningless
if sent (e.g. timesRead), messages are *packed for transmission*. As
this is a data structure which is *actually transferred*, its
definition is *critical* to FidoNet."
Packed to conserve space. Sounds exactly like compression to me. And
this critial structure is transferred actually.
(Looks like i have to withdraw my "no compression" term. ;) No, just kidding.) (packed type 2 messages are already supported by any fidonet tosser.)
Why should I ask him to do that?
You are part of the fidonet *C structure, you should have a
smooth network operation on your priority list.
I want to solve the simplest of issues. Not create more issues.
One node sending insecure compressed mail, other nodes must work
around. One node stops compression for sending insecure mail, other
nodes do nothing.
I'll save you the gory details. ;)
My translator told me to write "Nothing but hot air." ;)
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.
The questions is "is it desirable to decompress those packets" in the insecure inbound.
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.
Insecure ping does create hot air issues in most cases.
Ping is neither secure nor insecure.
We are going to repeat us. You are still on the "i and my" point
of view.
Who's point of view were you expecting?
You are the node that is NOT configured that way for compression.
The sender must not compress it.
I agree with you, it is best to send insecure netmail in it's plain uncompressed format.
Minimum definition in the policy is FTS-0001 type 2 packet
format.
These netmails were fully compliant with our minimum standards. The
issue is a simple one, they were compressed into an arcmail bundle
that needs to be decompressed before the packets can be tossed.
The questions is "is it desirable to decompress those packets" in the insecure inbound.
You told us you have never talked about compression to that node,
so this node never got your agreement for compression and because
of that he must stick on FTS-0001 without compression.
No, he/she didn't. They don't need my agreement. As long as they use a common archive tool I will simply decompress arcmail bundles.
Echomail/netmail may arrive compressed or uncompressed. If
that mail is compressed I don't think any rules have been
broken.
I do.
What rule?
If you can quote policy or fidonet standards that say that
archiving mail is bad, or wrong I will change my position.
Compression is not spoken of in policy and it doesn't need to.
It does need because it must be sure that both parties can
process the mail. That's why the the format is defined by policy
and compression is not part of the defined format.
If there is need then the policy needs to updated.
That would not be an easy thing to do in fidonet. I would be
agreeable to that also
That's the point. Compressed insecure inbound does not work
reliable on all systems.
How is that?
and maybe the default behavior because sysops sometimes share
their configuration. It would be established over time as common
practice or new standard.
I think that is the case now. An arcmail bundle is no surprise and it
may contain netmail and/or echomail.
Nodes with software that can't support insecure compressed mail
will have issues that they can't solve by their own.
That is why I don't compress netmail.
It would be best if they didn't do that but I am in no position to
change that behaviour.
I learned one reason. Becaue nobody told them that their way
causes trouble.
Does it actually cause trouble?
(Looks like i have to withdraw my "no compression" term. ;) No,
just kidding.) (packed type 2 messages are already supported by
any fidonet tosser.)
A packed message is not an arcmail bundle. They are two different
things.
The questions is "is it desirable to decompress those packets" in
the insecure inbound.
Can it be automatically unpacked without any security issues (there
can be any file in the archive).
Pre-compressed mail bundles are mostly useless in this scenario.
Files can be compressed on the fly over the binkp protocol.
Just reject any insecure compressed mail bundles, problem gone.
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
Just reject any insecure compressed mail bundles, problem gone.
Mail arrives in my inbound as other nodes prepare it and I must deal with it as it is. I receive many compressed mail bundles and I do not
want/need to reject them.
Yeah, this is today's attitude in FTN. Everything goes. Many Sysops
don't have a clue what they are doing and they don't care if the
software they are using is buggy or if it ignores basic FTN standards.
Reject the mail,
let them complain and learn.
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 find no policy or FTN standard that directs nodes not to do that and that is why it happens.
you don't decompress netmail,
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?
The questions is "is it desirable to decompress those packets"
in the insecure inbound.
Can it be automatically unpacked without any security issues
(there can be any file in the archive).
Yes, it can be. My tosser does that (compress/decompress) all day
long. Every tosser I have used does that, that is not an issue.
hpt checks the mail and finds it has come from an unknown node and
leaves it in the inbound so I need to decompress it from the command
line and hpt will then toss it.
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.
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.
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.
I agree with you that nodes should always send netmail uncompressed
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.
I received netmail in my insecure inbound addressed to Ping. ThisThat is the designed process and correct.
netmail arrived in an arcmail bundle and it was not unpacked, it
was renamed to .sec and left in the insecure inbound for me to
unpack and toss.
It is normal to receive netmail in the insecure inbound.Yes, because it's the only way to establish a first contact with the sysop. At this point the netmail is still not tossed and stored in the insec inbound.
I wonder if it is possible for hpt to unpack those arcmailYes, it is. Negotiate a password with the sending sysop.
bundles and toss the packets within if they are netmail.
Echomail should not be tossed from the insecure inbound, butIt's a compromise between security and easy network operation. A not
netmail in the insecure inbound should?
so golden but middle path.
Insecure bundles/archives should not be unpacked because of a mailbomb risk. I do know we are not in the POTS age anymore but i'd like to
keep that behavior because of the variety of systems in the network.
Unsecured echomail bundles are a configuration error in most cases.
Sending echomail bundles without negotating with the sysop first is annoying behavior if it's "wanted" echomail and xab if it's any form
of spam.
In any case there is need to talk to the sending sysop.
And that is why i do dislike the existence of PING. It's results are mostly useless. A PING result would tell me that mailer, tosser and
PING bot are up and running - but for any other problems i do need a contact with the sysop. I need a human being on the other side or we
are generating a network of lonley PING bots.
I wonder if it is possible for hpt to unpack those arcmail
bundles and toss the packets within if they are netmail.
Yes, it is. Negotiate a password with the sending sysop.It may be quite a job to negotiate a password with all sysops and
points in the world. :D
Hello Tommi,
No one should send netmail as arcmail, but there are systems thatIs there any reason not to archive netmail? Some tossers I have used
do it.
did that and some didn't. No reason to archive it or not that I know
of.
No one should send netmail as arcmail, but there are systems
that do it.
Is there any reason not to archive netmail?To make sure the destination will process it?
Is there any reason not to archive netmail?
To make sure the destination will process it?That is the truth in my my case at least, uncompressed netmails will
be processed.
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.
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.
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.
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.
Is there any reason not to archive netmail? Some tossers I have
used did that and some didn't. No reason to archive it or not
that I know of.
Is there any reason to compress netmail prior to sending nowdays?
I don't see one, and i'm a bandwith-saving-guy.
Do you allow me to try to fill your disk?
On ethical basis with prior notice of course.
Feel free to enjoy the ride...
Do you allow me to try to fill your disk?Say, your not that bastard operator from hell that Kai warned me about
are you? ;)
On ethical basis with prior notice of course.Are those my ethics, or yours.
I don't compress netmail. The issue I am seeing happens when I receive netmail that is compressed in my insecure inbound. The arcmail bundle
sits there until I decompress it.
I don't see one, and i'm a bandwith-saving-guy.I am too. Not that it matters much but I don't like to waste.
No, i'm not. I'm one of the defense guys, but i need to know
where the holes are to be able to fill them ... by fixing it.
That's a thing we'd agree on. I'd never attack a system without
consent of the target sysop. Back in the days, we had the
agreement to prepare everyting and then get the sysop on
a voice line. Then we agreed again and started. That was a very
tiny group of people here in switzerland doing this, 3 in fact.
I am too. Not that it matters much but I don't like to waste.
Yep, Bink does a fine job on compressing. So we all can be happy.
100% agree. Echomail historically was sent compressed. You know, cost savings in POTS. Nowdays, echomail is no longer compressed prior
to sending as BinkD does a good job ab it anyway. That reduces
tosser processing times.
When i re-started my fidonet operations, i was a fan of compressing outbound echomails but got convinced after a few tests and some statistics, that compressing with the tosser/packer is no longer
needed.
In fact, i no longer have any of my links/feeds running with
packed echomails. TBH, i've even disabled the unpacking feature
at all, even in secure inbound.
I've agreed with all my links/feeds, that we deliver eachother uncompressed and that's it.
I've agreed with all my links/feeds, that we deliver eachother
uncompressed and that's it.
I sometimes turn on compression for links that are offline for a bit longer then 1 or 2 days. Because with the high frequent tossing that happens today, the outbound directories quickly fill up with hundreds
of .pkt files, which I don't like. With compression turned on there
are at most 7 files for each (offline) node waiting to be send. When
they become connectable again I turn compression back off...
I sometimes turn on compression for links that are offline for a bit
longer then 1 or 2 days. Because with the high frequent tossing that
happens today, the outbound directories quickly fill up with hundreds
of .pkt files, which I don't like. With compression turned on there
are at most 7 files for each (offline) node waiting to be send. When
they become connectable again I turn compression back off...
That's a nice idea, but forces manual intervention in most cases.
Packed echomail is a bad idea with the high frequenies as one will
run out of file extensions after 36 polls. (.WE0-9 + .WEA-Z).
Having unpacked for offline systems is a pain in the outbound, but
having compressed for active nodes is a pain as well.
My solution: uncompressed & not looking in the outbound too often.
Packed echomail is a bad idea with the high frequenies as one
will run out of file extensions after 36 polls. (.WE0-9 +
.WEA-Z).
It could indeed. My tosser just keeps using the Z if that's reached.
Which doesn't seem to cause problems, as far as I'm aware of...
I sometimes turn on compression for links that are offline for a bit longer then 1 or 2 days. Because with the high frequent tossing that happens today, the outbound directories quickly fill up with hundreds of pkt files, which I don't like. With compression turned on there are at most 7 files for each (offline) node waiting to be send. When they become connectable again I turn compression back off...
I sometimes turn on compression for links that are offline for a
bit longer then 1 or 2 days. Because with the high frequent
tossing that happens today, the outbound directories quickly
fill up with hundreds of pkt files, which I don't like. With
compression turned on there are at most 7 files for each
(offline) node waiting to be send. When they become connectable
again I turn compression back off...
Why not create a separate directory for every node's (pkt) files? Like SeparateBundles in hpt or fileboxes.
Packed echomail is a bad idea with the high frequenies as one
will run out of file extensions after 36 polls. (.WE0-9 +
.WEA-Z).
It could indeed. My tosser just keeps using the Z if that's reached.
Which doesn't seem to cause problems, as far as I'm aware of...
As long as the inbound at the destination system gets processed, that's fine. If not, it will run out of filenames there since trying to rename 12345678.WEZ to 123345678.WE0 will most likely fail.
I sometimes turn on compression for links that are offline for a bit
longer then 1 or 2 days. Because with the high frequent tossing that
happens today, the outbound directories quickly fill up with hundreds
of pkt files, which I don't like. With compression turned on there
are at most 7 files for each (offline) node waiting to be send. When
they become connectable again I turn compression back off...
Why not create a separate directory for every node's (pkt) files? Like SeparateBundles in hpt or fileboxes.
Why not create a separate directory for every node's (pkt) files?
Like SeparateBundles in hpt or fileboxes.
Fileboxes are not BSO compatible. So the behaviour regarding flow
files in fileboxes is undefined. So that can cause problems if a
tosser and mailer try to access the same files at the same time...
And you would still have hundreds (or even more, if the link remains offline) of .pkt files in that directory. So it doesn't solve
anything...
Fileboxes are not BSO compatible. So the behaviour regarding flow
files in fileboxes is undefined. So that can cause problems if a
tosser and mailer try to access the same files at the same time...
I think what Oli meant to say was: Put the PKTs in some per-node folder and leave the LOs in the normal outbound. That way the outbound is
clean, you see what's waiting without having the fuzz of all the PKTs laying around.
And you would still have hundreds (or even more, if the link remains
offline) of .pkt files in that directory. So it doesn't solve
anything...
You'll have 1 ?LO (and probably one ?UT) per node in the outbound and a lot of PKTs in the "per node"-folder. Quite easy to delete, if needed (-:
You'll have 1 ?LO (and probably one ?UT) per node in the outbound
and a lot of PKTs in the "per node"-folder. Quite easy to delete,
if needed (-:
Ok I understand. (And there's only the .?lo file)
But your tosser would have to support that, and it currently
doesn't...
Ok I understand. (And there's only the .?lo file)
But your tosser would have to support that, and it currently
doesn't...
I'm in the (un)lucky position, that i develop my tosser myself, so
i could do that.
But it could also be done with a 3rd party tool that moves things away after your tosser prepared the original outbound.
It's quite easy:
- Check/set BSY
- Read LO files
- If there's a PKT referenced in the outbound, move that PKT away
- Update the LO file with the new path.
- Clear BSY
FlexToss developer there. FlexToss was created back in the days to handle swiss backbone traffic.
I'm in the (un)lucky position, that i develop my tosser myself,Yes, me too... ;-)
so i could do that.
It's quite easy:
- Check/set BSY
- Read LO files
- If there's a PKT referenced in the outbound, move that PKT away
- Update the LO file with the new path.
- Clear BSY
The new path also needs to be configured somewhere! If you have a configuration program, that's probably the most work to add that in
there. ;-)
FlexToss developer there. FlexToss was created back in the daysIs there a website or download for FlexToss?
to handle swiss backbone traffic.
Anyway I don't find it a usefull addition for my tosser, I rather spend my time on something else!
I was not telling, that i wanna do that, i only mentioned that it's possible. But then: How many sysops are nerd enough to inspect
their outbound manually? For now, i count two. (you & me)
Is the original discussion about the insecure outbound over? Can
we focus on something more serious now? ...duck&cover... :)
The new path also needs to be configured somewhere! If you have a
configuration program, that's probably the most work to add that in
there. ;-)
I was not telling, that i wanna do that, i only mentioned that it's possible. But then: How many sysops are nerd enough to inspect
their outbound manually? For now, i count two. (you & me)
Anyway I don't find it a usefull addition for my tosser, I rather
spend my time on something else!
Like watching the outbound, the log file and enabling and disabling %COMPRESS settings manually? ;-P
I'm not convinced we convinced Alan.
There is nothing serious about Fidonet.
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.
Mail arrives in my inbound as it is prepared by other nodes. This is
not a configuration or choice on my part.
My goal in testing is to fix what's broken or to make things work
better when that is possible.
That is incorrect. There is content to transfer.
Then it is worth a secure connection.
insecure inbound that sits there until I find and deal with it.
Best practice: Delete it.
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.
| Sysop: | Rempala |
|---|---|
| Location: | Richlands, NC |
| Users: | 103 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 213:42:52 |
| Calls: | 158 |
| Files: | 6 |
| Messages: | 110,600 |