All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
What are the features you want in a RBL?
I know people here have mixed feelings about realtime blacklists. Some of you because you deserve the be listed and you know it, others because you feel like they're punishing you for things that aren't your fault. With that said, it's obvious that they're not going away. Rallying against them has proven to be a futile effort for quite some time, and at this point just looks desperate (because why keep doing something that isn't working?).
I have a vision of revolutionizing the realtime blacklist for reasons that I'll be quite transparent about, before I ask for your thoughts:
- Fair, based on facts, firm but always open to discussion. It shouldn't feel like it's run by someone who isn't approachable and who isn't open to discussion. I realize that at scale this can be hard, which is why it needs commercial support to be sustainable.
- Powerful for blocking spam. It should function to significantly reduce inbound spam on servers that use it, or else it has no reason to exist.
- It should hold providers accountable and devalue their assets in reaction to their failures, by reducing the functions their IP addresses can serve if they decide to support spammers. No favorites, I've listed @Francisco before and he's cool as shit.
- It should be transparent and willing to prove it's positions. If an IP/range is blocked, the RBL should be able to openly make a factual case for the listing. No secrets.
- It should aim to assist providers by lowering the overhead required to police their networks, by offering them simple integrations for handling abuse on their network. Maybe even automating via API (perhaps with an abuse.io integration?).
- It should add incentive for transparency and fair behavior by devaluing the assets (IPv4, for example) of companies that attempt to gain unfair market positions through extortion (ex. "Buy our spam filtering software or maybe your IP addresses will be blocked by the servers run by the people who do").
- It should increase the value of MXroute by assisting to provide strong spam filtering and mostly clean inboxes with minimal to no false positives. This is the point that finishes #1 above by financially justifying it's existence and development.
Now that you know my set of goals for MXRBL, I want to hear from you. What are the things you want to see in an RBL? Set aside if you don't want them to exist, accept that they do, and tell me how they can exist while helping you to better manage abuse from your servers.
Tomorrow morning I'm entering into a strong development phase and your input could shape an RBL that is growing at a fairly rapid pace (people all around the world are already using it).
Comments
Ability to pay for delisting
I'll need the 24 pack of Red Bull on my doorstep before we can talk.
I can breathe again!
[Perhaps.]
Imagine entering an ASN and immediately accessing a provider-specific portal that includes a list of blocked IPs, redacted (hiding recipient info) logs proving that it was deserved, and providing easy export for logs with generated abuse complaints. Not only can you as a consumer pop in there and say "I want to know if this network is clean" but the provider can pop in and say "I want to keep my network clean." Both of you significantly benefiting from unprecedented transparency and finding value.
The question is, what do you consider fair?
What is the criteria for getting a /24 blocked? Or a larger block blocked. Or an ASN?
Everything else is fine so long as the criteria is actually fair and reasonable.
I think we are missing some buzzwords here: Blockchain
Why not host this RBL in a blockchain to ensure transparency and indisputably?
And NFT so spammers can actually profit from their spams
Involucrated coin?
To be honest I haven't defined it, but requesting that I do is fair. My process for escalating to blocking a whole network has usually been like this:
Day 1 I see a bunch of their IPs sending spam so I block them. Day 2 I see a bunch more IPs so I block them. Day 3 I see a bunch more IPs so I block them. Day 4 I say "Fuck this, I'm not playing wack-a-mole with them anymore."
Services like Mailgun, Mandrill, Sendinblue etc. need to have a much worse reputation than they do. This is where most of my spam comes from - newsletters I didn't really sign up for.
Any domains or IPs involved in "cold outreach" need to be blacklisted. I suspect you would have a bunch of seemingly legit websites with contact forms and some basic logic to differentiate between customers and cold outreach, that are essentially honeypots.
Instant (free) whitelisting after submiting form(s) which will verify that you are a human. If the IP appears again in the list within 7 days, then disable instant whitelisting for such IP and ban it for at least 7-14 days.
More than 50% of the ASN needs to be used for spamming to be listed, or the rate of spam must be more from single/multiple IPs than already existing banned ASNs to add this new ASN to blacklist.
ASN related blacklists should should have same rules but they should be more strict regarding re-occurance as that would usually mean that its coordinated spam.
If you ignore all of the above, the core idea is: Make sure that there are clear dates mentioned for any listing expiration. If you decide to ask for money for delisting, offer a clear free submit form with lower priority ticket queue. (The trick is to never really answer if you dont have time, cause it expires in 7 days anyway). The main thing is that, you need free options to appear legitmate whetever you process them or not.
Also, some kind of page where you can see the "proof" of spam for that specific IP with timestamp. For example, a message title and/or body which blacklisted the IP.
Verification could also include that you are required to host a http verification page on that IP or ping from that IP to ensure that you own it.
Also, I would really want to see AbuseIPDB blocklist. (They already offer it though, but its not quite realtime, and the logic is bad).
A big key is letting the end user/server renter delist their IP.
I hate sorbs cause we always have to login and the client cant to delist.
The first delisting should be instant, if they get relisted you should make them wait longer to delist.
I think that it'd be really neat if:
This is fair if you're manually checking and blocking. You're basically trying to reduce your labor. But I assume you will automate it at some point, and at that point you will need to define some set of rules to work against.
I suppose it would make sense to block various block sizes depending on the proportion of abusive IPs.
For example.
50% of a /29
30% of a /28
20% of a /27
15% of a /26
10% of a /25
5% of a /24
The key would be to list the smaller blocks. So if every IP in a /28 was spamming, it would not automatically block the parent /27 or /24. So it will also depend on distribution. I think it is fair that you be as targeted as possible to avoid collateral damage of the innocent.
And you could have a similar kind of rule at the ASN level. You can list the whole ASN if more than 10% of their subnets are listed. Something like that.
The ability for server administrators to see message headers so they can track down the culprit.
How do you identify server administrators and keep this information out of the hands of real spammers looking to circumvent your tactics? That's the million dollar question.
But understand - at least in shared hosting - server administrators don't really watch all outbound mail going out from their server. So if a client is sending out spam (whether it's willingly or through a password compromise - it really doesn't make any difference, it's still sending out spam) we need a way to track that spam back down to actual client on the server so we can punish the account.
Blindly allowing for delisting (assuming the listing was legitimate) doesn't help to solve the problem.
Server sends out spam -> server gets listed -> administrator requests delisting without making any changes to the server behavior -> Server sends out spam -> server gets listed ... See where I'm going here?
This is what I hate about a lot of RBLs and private "big company" blacklists. You simply write in or fill out a form that requests delisting. They don't ask if the problem has been solved. They don't provide any information about what caused the listing. We're just suppose to request delisting. That's not solving anything.
And I understand that providing that information to track down a spammer is a thin line. As the RBL's administrator you don't really know who you are are disclosing that information to and if they have the means or intentions to really solve the problem. At best, someone that requests this information should be able to prove that they have administrative privileges on the server - perhaps by string verification for http://%theipaddress%/%randomfilename.html% - but that's not necessarily going to prove the intention of the person requesting the delisting.
Good thoughts. That seems to be the question that drives a lot of RBL practices, driving them to keep things close to their chest. It's entirely possible that it's hubris leading me to believe that I can survive that kind of transparency by continually adapting to the changes in their behavior. At the end of the day these spammers can only function at scale by automating their behavior, and one only needs a decent sample size to quickly rebuild their algorithms. I propose that by keeping up with them on that, I can eventually run them out of steam (obviously they'll never really "run out" of steam but it might feel like that as some of them fail).
I've always thought that a major problem is one of comparison of effort. These abusive types often require minimal effort to project their damage across the internet, and everyone else requires an incredibly larger amount of effort to catch up to them. With MXroute as a tool for building sample data (with reasonable privacy protections, I'm mostly talking about behavior at the initial connection rather than sampling received emails) I believe that my effort to circumvent spammers has finally been reduced to a lower amount of required effort than is required by them to continue.
And if I can have my standards adopted at a larger scale, the amount of effort expended by them in response to equal or lower amounts of effort expended by me could begin to multiply on their side while staying the same for me. It could be the game changer if done right, or if I fail it could just be xkcd's "standards" comic
Don't block a whole network just because some (even most) of its IPs sending spam. If like you said, more and more of its IPs are sending spam, all of its IPs would all be listed in your RBL eventually. And you don't need to explain why your RBL lists an IP that has no history of sending spam.
If you saw some of these networks you'd agree it's appropriate. Entire ASNs prepped for spamming by their PTR records, hoping people won't block them all at once so they can get their money's worth.
It's not enough to customers to block spam after it happens, there has to be some proactive attacks against known spam operations as well.
I'd post one but it's been a couple days since l last ran into one and it's not fresh on my memory.
https://bgp.he.net/net/170.130.168.0/22#_dns
https://bgp.he.net/net/50.2.184.0/24#_dns
https://bgp.he.net/net/50.2.176.0/22#_dns
Yeah they don't get to claim they're not a spam operation anymore lol.
Here's another, only spam: https://bgp.he.net/AS16578#_prefixes
Halted so much proactively by blocking all of their ranges, not a single complaint.