Subj : Netmail in the insecure inbound To : Kai Richter From : Matthias Hertzog Date : Wed 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. 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 * Origin: MHS Systems (2:301/1) .