• Netmail in the insecure inbound

    From Alan Ianson@1:153/757 to All on Friday, April 23, 2021 17:12:49
    Hello All,

    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?

    Also, the TZUTC kludge. These replies to ping are not getting a TZUTC kludge although the replies are being written in my local timezone. A TZUTC kludge for
    messages posted by hpt post would be a good thing.

    Ttyl :-),
    Al

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Kai Richter@2:240/77 to Alan Ianson on Saturday, April 24, 2021 09:46:10
    Hello Alan!

    23 Apr 21, Alan Ianson wrote to All:

    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.

    That is the designed process and correct.

    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?

    It's a compromise between security and easy network operation. A not 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.

    Regards

    Kai

    --- GoldED+/LNX 1.1.4.7
    * Origin: Monobox (2:240/77)
  • From Tommi Koivula@2:221/1 to Kai Richter on Saturday, April 24, 2021 12:25:15

    24 Apr 21 09:46, Kai Richter wrote to Alan Ianson:

    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

    No one should send netmail as arcmail, but there are systems that do it.

    Insecure bundles/archives should not be unpacked because of a mailbomb risk.

    Fastecho has an option to allow unpacking insecure arcmail if the compression ratio is below xxx.

    Anyway, those .sec files can be investigated and unpacked in a script outside hpt.

    'Tommi

    ---
    * Origin: rbb.fidonet.fi (2:221/1)
  • From Alan Ianson@1:153/757 to Kai Richter on Saturday, April 24, 2021 04:15:03
    Hello Kai,

    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.

    Netmail that arrives uncompressed is tossed from the insecure directory.

    Even if that netmail is compressed hpt peeks inside the bundle to see who it is
    from and if it is an unconfigured node the bundle is renamed to .sec.

    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. Echomail has never come into it so far but if it ever does then I would request a password/link.

    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.

    Yes, that should never happen and if echomail is found in the insecure inbound it should be left there for investigation and solution.

    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.

    Agreed.

    In any case there is need to talk to the sending sysop.

    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. I hope that node received his reply.

    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 don't care much for pings either, or BBS ads, new file announcements, rules posts.. but each of those things has a role to play.

    I wish ping/trace could tell us what isn't working and why but it can only tell
    us what is working.

    Ttyl :-),
    Al

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Alan Ianson@1:153/757 to Tommi Koivula on Saturday, April 24, 2021 04:42:09
    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.

    Sitting where I am right now I'd be happy if tossers didn't do that. ;)

    Ttyl :-),
    Al

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Tommi Koivula@2:221/1 to Alan Ianson on Saturday, April 24, 2021 15:20:42
    Hi Alan.

    24 Apr 21 04:42:08, you wrote to me:

    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?

    'Tommi

    ---
    * Origin: - rbb.fidonet.fi - Finland - (2:221/1)
  • From Alan Ianson@1:153/757 to Tommi Koivula on Saturday, April 24, 2021 05:39:20
    Hello Tommi,

    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.

    Ttyl :-),
    Al

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Tommi Koivula@2:221/360 to Alan Ianson on Saturday, April 24, 2021 16:21:35
    On 24.4.2021 15:39, Alan Ianson wrote:

    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.

    Yes, that is the way here too, as it should be. In my OS/2 system all mail will
    be processed, secure or not.

    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.

    And if "zipinternal" is used in hpt, you don't really see a difference in speed. :)

    But for netmail, I prefer .pkt.

    'Tommi

    --- Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0
    * Origin: nntp://rbb.fidonet.fi - Lake Ylo - Finland (2:221/360)
  • From Kai Richter@2:240/77 to Tommi Koivula on Sunday, April 25, 2021 12:49:36
    Hello Tommi!

    24 Apr 21, Tommi Koivula wrote to Kai Richter:

    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

    True, but possible.

    No one should send netmail as arcmail, but there are systems that do
    it.

    And no one should support this behavior by searching for solutions to process this mail. Learning by doing. Send insecure arcmail and your mail doesn't reach
    it's destination.

    Regards

    Kai

    --- GoldED+/LNX 1.1.4.7
    * Origin: Monobox (2:240/77)
  • From Kai Richter@2:240/77 to Alan Ianson on Sunday, April 25, 2021 16:03:16
    Hello Alan!

    24 Apr 21, Alan Ianson wrote to Kai Richter:

    Netmail that arrives uncompressed is tossed from the insecure
    directory.

    There your solution is. Get the netmail uncompressed.

    If echomail is found it should be so, if netmail is found it should be tossed?

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

    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.

    We only exchange netmail once in a while so we have never setup a
    secure link.

    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.

    Unless there is a problem

    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.

    Regards

    Kai

    --- GoldED+/LNX 1.1.4.7
    * Origin: Monobox (2:240/77)
  • From Kai Richter@2:240/77 to Alan Ianson on Sunday, April 25, 2021 16:05:26
    Hello Alan!

    24 Apr 21, Alan Ianson wrote to Tommi Koivula:

    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.

    Wrong, you already know it. ;)

    24 Apr 21, Alan Ianson wrote to Louis Northmore:

    Outgoing echomail to this net works fine, just incoming is
    problematic.

    Here's a wild guess, an unknown archiver.

    Compressing adds a layer of complexity.

    Regards

    Kai

    --- GoldED+/LNX 1.1.4.7
    * Origin: Monobox (2:240/77)
  • From Alan Ianson@1:153/757 to Kai Richter on Sunday, April 25, 2021 13:40:42
    Hello Kai,

    Netmail that arrives uncompressed is tossed from the insecure
    directory.

    There your solution is. Get the netmail uncompressed.

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

    Tossing uncompressed insecure netmail is the lowest level to establish first communication with the other sysop. It needs to work on any
    system.

    Yes, it does.

    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.

    Yes, it is.

    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 sometimes receive netmail compressed. In the fidoverse a lot of netmail is compressed, with zip in most cases. I have no problem decompressing those files.

    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.

    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.

    Secure links for possible periodic netmail is not necessary. Even when linked the choice to archive or not is left with the node to make that choice. 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.

    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.

    As it stands today I believe my route files is in good condition and in every case mail that arrives here will be sent towards it's destination via a secure and trusted link.

    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.

    Looking at that from the outside that seems a useless test, something to be avoided. The ping functionality available here is advertised in the nodelist and available to any node who would like to use it in the hopes it will be useful and productive.

    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. It
    arrives in my inbound as prepared by other tossers and mailers and they can and
    do behave differently than my own tosser/mailer.

    Ttyl :-),
    Al

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Alan Ianson@1:153/757 to Kai Richter on Sunday, April 25, 2021 14:36:28
    Hello Kai,

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

    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.

    Ttyl :-),
    Al

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Kai Richter@2:240/77 to Alan Ianson on Monday, April 26, 2021 20:45:54
    Hello Alan!

    25 Apr 21, Alan Ianson wrote to Kai Richter:

    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.

    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.

    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

    Zone Mail Hour is the heart of FidoNet, as this is when network mail is
    passed between systems. Any system which wishes to be a part of FidoNet must be able to receive mail during this time using the protocol defined in the current FidoNet Technical Standards Committee publication (FTS-0001 at this writing). It is permissible to have greater capability (for example, to support additional protocols or extended mail hours), but the minimum requirement is FTS-0001 capability during this one hour of the day.

    This time is exclusively reserved for netmail."

    FTS-0001 is on revision 16 of 1995 and is the definition of the *.pkt format. A
    packet is a bundle of messages that is stored in the type 2 packet format.
    (see line 462 and on)

    Within the introduction text FTS-0001 is open for the future:

    "2. Levels of Compliance

    This documents represents the most basic FidoNet implementation. A future document will define well tested extensions which are optional but provide sufficient additional function that implementors should seriously consider them. SEAdog(tm), from System Enhancement Associates, is an excellent example of such an extended FidoNet implementation."

    Today seadog is outdated in network operation but the minimum definition as most basic implementation for type 2 packets does still apply.

    There are historical reasons why echomail handling with or without compression is not found in the policy. Based on the phone line cost structure in some/many/all?? countries of the USA a local area call was free of additional cost. This is why the host structure was implemented. There was one system responsible for long distance calls and so mass transportation was done by one system only. Local systems didn't need to think about costs and so compression was never required.

    I'm not sure about how the echomail policy was build but this echopol shows how
    to handle compression:

    "11. ECHOMAIL SOFTWARE: EchoMail exchanges may consist of any
    type of archival storage format agreed upon by both parties."

    This is the key element, any other archival format can be used if both sysops agree.

    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. The continued use of Echomail software without
    prior agreement of both the sending and receiving nodes which
    interferes with the distribution of echomail shall lead to
    disciplinary action as described previously in this document.
    See Section III. Examples of prohibited software would include
    the use of non-standard echomail packets which can not be
    processed by the receiving system."

    With enough compression fanatism someone could shout now: "look, ARC is the fallback when the other side is unable to support my compression". But if we consider all of the text then the main purpose of the echopol would rise: Make sure that echomail can be processed.

    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.

    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.

    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.

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

    I am not asking anyone to travel anywhere they don't want/need to
    travel.

    Then don't follow him if he don't want to travel with us.

    The problem is unsecured inbound compressed netmail.

    I need to decompress archived netmail, that has never been a problem.

    Then why it is now? This "new" fault is no issue on your system.

    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.

    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.

    Regards

    Kai

    --- GoldED+/LNX 1.1.4.7
    * Origin: Monobox (2:240/77)
  • From Kai Richter@2:240/77 to Alan Ianson on Monday, April 26, 2021 19:37:12
    Hello Alan!

    25 Apr 21, Alan Ianson wrote to Kai Richter:

    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.

    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.

    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.

    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.

    Regards

    Kai

    --- GoldED+/LNX 1.1.4.7
    * Origin: Monobox (2:240/77)
  • From Kai Richter@2:240/77 to Alan Ianson on Monday, April 26, 2021 21:01:16
    Hello Alan!

    25 Apr 21, Alan Ianson wrote to Kai Richter:

    In the case of ping/trace we are trying to find and solve issues with netmail routing. This seems to be an ongoing battle. In my own case
    the problem has been my own configuration and these pings can help me identify and fix those problems.

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

    Regards

    Kai

    --- GoldED+/LNX 1.1.4.7
    * Origin: Monobox (2:240/77)
  • From Alan Ianson@1:153/757 to Kai Richter on Monday, April 26, 2021 16:45:34
    Hello Kai,

    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.

    Yes it does. I do not want to be or link with the bastard operator from hell.

    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

    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 are historical reasons why echomail handling with or without compression is not found in the policy.

    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 zip, arc, arj and rar archives if they arrive here like that but I only use zip to compress mail if a node wants it that way. That seems to be enough in my experience.

    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 still have arc on my path to extract an arc compressed mail bundle but I haven't seen an arc bundle in years.

    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?

    I do have links for secure routing and it is used at times. When netmail arrives in my inbound it follows my routing rules. When I write a netmail and I
    want to be sure it is received in a timely way I will crash it directly to the node. That is easy to do today and it doesn't cause excessive phone bills like it did in the past.

    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?

    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?

    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.

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

    You can use any archive method I have mentioned. It's possible I could also use
    LHA or ZOO if a node really needed it, but I don't think anyone wants or needs it today.

    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. An actual compression format that would require 66MB for decompression would
    crash the system.

    I would not send mail to your node that was compressed in a way you could not decompress it. You or any node.

    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.

    This not my configuration or choice to make. 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.

    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.

    There has been no force, or need for force.

    I simply bring up my experience for discussion and consideration.

    (i found unwitting by translator. i hope that stands for "he doesn't
    know what he's doing".)

    We are talking about a well respected (at least be me) fido node who does indeed know what he is doing.

    Then why it is now? This "new" fault is no issue on your system.

    I don't think this is new. Once in a while I need to decompress mail in my insecure inbound. I suspect that may happen at other nodes also from time to time.

    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.

    Ttyl :-),
    Al

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Alan Ianson@1:153/757 to Kai Richter on Monday, April 26, 2021 18:18:07
    Hello Kai,

    I don't know that. What is wrong?
    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? Great if you ever heard of them
    before but bad because i'd liked to give an expample of surprizing hardware out there.

    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.

    Ttyl :-),
    Al

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Alan Ianson@1:153/757 to Kai Richter on Monday, April 26, 2021 18:25:48
    Hello Kai,

    In the case of ping/trace we are trying to find and solve issues
    with netmail routing. This seems to be an ongoing battle. In my
    own case the problem has been my own configuration and these
    pings can help me identify and fix those problems.

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

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

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

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

    Ttyl :-),
    Al

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Kai Richter@2:240/77 to Alan Ianson on Wednesday, April 28, 2021 00:23:54
    Hello Alan!

    26 Apr 21, Alan Ianson wrote to Kai Richter:

    [netmail compression]
    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.

    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.

    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 no need for. I don't want to discuss the policy, i quoted the parts as
    a reference for the minimum standard.

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

    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 know and i did wrote that some parts of the policies are outdated before. But
    the important thing was the basic concept of compression use.

    I do have

    The basic concept of the policies is not focused on "i".

    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.

    That was not the question. The question was if the size of the incoming test mails is large enough to justify compression. And again i do see a "my" positon.

    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?

    I qouted all relevant parts in the mail before. If your question is serious please read it.

    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.

    Again i see "i" and "my" and the first step for help should be to tell you to raise your head up from the narrow focus of "i and my" and get a distant point of view to see not only your system but to look what is or should go on in the fidonetwork.

    I bring it up for discussion with other users of the husky software
    for discussion and consideration only.

    And so i answered. My contribution to the discussion is now to tell a network coordinatior to step into the network coordination view mode. The question is not what a good solution for "your" system is. You already thought into the right direction when asking if there is some minimum standard.

    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.

    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.

    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

    1.2.3 Networks and Network Coordinators
    [...]
    The Network Coordinator is responsible for maintaining the list of nodes for the network, and for
    *forwarding netmail sent to members of the network from other FidoNet nodes.*

    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.

    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.

    You put on the "i" glasses again. Btw, you are doing right in this moment what is the minimum standard as per policies, you do agree what kind of compression should be used between your systems. And now, after we both agreed, the compression is in compliance with the minimum 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?

    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.

    I have to say sorry if i used any wording that could be taken as offense. I still have the technical fidonet operation in mind. So "we" are any node that may send netmail. You and i doesn't have an idea what kind of systems or what kind of compression software could be out there.

    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 would not do this, too. And because i do not know what kind of compression the receiving node can handle i would never turn it on for unsecure connects.

    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.

    I do not wish any node delisted, I just want to unpack and toss mail.

    I wish that nodes prefer interaction and find a way to create a reliable amateur electronic mail network. This includes password protected links or uncompressed insecure netmail.

    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.

    Then why and what about are we talking here? Without offense, from a distant all fidonet including overview, he does it wrong. It's his fault that we both are wasting our time about "no issue".

    I will likely talk to this sysop again but I doubt we will discuss
    this, because there is no need.

    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.

    I cannot change the behaviour of other nodes

    You can and you have to. That's your job as network coordinator.

    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 am. I was crawling through policies again, it took hours to collect everything, including dictionary and translation time. I'd like to help, just for fun and it did make me happy as i saw that my idea to use ssh access did lead a ru developer to an us raspi what resulted into a fix for the husky build
    process. I'd like to see that people are still working together to keep fidonet
    up and running. And now this node wasted my time for nothing. Both of you will not work together, now it's my time for guessing he will continue to send other
    nodes unsecure compressed netmails and will cause trouble that could be avoided
    by a simple switch.

    I simply bring up my experience for discussion and consideration.

    But you are not discussing with the source of the issue.

    We are talking about a well respected (at least be me) fido node who
    does indeed know what he is doing.

    Obviously not. His behavior is the inital trigger for this discussion. It is not my intention to blame anyone and network operation does work with respect only. In our case respect to the policies and to common sense. Network operation is based on yes or no descisions and raising the minimum standard to insecure compressed netmail support is a bad idea because the potential of systems that could not support this. We found that for that reason you and i would never send insecure compressed netmail. I call that a serious well argumented reason that will be handled by any fidonet system.

    Anyone and you can. TALK WITH HIM! Do what fidonet is for.
    Communicate!

    That is what I do, and what I am doing.

    I missed that. What did he said? Why he don't turn off compression?

    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 quoted the parts that display that. The important thing of the ZMH is not the
    time in this case. (The ZMH is the heart of FidoNet [...] Any system which wishes to be a part of FidoNet must be able to receive mail during this time *using the protocol defined in the current FTSC publication (FTS-0001)*) The core elements for our question are the minimum protocols per FTS-0001 and those
    doesn't include compression.

    Vice versa you need to send uncompressed mail to make sure that it will be received.

    Regards

    Kai

    --- GoldED+/LNX 1.1.4.7
    * Origin: Monobox (2:240/77)
  • From Kai Richter@2:240/77 to Alan Ianson on Wednesday, April 28, 2021 04:12:44
    Hello Alan!

    26 Apr 21, Alan Ianson wrote to Kai Richter:

    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.

    The problem is the combination of insecure and compression.

    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 don't understand. No matter what you will work around it would never solve the ongoing problems that other nodes could have with insecure compressed netmail.

    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.

    So why does your respected node not do that? Why does he cause inconvenice to you?

    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.

    This exactly the issue you have. An insecure connect is for the first contact with a fidonet system, you as sender do not have any idea what kind of compression is supported. Thus insecure connects must be without compression.

    Regards

    Kai

    --- GoldED+/LNX 1.1.4.7
    * Origin: Monobox (2:240/77)
  • From Kai Richter@2:240/77 to Alan Ianson on Wednesday, April 28, 2021 04:45:00
    Hello Alan!

    26 Apr 21, Alan Ianson wrote to Kai Richter:

    In the case of ping/trace we are trying to find and solve issues
    with netmail routing. This seems to be an ongoing battle. In my
    own case the problem has been my own configuration and these
    pings can help me identify and fix those problems.

    What kind of problems there could be??

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

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

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

    This is common in all networks, sadly.

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

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

    Regards

    Kai

    --- GoldED+/LNX 1.1.4.7
    * Origin: Monobox (2:240/77)
  • From Alan Ianson@1:153/757 to Kai Richter on Thursday, April 29, 2021 04:48:28
    Hello Kai,

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

    Policy takes no position on compression, and rightly so.

    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.

    No, I read everything in your message.

    I'll talk later about the "my node accepts" because i noted "my"
    often.

    I will skip it for brevity. I am speaking to you from my thoughts and experiences I have had over time.

    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?

    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.

    Neither is the size of these netmails. I forgot to answer that 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.

    As proved by the policies we simply do not need to agree to
    receive it.

    I don't see that in policy or fidonet standards.

    What proof, and what policy?

    I qouted all relevant parts in the mail before. If your question is serious please read it.

    Yes, you have spoken of ZMH and our minimum standards. All that is good and it has not been rejected.

    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.

    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!

    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

    Yes, there are responsibilities that go with that.

    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.

    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.

    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.

    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?

    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 was not at the table when these decisions were made.

    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.

    Because it does work for any node this should be the minimum standard.

    What you are saying makes sense but there is no such standard that I have seen.
    If there was one then maybe we would not be having this conversation.

    And because this was known since 30+ years this spirit can be found in
    the policies.

    I see the minimum standards you speak of but policy doesn't get into the subject of compression. I don't think we need or want it to.

    Hell, my jaw is falling down, you *guess* and you see no need to
    talk??

    I did actually write that sysop. I apologized to him for the delay and explained what happened.

    Why are we talking then?

    I explained my problem with netmail not being tossed in the insecure inbound and here we are. If you don't reply I will understand.

    Why are you searching for a solution here,

    That's what I have been wondering too.

    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.

    You can and you have to. That's your job as network coordinator.

    I think you are wrong and I am going to drop the rest of this here and now.

    Ttyl :-),
    Al

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Alan Ianson@1:153/757 to Kai Richter on Thursday, April 29, 2021 06:16:10
    Hello Kai,

    Then there is no ongoning battle?

    No.

    No own configuration problem?

    Not currently, not that I know of.

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

    I'll save you the gory details. ;)

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

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

    Ttyl :-),
    Al

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Kai Richter@2:240/77 to Alan Ianson on Sunday, May 02, 2021 22:00:36
    Hello Alan!

    29 Apr 21, Alan Ianson wrote to Kai Richter:

    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.

    We are going to repeat us. You are still on the "i and my" point of view. You and your system are not part of your problem as noted on the subject line.
    Btw, didn't you told us you have no control about the input to your system?

    (*)
    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?

    To fulfill your responsibiliy as part of the fidonet *C structure.

    Let's reflect your point starting above at (*) to your initial situation:

    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

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

    Like we see now. You can't do automatic decompression for insecure inbounds.

    I think we made a mistake when we started the discussion with a focus on compression. The more important issue is insecure inbound.

    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.

    That's too bad. So size couldn't be put on the "pro compression" list.

    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.

    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.

    Fidonet nodes can arrange their links in a way that works for them.

    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.

    If my tosser can't/won't do it then I'll do it myself!

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

    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.

    Thanks, i'm happy to read that, the last part especially. ;-) Could we keep going on with the "as a whole" hat on?

    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.

    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.

    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 am not remotely qualified to make these kind of judgments.

    I did not judge at that point, i asked why. Trying to understand why people do something is the best way to learn about my own mistakes of prejustice.

    Different nodes and software do things differently. I don't know why.

    I learned one reason. Becaue nobody told them that their way causes trouble.

    I am just trying to get things done on my node in a good a reliable
    way.

    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.

    [always send uncompressed mail to insecure connects]
    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 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.)


    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.

    One node sending insecure compressed mail, other nodes must work around.
    One node stops compression for sending insecure mail, other nodes do nothing.

    Pick the one with lesser issues.

    Regards

    Kai
    --- GoldED+/LNX 1.1.4.7
    * Origin: Monobox (2:240/77)
  • From Kai Richter@2:240/77 to Alan Ianson on Sunday, May 02, 2021 20:48:14
    Hello Alan!

    29 Apr 21, Alan Ianson wrote to Kai Richter:

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

    I'll save you the gory details. ;)

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

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

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

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

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

    Regards

    Kai
    --- GoldED+/LNX 1.1.4.7
    * Origin: Monobox (2:240/77)
  • From Alan Ianson@1:153/757 to Kai Richter on Sunday, May 02, 2021 16:36:34
    Hello Kai,

    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. Nevertheless, I sometimes (once or twice a month) receive netmail in my insecure inbound that is compressed so I must deal with it somehow.

    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. I have not read that in policy
    or standards, so I can't get on board.

    I think we made a mistake when we started the discussion with a focus
    on compression. The more important issue is insecure inbound.

    Yes, I receive netmail in my insecure inbound that is not tossed until I decompress it.

    That's too bad. So size couldn't be put on the "pro compression" list.

    Yes, this is not a concern.

    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 but in the mean time the issue I reported remains.

    That's the point. Compressed insecure inbound does not work reliable
    on all systems.

    How is that? I have not had issues decompressing mail. The only issue is that it sits in my insecure inbound until I find it there.

    Compressed mail CAN be arranged optional AFTER agreement.

    Sure, node can arrange things as they need.

    This would tell us what the minimum configuration for fidonet software
    is and what kind of configuration is an optional enhancement.

    The setup of other fidonet nodes is beyond my control. I don't think arcmail bundles are good or bad. I only know that when an arcmail bundle arrives in my inbound I need to decompress it.

    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.

    I might experiment with exotic hardware or software. If I was using Pyra in Fidonet I would stick to the standards.

    Type 2 packets and arcmail bundles are standard Fidonet fair.

    Sure you can. But i have to remind you that you asked for a solution
    that does not effect your system only:

    I agree. The husky developers have to keep the big picture in mind and I think they have always done that.

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

    Yes it does. I am not a husky developer and am going to make no changes.

    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 don't think we are searching for a standard. The standards are all in place.

    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.

    I think that is the case now. An arcmail bundle is no surprise and it may contain netmail and/or echomail.

    I think that has been the case for a very long time.

    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.

    Of course that doesn't mean it doesn't happen. I am familiar with a number of different software used in fidonet. Sometimes they just go ahead and compress netmail/echomail and then send it to the destination.

    It would be best if they didn't do that but I am in no position to change that behaviour. I don't mind discussing that with with the author of the software and asking them to consider a change but that depends on those authors listening to what I have to say and ...

    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.

    They could start by talking the node that sent the compressed mail and I'm sure
    the node would arrange uncompressed mail for them.

    It would be a big effort to change the habits of fidonet nodes and I don't know
    if that effort would be met with much success or not. Not because fidonet nodes
    are bad but because fidonet nodes software works the way it does along with the
    setup fidonet nodes have put in place.

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

    Yes, I have been given the NC 153 hat for now. Lets discount those responsibilities for this discussion. N153C or not, I am a fidonet node and fidonet is important to me. I will always conduct myself in a way that is good for my own node and fidonet generally.

    I learned one reason. Becaue nobody told them that their way causes trouble.

    Does it actually cause 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.

    Yes, I have thought about that. Until now I am simply making my way to my insecure inbound and decompressing bundles I find there and doing what needs to
    be done.

    A modification for hpt would lower the security level on all systems
    that work with hpt.

    If decompressing arcmail bundles is a security risk then we don't want to do that. I am not suggesting that hpt should act in an insecure way.

    If it did that I wouldn't use it.

    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:

    We are doing that.

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

    True, but that is not the case so they can be 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."

    Yes, those minimum standards are critical and they have not been set aside.

    Packed to conserve space. Sounds exactly like compression to me. And
    this critial structure is transferred actually.

    It sounds like compression because that is what it is. Compression is not a bad
    thing. I only compress packets when a node is configured for that and most are,
    even today.

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

    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.

    It is. The network is operating smoothly here, even if mail is compressed.

    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.

    There maybe troubles to be had, but arcmail bundles are not it.

    Ttyl :-),
    Al

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Alan Ianson@1:153/757 to Kai Richter on Sunday, May 02, 2021 18:50:19
    Hello Kai,

    I'll save you the gory details. ;)

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

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

    Nothing to report today. ;)

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

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

    Insecure ping does create hot air issues in most cases.

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

    Ttyl :-),
    Al

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Oli@2:280/464.47 to Alan Ianson on Monday, May 03, 2021 12:03:42
    Alan wrote (2021-05-02):

    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.

    ---
    * Origin: . (2:280/464.47)
  • From Kai Richter@2:240/77 to Alan Ianson on Monday, May 03, 2021 16:38:00
    Hello Alan!

    02 May 21, Alan Ianson wrote to Kai Richter:

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

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

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

    Insecure ping does create hot air issues in most cases.

    Ping is neither secure nor insecure.

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

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

    Regards

    Kai
    --- GoldED+/LNX 1.1.4.7
    * Origin: Monobox (2:240/77)
  • From Kai Richter@2:240/77 to Alan Ianson on Monday, May 03, 2021 19:45:46
    Hello Alan!

    02 May 21, Alan Ianson wrote to Kai Richter:

    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?

    The one of an disinteressted party or a neutral observer. You already stated that you have the whole of fidonet in view. Back to the start i did understand that you were asking for a change in a security feature of hpt that would effect many nodes. Having the whole fidonet in view i started to argue.

    Just for confirmation and to avoid misunderstanding: I do not have any issues what your system only would do with non-secure inbound files locally. If you think that automatic process of insecure inbound is not a risk you could do what you want because at last you are responsible for what your system will send to others.

    The only advice i'd like to mention is that there is a reason why binkd and tossers do support security features with password protection.

    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.

    Mailers do not receive netmails they receive files only.

    The file that have been transfered to you is an arcmail archive.

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

    The FTS requirement is to transfer that data structure of packed messages.

    That transfered arcmail archive is not in compliance with the FTS-0001 standard.

    The questions is "is it desirable to decompress those packets" in the insecure inbound.

    Generally spoken without further context i would answer with "No because of security reasons".

    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.

    The question is what the whole fidonet can. Do you remember? We have the whole fidonet view active. And please remember "when" we are now. We are at the first
    connect between two nodes that do not have an idea what is working on the other
    side. None of them would know what archiver the other side hates and rejects to
    support. So both needs to stick on the FTS-0001 level to ensure that the other one could read their mail.

    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?

    I wrote that in detail in the mail where i said i do.

    If you can quote policy or fidonet standards that say that
    archiving mail is bad, or wrong I will change my position.

    See above.

    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.

    Why did you stopped reading after the first sentence?

    I said it does need because it must be sure that both parties can process the mail - this is the reason why something must be defined.

    And then i said that's why the the format is defined by policy - that is written in the policy now.

    Finally and compression is not part of the defined format - so there is no reason to update the policy because all important things for first connects is there.

    That would not be an easy thing to do in fidonet. I would be
    agreeable to that also

    By now i'm going to think you don't really know what you are doing. Put that on
    the table seriously and it would kill half of the fidonet by violent fits of laughter. ;-)


    That's the point. Compressed insecure inbound does not work
    reliable on all systems.

    How is that?

    Due to the negotation of "yes, i can guarantee that
    -all nodes can run any archiver
    -all nodes allow anything for insecure inbound because it's save
    -all nodes check their insecure inbound every hour/day/whatever"

    All that is wrong and i have no idea if or when compressed insecure archives will be processed.

    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.

    And now the importent part: For secure links. If i do a negotiation with the other node first we can set our passwords and agree on the used compression software. We have full automatic mailflow without manual interaction because we
    switched to secured connects.

    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.

    Whole fidonet view, nobody should compress netmail for insecure connects.

    It would be best if they didn't do that but I am in no position to
    change that behaviour.

    But you can talk about the problem. You could simply ask for turning off compression or you could offer a secure link.

    I learned one reason. Becaue nobody told them that their way
    causes trouble.

    Does it actually cause trouble?

    3x ~10k mails are an indicator those days. ;-)
    But i'm willing to correct to "can cause trouble".
    Edit: And after saving i see #3 is 6,5K only.

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

    Oh. I should keep that in mind.

    Regards

    Kai
    --- GoldED+/LNX 1.1.4.7
    * Origin: Monobox (2:240/77)
  • From Alan Ianson@1:153/757 to Oli on Monday, May 03, 2021 16:04:44
    Hello Oli,

    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.

    The question I am considering is the above. Do we want to decompress those packets in the insecure inbound". Currently hpt tosses uncompressed packets in the insecure inbound. The issue arises when netmail is compressed in an arcmail
    bundle. 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.

    Pre-compressed mail bundles are mostly useless in this scenario.

    Why are they useless? They contain packets that contain mail that needs to be tossed. They are just as useful today as they were in 1995.

    Files can be compressed on the fly over the binkp protocol.

    Yes, this is my preferred method today and I use this method with several nodes
    that also use it. It's not well supported outside of binkd, at least not yet.

    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.

    Ttyl :-),
    Al

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Alan Ianson@1:153/757 to Kai Richter on Monday, May 03, 2021 16:36:36
    Hello Kai,

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

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

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

    The connects do happen. That is not a problem. The issue is netmail that is compressed, the recipient is irrelevant.

    Insecure ping does create hot air issues in most cases.

    Ping is neither secure nor insecure.

    Wrong.

    Bzzt. Wrong.

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

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

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

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

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

    We do toss netmail in the secure and insecure inbound as we should.

    The question is simply..

    Is it desirable to decompress netmail in the insecure inbound that has arrived in the form of an arcmail compressed mail bundle?

    I am suggesting that we do that for netmail. Currently hpt checks the origin of
    arcmail bundles and if it comes from an unknown node it is not decompressed and
    tossed. Perhaps we could also check if the mail is netmail or echomail and if it is netmail then go ahead and toss it.

    Echomail should never be tossed or even upacked in the insecure inbound.

    Is there some kind of security risk in doing that?

    I agree with you that nodes should always send netmail uncompressed and I always do that. However if I receive netmail in compressed form, and I do receive it that way from time to time that we process it.

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

    Ttyl :-),
    Al

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Oli@2:280/464.47 to Alan Ianson on Tuesday, May 04, 2021 09:17:04
    Alan wrote (2021-05-03):

    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.

    ---
    * Origin: . (2:280/464.47)
  • From Alan Ianson@1:153/757 to Oli on Tuesday, May 04, 2021 03:14:50
    Hello Oli,

    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.

    I suppose there could be something to that. I have encountered many attitudes over the years. But in the issue I brought up there are no attitudes, buggy software or ignored FTN standards.

    Reject the mail,

    How, why?

    let them complain and learn.

    I am not teaching anyone anything, and if I was I would use a different method.

    Ttyl :-),
    Al

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Oli@2:280/464.47 to Alan Ianson on Tuesday, May 04, 2021 12:59:23
    Alan wrote (2021-05-03):

    The question is simply..

    Is it desirable to decompress netmail in the insecure inbound that has arrived in the form of an arcmail compressed mail bundle?

    no, it isn't.

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

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

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

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

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

    ---
    * Origin: . (2:280/464.47)
  • From Alan Ianson@1:153/757 to Oli on Tuesday, May 04, 2021 06:27:11
    Hello Oli,

    you don't decompress netmail,

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

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

    I would call that excessively annoying.

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

    OK.

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

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

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

    Ttyl :-),
    Al

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Kai Richter@2:240/77 to Alan Ianson on Tuesday, May 04, 2021 13:18:50
    Hello Alan!

    03 May 21, Alan Ianson wrote to Oli:

    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.

    The question is not if a tosser can compress/decompress.

    We are talking about insecure inbound handling. Compression rate for ftn format
    is approx. 80%. In case of security issues the power of the attack increases by
    factor 5 due to compression.

    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.

    This is because it is insecure inbound and it's the task of the node to do the security check.

    Regards

    Kai
    --- GoldED+/LNX 1.1.4.7
    * Origin: Monobox (2:240/77)
  • From Kai Richter@2:240/77 to Alan Ianson on Tuesday, May 04, 2021 16:47:40
    Hello Alan!

    03 May 21, Alan Ianson wrote to Kai Richter:

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

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

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

    The connects do happen. That is not a problem. The issue is netmail
    that is compressed, the recipient is irrelevant.

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

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

    Do one step back and get aware that insecure compressed ping creates problems for no reason other than to have a problem to be solved.

    ==========

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

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

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

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

    Is it desirable to decompress netmail in the insecure inbound that has arrived in the form of an arcmail compressed mail bundle?

    I am suggesting that we do that for netmail.

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

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

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

    I agree with you that nodes should always send netmail uncompressed

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

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

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

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

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

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

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

    What will be then? Would you simply say i'm no longer part of fidonet if i can't support compression? Or will you invent a "noarc" flag for the nodelist that any node does know that i do not support compression?

    You intention for easy going with compressed insecure mail will backfire then because you have to install the "unarc" flag condition to the whole fidonet systems including yours. See the top of this mail, you're creating issues where
    are none.

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

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

    Compression after agreement is defined by the echopol and that is a freedom i'd
    like to see for the whole fidonet. You can use any compression tool you like if
    both parties agree.

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

    Regards

    Kai
    --- GoldED+/LNX 1.1.4.7
    * Origin: Monobox (2:240/77)
  • From Matthias Hertzog@2:301/1 to Kai Richter on Wednesday, May 05, 2021 05:11:34
    Hello Kai!

    FlexToss developer there. FlexToss was created back in the days to handle
    swiss backbone traffic. One of our sports back then was to test eachothers system security, on full ethical basis, of course. No system was 'attacked' without prior notice and agreement with the sysop.

    We did wild things back then and improved our tools. With security in mind,
    i like to weigh in on this discussion as i seee the comfort factur (not to
    say the factor of lazyness) is getting a bit strong.

    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.
    That is the designed process and correct.

    100% agree.

    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.

    100% agree.

    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.

    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.

    Echomail should not be tossed from the insecure inbound, but
    netmail in the insecure inbound should?
    It's a compromise between security and easy network operation. A not
    so golden but middle path.

    100% agree, but i'm even thinking about tossing netmails from
    insecure inbound to a special netmail directory. If i receive
    something in there, i'll have to look twice what it is, where it came
    from and if it's legitimate.

    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.

    Especially in the non-POTS age, the risk is even higher as bandwidth
    is not an issue. Delivering a mailbomb back in the days meant sending
    1MB of data to the target system and then wait until the unpacker folded it
    up until it was 1GB. If that did not fill the disk, another 1MB transfer
    would suffice to finally bring down the target.
    Today, we deliver hundrets ob megabytes within no time, you'd not even
    see it coming when looking at your BinkD window. Delivering hundrets
    of them is easy and if inbound unpacker scripts are dumb enough to
    process the garbadge, welcome back in the days of full disks, service interruption and a lot of work to cleanup that mess.

    Unsecured echomail bundles are a configuration error in most cases.

    Exactly.

    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.

    That's a bit harsh, but yes, sending unwanted stuff will create work at
    the destination target (if one is not that crazy to allow autocreation of
    areas in the unsecure inbound). So it's disrespectful anyway. Depending
    on if i see the behaviour as an error or rudeness of the sending sysop,
    i'd consider just deleting the thing or simply sending the bullshit back.
    And believe me, i'm good at automating such things.

    In any case there is need to talk to the sending sysop.

    I've spent the last weeks arranging secure connections with a lot of
    people. 90% of all sysops i've contacted gave feedback within a fair
    amount of time. While i'm a little nerdy and established a lot of connections, most sysops will have one or two. That's doable. And: If two sysops cannot agree a session pasword together, one of them is not a good partner to deal with anyway.

    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 havn't looked at PING in detail yet, but will do so as soon my netmail tracker called "ShiTrack" is in place again. It detects all kind of garbadge that is trown at my system, from routed echomails to lousy message preparing.

    So, folks, please keep security and kindness in mind:
    - Talk to your sysop colleagues when establishing links/feeds
    - Agree on session passwords, at least for the AKAs used for mail processing
    - Agree on PKT passwords ... and i know some people think, this is an overkill,
    but i don't think so. Every possible layer of security matters, especially
    in a network where we send unencrypted passwords in our mails to *fix
    things. Which brings me to the last topic:
    - Use different passwords for Session, PKT, Areafix and Raid/TIC.

    Enjoy the ride, stay (or get) safe & have fun!

    Matthias
    --- GoldED+/W64-MSVC 1.1.5-b20180707
    * Origin: MHS Systems (2:301/1)
  • From Matthias Hertzog@2:301/1 to Tommi Koivula on Wednesday, May 05, 2021 05:39:01
    Hello Tommi!

    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

    It makes no sense to try to exchange echomails with every node
    in the nodelist. Even with the nodelist being that small already.

    For netmail transport, one can send uncompressed PKTs or route the netmail
    and leave the security process to people who agreed on a link, like
    we two did :-)

    Matthias
    --- GoldED+/W64-MSVC 1.1.5-b20180707
    * Origin: MHS Systems (2:301/1)
  • From Matthias Hertzog@2:301/1 to Alan Ianson on Wednesday, May 05, 2021 05:41:50
    Hello Alan!

    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.

    Is there any reason to compress netmail prior to sending nowdays?
    I don't see one, and i'm a bandwith-saving-guy.

    Matthias
    --- GoldED+/W64-MSVC 1.1.5-b20180707
    * Origin: MHS Systems (2:301/1)
  • From Matthias Hertzog@2:301/1 to Tommi Koivula on Wednesday, May 05, 2021 05:43:15
    Hello Tommi!

    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?

    Exactly.

    Matthias
    --- GoldED+/W64-MSVC 1.1.5-b20180707
    * Origin: MHS Systems (2:301/1)
  • From Matthias Hertzog@2:301/1 to Alan Ianson on Wednesday, May 05, 2021 05:43:48
    Hello Alan!

    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.

    Do you allow me to try to fill your disk? On ethical basis with prior notice of
    course.

    Feel free to enjoy the ride...

    Matthias
    --- GoldED+/W64-MSVC 1.1.5-b20180707
    * Origin: MHS Systems (2:301/1)
  • From Alan Ianson@1:153/757 to Kai Richter on Tuesday, May 04, 2021 19:30:25
    Hello Kai,

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

    That is incorrect. There is content to transfer.

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

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

    To that end I just sent a ping to a node I want to communicate with and am just
    awaiting a reply. If I don't get a reply to that ping I will send the mail directly.

    Do one step back and get aware that insecure compressed ping creates problems for no reason other than to have a problem to be solved.

    Ping creates no problems at all whether it is sent/received directly or routed.
    It is just a tool available to us.

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

    That is up to the husky developers. I am only trying to solve the issue I reported.

    The husky developers may have read my comments, I don't know. But I have not asked them to change anything, and I will not.

    I agree with you that nodes should always send netmail
    uncompressed

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

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

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

    Selfish nodes?

    I will certainly suggest this to nodes when I can do that. I think that's the right thing to do. I don't think I am in any kind of position to change the way
    this does happen in fidonet.

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

    I suggested nothing of the sort. Individual nodes can and will support the compression methods they choose, if any.

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

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

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

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

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

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

    I would not invent a noarc flag for several reasons. A netmail will leave my node uncompressed but it may be compressed along the way, this is beyond my control. That may or may not be a problem for the destination node.

    You intention for easy going with compressed insecure mail will
    backfire then because you have to install the "unarc" flag condition
    to the whole fidonet systems including yours. See the top of this
    mail, you're creating issues where are none.

    I am creating no issues. Archived netmail is in my insecure inbound and I need to decompress it so it can be tossed.

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

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

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

    Compression after agreement is defined by the echopol and that is a freedom i'd like to see for the whole fidonet. You can use any
    compression tool you like if both parties agree.

    What echopol? My own use of compression/decompression (if needed) is not defined by echopol. It is simply used as needed.

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

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

    Ttyl :-),
    Al

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Alan Ianson@1:153/757 to Matthias Hertzog on Tuesday, May 04, 2021 21:15:02
    Hello Matthias,

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

    Ttyl :-),
    Al

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Alan Ianson@1:153/757 to Matthias Hertzog on Tuesday, May 04, 2021 21:19:25
    Hello Matthias,

    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.

    Feel free to enjoy the ride...

    Lovin' every minute of it.

    Ttyl :-),
    Al

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Matthias Hertzog@2:301/1 to Alan Ianson on Wednesday, May 05, 2021 06:29:53
    Hello Alan!

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

    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.

    :-)

    On ethical basis with prior notice of course.
    Are those my ethics, or yours.

    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.

    Don't worry.

    Matthias
    --- GoldED+/W64-MSVC 1.1.5-b20180707
    * Origin: MHS Systems (2:301/1)
  • From Matthias Hertzog@2:301/1 to Alan Ianson on Wednesday, May 05, 2021 06:40:15
    Hello Alan!

    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.

    Yep, Bink does a fine job on compressing. So we all can be happy.

    Matthias
    --- GoldED+/W64-MSVC 1.1.5-b20180707
    * Origin: MHS Systems (2:301/1)
  • From Alan Ianson@1:153/757 to Matthias Hertzog on Tuesday, May 04, 2021 21:51:11
    Hello Matthias,

    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.

    OK, good to know.. :)

    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.

    You can feel free to test things that need testing against my node (or BBS) at any time and if you find a weakness I'd appreciate it if you'd let me know.

    If you asked me to test something against your node I would be happy to do that. I have spent and will continue to spend time testing things that need to be tested.

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

    Ttyl :-),
    Al

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Alan Ianson@1:153/757 to Matthias Hertzog on Tuesday, May 04, 2021 21:57:27
    Hello Matthias,

    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.

    Yes it does. If nodes would use that method my issue would not happen.

    There is always tomorrow. :)

    Ttyl :-),
    Al

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Wilfred van Velzen@2:280/464 to Matthias Hertzog on Wednesday, May 05, 2021 08:43:08
    Hi Matthias,

    On 2021-05-05 05:11:34, you wrote to Kai Richter:

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

    Bye, Wilfred.
    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Matthias Hertzog@2:301/1 to Wilfred van Velzen on Wednesday, May 05, 2021 09:38:25
    Hello Wilfred!

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

    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.

    Matthias
    --- GoldED+/W64-MSVC 1.1.5-b20180707
    * Origin: MHS Systems (2:301/1)
  • From Wilfred van Velzen@2:280/464 to Matthias Hertzog on Wednesday, May 05, 2021 09:54:12
    Hi Matthias,

    On 2021-05-05 09:38:25, you wrote to me:

    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.

    Indeed. That's why I use the threshold of 1 or 2 days. Most connection problems
    are solved within that period.

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

    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.

    That works too! ;)

    Bye, Wilfred.
    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Matthias Hertzog@2:301/1 to Wilfred van Velzen on Wednesday, May 05, 2021 09:59:24
    Hello Wilfred!

    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.

    My tosser stops packing when reaching WEZ. It saves the prepared PKTs for
    later compressing. However, that's turned OFF here anyway.

    Matthias
    --- GoldED+/W64-MSVC 1.1.5-b20180707
    * Origin: MHS Systems (2:301/1)
  • From Oli@2:280/464.47 to Wilfred van Velzen on Wednesday, May 05, 2021 09:44:32
    Wilfred wrote (2021-05-05):

    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.

    ---
    * Origin: . (2:280/464.47)
  • From Matthias Hertzog@2:301/1 to Oli on Wednesday, May 05, 2021 11:08:29
    Hello Oli!

    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.

    That's indeed a nice idea. I'm doing almost the same with my TIC outbound.

    Matthias
    --- GoldED+/W64-MSVC 1.1.5-b20180707
    * Origin: MHS Systems (2:301/1)
  • From Wilfred van Velzen@2:280/464 to Matthias Hertzog on Wednesday, May 05, 2021 10:57:35
    Hi Matthias,

    On 2021-05-05 09:59:24, you wrote to me:

    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.

    It's up to the mailer at the other end, what happens with the file if it already exists. Binkd has an option for this:

    # Rename style if file with the same name already exists in inbound
    # rename-style [postix|extension]
    #
    # 'postfix' append number at the end of filename, after dot (default)
    # example: file.ext -> file.ext.1
    # 'extension' change filename extension
    # example: file.ext -> file.ex0
    #
    # Not applied to *.pkt, arcmail, *.tic, *.req - only filename is changed
    # for these file types.

    It seems to work fine...


    Bye, Wilfred.
    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Wilfred van Velzen@2:280/464 to Oli on Wednesday, May 05, 2021 11:00:48
    Hi Oli,

    On 2021-05-05 09:44:32, you wrote to me:

    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.

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

    Bye, Wilfred.
    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Matthias Hertzog@2:301/1 to Wilfred van Velzen on Wednesday, May 05, 2021 11:30:17
    Hello Wilfred!

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

    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 (-:

    cu, Matthias
    --- GoldED+/W64-MSVC 1.1.5-b20180707
    * Origin: MHS Systems (2:301/1)
  • From Wilfred van Velzen@2:280/464 to Matthias Hertzog on Wednesday, May 05, 2021 11:44:05
    Hi Matthias,

    On 2021-05-05 11:30:17, you wrote to me:

    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 (-:

    Ok I understand. (And there's only the .?lo file)
    But your tosser would have to support that, and it currently doesn't...

    Bye, Wilfred.
    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Matthias Hertzog@2:301/1 to Wilfred van Velzen on Wednesday, May 05, 2021 11:49:21
    Hello Wilfred!

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

    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

    Or having two outbounds is possible as well, but more work with
    BSY in both directions.

    Matthias
    --- GoldED+/W64-MSVC 1.1.5-b20180707
    * Origin: MHS Systems (2:301/1)
  • From Wilfred van Velzen@2:280/464 to Matthias Hertzog on Wednesday, May 05, 2021 11:58:00
    Hi Matthias,

    On 2021-05-05 11:49:21, you wrote to me:

    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.

    Yes, me too... ;-)

    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

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

    Anyway I don't find it a usefull addition for my tosser, I rather spend my time
    on something else!

    Bye, Wilfred.
    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Oli@2:280/464.47 to Matthias Hertzog on Wednesday, May 05, 2021 11:07:34
    Matthias wrote (2021-05-05):

    FlexToss developer there. FlexToss was created back in the days to handle swiss backbone traffic.

    Is there a website or download for FlexToss?

    ---
    * Origin: . (2:280/464.47)
  • From Matthias Hertzog@2:301/1 to Wilfred van Velzen on Wednesday, May 05, 2021 12:08:41
    Hello Wilfred!

    I'm in the (un)lucky position, that i develop my tosser myself,
    so i could do that.
    Yes, me too... ;-)

    I know, comrade! :-)

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

    Matthias
    --- GoldED+/W64-MSVC 1.1.5-b20180707
    * Origin: MHS Systems (2:301/1)
  • From Matthias Hertzog@2:301/1 to Oli on Wednesday, May 05, 2021 12:12:18
    Hello Oli!

    FlexToss developer there. FlexToss was created back in the days
    to handle swiss backbone traffic.
    Is there a website or download for FlexToss?

    Website? What's that? ;-)

    Seriously: There's not, but i'm willing to give it as win32 exe for everyone who likes to test it. Runs on Windows. Runs fine, but runs on windows.

    As the tosser is only one part of an entire suite of tools (AreaLink, FileLink, ShiTrack, FlexToss), it makes no sense to implement it as tosser-only setup.

    I once thought about creating a nodekit with it, but then came internet and
    the idea vanished. Would be easy today. BinkD + GoldED + my Tools => done.

    Hmm... aaah, noone cares. Forget it. Not worth the time probably.

    Matthias
    --- GoldED+/W64-MSVC 1.1.5-b20180707
    * Origin: MHS Systems (2:301/1)
  • From Oli@2:280/464.47 to Wilfred van Velzen on Wednesday, May 05, 2021 11:36:29
    Wilfred wrote (2021-05-05):

    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

    ---
    * Origin: . (2:280/464.47)
  • From Oli@2:280/464.47 to Matthias Hertzog on Wednesday, May 05, 2021 11:40:04
    Matthias wrote (2021-05-05):

    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)

    I'm sure there are a lot more (I wonder how many read the routed passthrough netmail).

    Is the original discussion about the insecure outbound over? Can
    we focus on something more serious now? ...duck&cover... :)

    I'm not convinced we convinced Alan.

    There is nothing serious about Fidonet.

    ---
    * Origin: . (2:280/464.47)
  • From Wilfred van Velzen@2:280/464 to Matthias Hertzog on Wednesday, May 05, 2021 12:56:29
    Hi Matthias,

    On 2021-05-05 12:08:41, you wrote to me:

    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)

    Well, I'm doing it half manual. ;)

    I've written a little python script that prints a report about what is in my outbound directories, that I run manually on occasion...

    Bye, Wilfred.
    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Wilfred van Velzen@2:280/464 to Oli on Wednesday, May 05, 2021 12:58:04
    Hi Oli,

    On 2021-05-05 11:36:29, you wrote to 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

    Yes, that is very important! ;)

    Bye, Wilfred.
    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Alan Ianson@1:153/757 to Oli on Wednesday, May 05, 2021 04:12:13
    Hello Oli,

    I'm not convinced we convinced Alan.

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

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

    There is nothing serious about Fidonet.

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

    Ttyl :-),
    Al

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Kai Richter@2:240/77 to Alan Ianson on Thursday, May 06, 2021 20:59:08
    Hello Alan!

    04 May 21, Alan Ianson wrote to Kai Richter:

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

    That is incorrect. There is content to transfer.

    Then it is worth a secure connection.

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

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

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

    To that end I just sent a ping to a node I want to communicate with
    and am just awaiting a reply. If I don't get a reply to that ping I
    will send the mail directly.

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

    Do one step back and get aware that insecure compressed ping
    creates problems for no reason other than to have a problem to be
    solved.

    Ping creates no problems at all whether it is sent/received directly
    or routed. It is just a tool available to us.

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

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

    That is up to the husky developers.

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

    I am only trying to solve the issue I reported. The husky developers
    may have read my comments, I don't know. But I have not asked them to change anything, and I will not.

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

    I agree with you that nodes should always send netmail
    uncompressed

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

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

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

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

    Selfish nodes?

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

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

    That would be great.

    I think that's the right thing to do. I don't think I am in any kind
    of position to change the way this does happen in fidonet.

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

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

    I suggested nothing of the sort. Individual nodes can and will support
    the compression methods they choose, if any.

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

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

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

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

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

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

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

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

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

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

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

    I would not invent a noarc flag for several reasons.

    Thanks.

    A netmail will leave my node uncompressed but it may be compressed
    along the way, this is beyond my control. That may or may not be a
    problem for the destination node.

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

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

    You intention for easy going with compressed insecure mail will
    backfire then because you have to install the "unarc" flag
    condition to the whole fidonet systems including yours. See the
    top of this mail, you're creating issues where are none.

    I am creating no issues. Archived netmail is in my insecure inbound
    and I need to decompress it so it can be tossed.

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

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

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

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

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

    Compression after agreement is defined by the echopol and that is
    a freedom i'd like to see for the whole fidonet. You can use any
    compression tool you like if both parties agree.

    What echopol? My own use of compression/decompression (if needed) is
    not defined by echopol. It is simply used as needed.

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

    Sending compression to others is not your own use.

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

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

    Best practice: Delete it.

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

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

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

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

    Regards

    Kai
    --- GoldED+/LNX 1.1.4.7
    * Origin: Monobox (2:240/77)
  • From Kai Richter@2:240/77 to Alan Ianson on Thursday, May 06, 2021 20:21:20
    Hello Alan!

    04 May 21, Alan Ianson wrote to Matthias Hertzog:

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

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

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

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

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

    Regards

    Kai
    --- GoldED+/LNX 1.1.4.7
    * Origin: Monobox (2:240/77)
  • From Alan Ianson@1:153/757 to Kai Richter on Friday, May 07, 2021 03:12:09
    Hello Kai,

    That is incorrect. There is content to transfer.

    Then it is worth a secure connection.

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

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

    Best practice: Delete it.

    Thank you for your advice.

    Ttyl :-),
    Al

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Matthias Hertzog@2:301/1 to Alan Ianson on Friday, May 07, 2021 16:54:15
    Hello Alan!

    That is incorrect. There is content to transfer.
    Then it is worth a secure connection.
    We've been over this so I'll make this short.

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

    insecure inbound that sits there until I find and deal with it.
    Best practice: Delete it.

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

    Never change a winning team.

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