In the never ending battle against spam, the resultant eco-system has generated some really interesting dynamics. Often times, organizations working in synergy to try and address and resolve spamming issues, and most importantly, keep legitimate email flowing to users, get caught in tug and war battles. Often times, this is nothing more then newer players coming into a space they know little about and attempt to make their mark by flexing some muscle – when all that is actually required is a little common sense and an ability to work with each other. This is what is happening right now with SpamRats. SpamRats is a newer RBL provider on the scene, and have many of us shaking our respective heads with how they are choosing to operate. Personally, we do not hold any ill will. We understand they are trying to solve a problem and they have their own philosophies behind their approach. Unfortunately however for SpamRats, they are forgetting the primary principle and their primary purpose – which is to protect legitimate email for legitimate users. The Scenario
- We utilize MXtoolbox to monitor any IPs within our network used to send email. This includes our SMTP spamfilter appliance farm and its entire SMTP pool of IPs, and all email servers routing email through these appliances (if these email servers get listed, its an indication of an issue, meaning our filters are somehow being bipassed)
- One of our Exchange CAS servers in our cloud got listed with SpamRats (even though this IP does not send a single piece of email out to the internet directly and rather routes all email through our SMTP spam filtering appliances)
- We thought there was a serious issue but upon investigation, discovered that SpamRats simply chose to RBL this IP as it was part of a Class C where one IaaS VM customer signed up by a reseller was a spammer. The spammer was swiftly removed and the IP RBL listing was removed from every major RBL provider (spamcop, spamhaus, etc) within minutes to ensure the next customer using this IP for email would not have an issue
What Happened Next?
- So, we decided to be friendly internet people, contact SpamRats, explain the situation, explain we want to work with them and to ask them to remove the listing for the Class C as these IPs are assigned dynamically to new customers (thread quoted below)
Pest Control OfficerTo:From: Pest Control OfficerHello Only email servers need to be unlisted, been this list wont affect your network.– Pest Control Officer –Andrew RouchotasTo: Pest Control OfficerFrom: “Cartika Support”Reply-to: [email protected]Hello and thank you for your reply, but, can you further elaborate? we are a service provider. every IP address in that class C you blacklisted will be deployed on future VMs deployed on our IaaS platform many of which, and we dont know which ones yes as they dont exist yet, will be legitimate email users its simply not reasonable for them to be blacklisted like this I am anxious to work with you folks – and I URGE you to RBL any IPs that require a listing until an issue is resolved (of which we are very proactive and you will notice very few of our IPs are on ANY RBL ANYWHERE) we simply cannot have someone blacklist an entire class c – and then have to engage you IP by IP as new VMs are deployed on our platform. customers simply will not tolerate this – and to be fair, its not a very reasonable approach on your end either if you need anything from us to facilitate this process, let us know – but, I must ask that you remove the blacklisting for one of our class c’s – its just not a reasonable approach to an issue we are all working together to address please advise at your soonest thanks AndrewPest Control OfficerTo:From: Pest Control OfficerHello,We require individual IP of Mail Servers, we are not able to remove entire network blocks; please respond with the appropriate IPs and we will address this.Thanks,–Pest Control Officer–
The majority of established RBL providers (think Spamcop, Spamhaus, etc), although never perfect, are usually very reasonable organizations to deal with. We absolutely respect the jobs they do and the services they offer. Whether they are blacklisting IPs belonging to other organizations, or our own, does not matter. A listing from one of these RBL providers typically means there is an issue which needs addressing and resolving. This could be a user with a compromised PC and compromised email credentials being used for spamming activity, a compromised script resulting in spamming activity, or even a new customer signup (direct or via a reseller) who turned out to be a spammer that needs to be addressed. On the whole, established, legitimate RBL providers offer an invaluable service. They let us all know when there is a problem which needs addressing, and we have a clear and absolute path to resolve the issue as described and then remove the respective IP from any blacklist once the issue has been shown to be resolved. This process above is critically important to the primary objective here – which again, is to protect legitimate email for legitimate users. When RBL providers try and operate outside of such established and well understood protocol, they simply forget their entire purpose and reason for being. They no longer care about the integrity of legitimate email for legitimate users, and rather, move into the realm of creating their own rules for their own reasons, while inconveniencing and negatively impacting users who rely on them to provide a specific service. This is what is happening with SpamRats right now. They have stuck a stake in the ground, and the consequences will be significant, especially from service providers. SpamRats is opting to blacklist entire class C or higher ranges of IPs in scenarios where none of these IPs were involved in any spamming activity, except for 1 or 2 IPs for a brief period of time. This alone is actually not an issue. Many RBL providers will blacklist an entire range of IPs if they see a significant enough issue warranting it. Makes absolute sense! SpamRats however are then refusing to delist any IPs unless they are shown to be legitimate email servers. What this means, is any new mail service launched on that set of IPs will be automatically listed and will require a manual delisting request. What has already happened is customers using those IPs, having issues delivering to various ISPs who do use SpamRats as an RBL source, are simply requesting the ISP to stop using SpamRats. I imagine over time, SpamRats will change this policy, but, for now, they have stubbornly dug in their heels and chose to battle providers like us, vs working with us to find an amicable solution. Its difficult to justify having IPs blacklisted which do not even send any email, and may never send email. Its also difficult to justify not being able to release an IP from an RBL when there was an issue, which was resolved and resulted in the delisting at every other significant and reliable RBL provider. If an IP cannot be reliably delisted when its proven to no longer be a spam source, then the effectiveness of the RBL provider issuing the listing is absolutely useless – as again, they are not protecting the legitimate flow of legitimate email from legitimate users. As such, its impossible to trust this RBL provider to properly handle email and ensure the delivery and sanctity of legitimate email for legitimate users. Until such time that SpamRats gains an understanding of how IPs are assigned and used on the internet, and how their actions are penalizing the very same people they are trying to protect, our formal stance with SpamRats is we will work on a best effort basis with them to ensure any new IPs launched as mail servers are removed from their RBL. However, they are so erratic in their approach, that we simply do not know when or if they will act rationally. As such, we encourage any users with any delivery issues using the SpamRats RBL, with us or any other service provider, to contact the recipient email server administrator, make them aware of these policies and ask them to use more trusted RBL providers to determine the legitimacy of email. SpamCop or SpamHaus as an example are reliable RBL providers and protect legitimate email. SpamRats should not be used as a hard failure RBL listing until such time as SpamRats learns how to operate properly.