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.
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.
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.
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.
"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.
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.
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.
The questions is "is it desirable to decompress those packets" in the insecure inbound.
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.
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 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.
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.
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.
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? 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. ;-)
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
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'm not convinced we convinced Alan.
There is nothing serious about Fidonet.
My goal in testing is to fix what's broken or to make things work
better when that is possible.
| Sysop: | Coz |
|---|---|
| Location: | Anoka, MN |
| Users: | 2 |
| Nodes: | 4 (0 / 4) |
| Uptime: | 09:55:31 |
| Calls: | 273 |
| Files: | 5,593 |
| Messages: | 225,375 |