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.

 AI>> I received netmail in my insecure inbound addressed to Ping. This
 AI>> netmail arrived in an arcmail bundle and it was not unpacked, it
 AI>> was renamed to .sec and left in the insecure inbound for me to
 AI>> unpack and toss.
 KR> That is the designed process and correct.

100% agree.

 AI>> It is normal to receive netmail in the insecure inbound.
 KR> Yes, because it's the only way to establish a first contact with the
 KR> sysop. At this point the netmail is still not tossed and stored in the
 KR> insec inbound.

100% agree.

 AI>> I wonder if it is possible for hpt to unpack those arcmail
 AI>> bundles and toss the packets within if they are netmail.
 KR> 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.

 AI>> Echomail should not be tossed from the insecure inbound, but
 AI>> netmail in the insecure inbound should?
 KR> It's a compromise between security and easy network operation. A not
 KR> 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.

 KR> Insecure bundles/archives should not be unpacked because of a mailbomb
 KR> risk. I do know we are not in the POTS age anymore but i'd like to
 KR> 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.

 KR> Unsecured echomail bundles are a configuration error in most cases.

Exactly.

 KR> Sending echomail bundles without negotating with the sysop first is
 KR> annoying behavior if it's "wanted" echomail and xab if it's any form
 KR> 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.

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

 KR> And that is why i do dislike the existence of PING. It's results are
 KR> mostly useless. A PING result would tell me that mailer, tosser and
 KR> PING bot are up and running - but for any other problems i do need a
 KR> contact with the sysop. I need a human being on the other side or we
 KR> 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