• Netmail in the insecure inbound

    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)