Jan 🏳️⚧️🇨🇦Welcome to spider-go-splat, Elon. Starlink IP 129.222.250.120 listed for ssh abuse. I won't bother reporting, 'cause I've got all the poop emojis I need.
Looking at the mailcow issues list over the last few days, I'm getting a sense of how it's being worked through. My issue with the cidr maps isn't going to get any attention any time soon, as it's unimportant compared to the stuff being worked on. This is the nature of OSS, and I have no complaints! It just means I need to figure out some other way of getting that information in there. RBL probably won't work; don't really know yet. Going to look for backup plans this weekend.
Gonna have some fun. One of my trap boxes is going to run FreeBSD.
(Trap boxes are the servers that run services I pull abuse logs from. Nothing is done to solicit traffic there, and many efforts are made to weed out unintentional traffic. Trust me -- it's easy to tell the difference between a forgotten fetchmail job and brute force IMAP attacks in several ways, and ditto for other services. The mnemonic is that something has to go to a trap, the trap can't go to the thing.)
Unfortunately, not that I can find.
Pondering it some more, I think that bind9 does allow one to have dynamic zones of some sort, where it queries another data source. That would handle a lot of the drudge work, for sure. Going to read up on that.
It looks like $GENERATE isn't going to work on its own. The tools the docs point to seem to just generate voluminous zone files, which isn't exactly a win when it comes time to reload.
I am thinking about prototyping a daemon in Rust that accepts DNS requests and returns the appropriate results based on a non-zone-file format. This probably means I should be sure this thing doesn't already exist first. 🙂
Okay, so my concerns about data representation in zone files for the RBL seem to be somewhat founded. $GENERATE can do sub-/24 on a single line, but that's still 1024 lines for a /16 (assuming full occupancy as a worst-case, because this is common in one of my data sets). This is going to suck if it runs into a /12 or something. I have a few of those in the IRY dataset.
Yeah, I think I'm going to learn a thing or two about putting together an RBL. Initially, just for the netblocks that participated in the "I recorded you" phishing/harassment, because that's a nice small data set of around 1000 netblocks to play with.
Issue #5396 opened on mailcow/mailcow-dockerized: cidr_map support for Postfix
https://github.com/mailcow/mailcow-dockerized/issues/5396
I think it would be a good addition, and shouldn't be too difficult to implement alongside the regexp maps mailcow already supports.
This seems far less painful than trying to make mailcow listen only on localhost and then bridging with haproxy, and then figuring out how to make haproxy decline mail connections gracefully, and so on.
There is definitely an IP/netblock-based approach to be brought here, but I think the existing RBLs bring enough of what's needed.
I'm considering making spider-go-splat an RBL as well as a list of text files. I could probably teach rspam a new RBL within mailcow.
I think I'm leaning too hard on IPs/netblocks as identifiers for spam and phishing, specifically. For those concerns, I'm going to try to adopt a more address-and-domain-based approach and see where that gets me. That being said, I think I'm also going to submit a feature request for cidr map functionality to be added to mailcow (I'm using its proper name with the lower-case 'm' now -- oops!). I just have to finish reading the existing ones to make sure I don't file a duplicate.