I, for one, am tired of blacklists being run by people with a god complex. They’re obviously useful and desirable, and they’re not going away. Most recently I discovered the depths of the worst of the worst: A company that sells spam filtering software, seems to have a preference for listing small companies that don’t purchase their software in their in-house blacklist, and refuses to remove them. A good old fashioned shakedown. But enough about MagicSpam and MIPSPACE (the RBL they say they don’t control and yet run in-house).
One thing MXroute has become is a collection of the rest of us, making us all a force to be reckoned with. While others want to try to gatekeep the email protocol and covertly attack their competitors by making it hard to get emails delivered everywhere without purchasing from one of the big names, we’ve all been rising up as a bunch of web designers, hosting providers, and sysadmins and using the brand as our sledgehammer to the market.
It only makes sense that we should continue to work on taking power away from some of these gatekeepers by being better than they are at what they do. I submit that we have better data anyway.
We’ll be eating our own dogfood and using MXRBL as the exclusive RBL of MXroute, giving our customers the first place in line to influence it. If you’d like to use it on your servers, just add “bl.mxrbl.com” to your RBL list
For now just an email link for removal request, and just me adding them from MXroute data. I’d like to put up a queue system that people can submit to and I can review for addition/removal. Nothing too difficult, just next steps
Ah, MagicSpam. Told them to talk a long walk off a short pier when approached last year. Glad to see my gut didn’t belie me
Consider adding a drop-in ruleset for rspamd. SpamHaus has a DQS service that provides similarly scoped features. Also, since you run a network of trusted MTA relays, wouldn’t hurt to filter problematic SMTP connections or leveraging something like Postscreen and feeding those bots to the list, adding a new classification such as known spammer, known brute-force, or known irregular client to let users apply arbitrary weights to these classifications.
It’s a good start with a unique network that can set it apart from other RBLs. I’ll tie it back into ApisCP once it stabilizes.
Great initiative, although if I might add a few suggestions:
the 127.0.0.1 should not be used, as it’s the return code that should never be returned as a way of checking whether or not the RBL is functioning properly
the 127.0.0.2 is the default ‘blacklisted’ return code, and should always be returned if the IP is blacklisted
if you wish to have degrees of ‘blacklisting’ (ie: minor offender, strong offender, career spammer) then I’d suggest having different RBLs for each of these as opposed to having them all in one RBL with different return codes. You could have for instance: grey.mxrbl.com, red.mxrbl.com, and red.mxrbl.com. This would be ideal as not all anti-spam or RBL filtering systems allow the users to select return codes as the “degree of filter”, so this way it’d be easier for users to select what they’d like to block.
I’m becoming convinced that most of the others were made for evil purposes. Mine might be interpreted as evil but only so far as to try to reduce their impact.
To kill a king and take his sword may look like the same action taken by the last king, but if the intent is to take the sword and destroy it, returning control to the people, that’s a cause I can get behind