Blocklist changes

Late last year we wrote about the many problems with SORBS. One of the results of that series of posts was a discussion between a lot of industry professionals and GFI executives. A number of problems were identified with SORBS, some that we didn’t mention on the blog. There was an open and free discussion about solutions.
A few months ago, there were a bunch of rumors that GFI had divested themselves from SORBS. There were also rumors that SORBS was purchased by Proofpoint. Based on publicly available information many of us suspected that GFI was no longer involved in SORBS. Yet other information suggested that Proofpoint may truly have been the purchaser.
This week those rumors were confirmed.

Proofpoint, Inc., the leading provider of cloud-based security and compliance solutions for enterprise messaging and collaboration, today announced it has acquired the assets of the SORBS (Spam and Open Relay Blocking System) service (http://www.sorbs.net). Approximately 200,000 organizations worldwide leverage the SORBS DNS-based Block List (DNSBL) to effectively block email from more than 12 million host servers known to disseminate spam, phishing attacks and other forms of malicious email.

I have to wonder how reflective of actual usage numbers the “200,000 organizations” is. I do suspect that many organizations are querying the list, but I don’t know how much it’s affecting delivery. Most spamassassin installations query SORBS DUL by default. However, being listed on SORBS DUL only counts for 0.001 points. Being queried doesn’t matter if those queries don’t really affect delivery.
We recently wrote about problems with the Trend/MAPS lists. Many people have contacted us about that and indicated they are no longer seeing any blocking at Comcast based on a MAPS listing. The Comcast postmaster page hasn’t been updated, but I haven’t heard of anyone having problems with listings at Comcast recently.
I’m hearing conflicting reports about the other major US Trend/MAPS user, RR.com. Some people are telling me they’re seeing inbox delivery for MAPS listed IPs. Other people are telling me they’re seeing deferrals for MAPS listed IPs.
In either case, it appears that the effect of a MAPS listing on delivering mail to US ISPs is less than it was a few months ago.
The decisions to make this information public  were not made lightly. On balance, blocklists are a valuable and important part of the email ecosystem. But they are a bit of a black box. Very few people who don’t run blocklists actually have insight into how they work and how they make decisions. There are good reasons the blocklists do this, but it does make them a bit of an unknown entity to many.
In response to the ongoing damage to the email ecosystem, we decided share this information publicly. Many people tried discussions with the list maintainers and their parent companies: by phone, by email and in person. These efforts were only partially effective at getting wanted mail delivered.
Because this problem was ongoing and because so many different people were attempting to resolve the problem unsuccessfully, we decided to make the information we knew public. While the listing policies don’t seem to have changed, the overall damage to the ecosystem seems to be lessening.
There are a lot of people who worked very hard to bring about these changes. Many of them cannot be named, for obvious reasons. But their contribution should not be overlooked. Our position in the industry means people share issues with us and that we can share information publicly. But just because we’re the public face doesn’t mean we’re the only actors.

Related Posts

A Disturbing Trend

Over the last year or so we’ve been hearing some concerns about some of the blacklisting policies and decisions at Trend Micro / MAPS.
One common thread is that the ESP customers being listed aren’t the sort of sender who you’d expect to be a significant source of abuse. Real companies, gathering addresses from signup forms on their website. Not spammers who buy lists, or who harvest addresses, or who are generating high levels of complaints – rather legitimate senders who are, at worst, being a bit sloppy with their data management. When Trend blacklist an IP address due to a spamtrap hit from one of these customers the actions they are demanding before delisting seem out of proportion to the actual level of abuse seen – often requiring that the ESP terminate the customer or have the customer reconfirm the entire list.
“Reconfirming” means sending an opt-in challenge to every existing subscriber, and dropping any subscriber who doesn’t click on the confirmation link. It’s a very blunt tool. It will annoy the existing recipients and will usually lead to a lot of otherwise happy, engaged subscribers being removed from the mailing list. While reconfirmation can be a useful tool in cleaning up senders who have serious data integrity problems, it’s an overreaction in the case of a sender who doesn’t have any serious problems. “Proportionate punishment” issues aside, it often won’t do anything to improve the state of the email ecosystem. Rather than staying with their current ESP and doing some data hygiene work to fix their real problems, if any, they’re more likely to just move elsewhere. The ESP loses a customer, the sender keeps sending the same email.
If this were all that was going on, it would just mean that the MAPS blacklists are likely to block mail from senders who are sending mostly wanted email.
It’s worse than that, though.
The other thread is that we’re being told that Trend/MAPS are blocking IP addresses that only send confirmed, closed-loop opt-in email, due to spamtrap hits – and they’re not doing so accidentally, as they’re not removing those listings when told that those addresses only emit COI email. That’s something it’s hard to believe a serious blacklist would do, so we decided to dig down and look at what’s going on.
Trend/MAPS have registered upwards of 5,000 domains for use as spamtraps. Some of them are the sort of “fake” domain that people enter into a web form when they want a fake email address (“fakeaddressforyourlist.com”, “nonofyourbussiness.com”, “noneatall.com”). Some of them are the sort of domains that people will accidentally typo when entering an email address (“netvigattor.com”, “lettterbox.com”, “ahoo.es”). Some of them look like they were created automatically by flaky software or were taken from people obfuscating their email addresses to avoid spam (“notmenetvigator.com”, “nofuckinspamhotmail.com”, “nospamsprintnet.com”). And some are real domains that were used for real websites and email in the past, then acquired by Trend/MAPS (“networkembroidery.com”, “omeganetworking.com”, “sheratonforms.com”). And some are just inscrutable (“5b727e6575b89c827e8c9756076e9163.com” – it’s probably an MD5 hash of something, and is exactly the sort of domain you’d use when you wanted to be able to prove ownership after the fact, by knowing what it’s an MD5 hash of).
Some of these are good traps for detecting mail sent to old lists, but many of them (typos, fake addresses) are good traps for detecting mail sent to email addresses entered into web forms – in other words, for the sort of mail typically sent by opt-in mailers.
How are they listing sources of pure COI email, though? That’s simple – Trend/MAPS are taking email sent to the trap domains they own, then they’re clicking on the confirmation links in the email.
Yes. Really.
So if someone typos their email address in your signup form (“steve@netvigattor.com” instead of “steve@netvigator.com”) you’ll send a confirmation email to that address. Trend/MAPS will get that misdirected email, and may click on the confirmation link, and then you’ll “know” that it’s a legitimate, confirmed signup – because Trend/MAPS did confirm they wanted the email. Then at some later date, you’ll end up being blacklisted for sending that 100% COI email to a “MAPS spamtrap”. Then Trend/MAPS require you to reconfirm your entire list to get removed from their blacklist – despite the fact that it’s already COI email, and risking that Trend/MAPS may click on the confirmation links in that reconfirmation run, and blacklist you again based on the same “spamtrap hit” in the future.

Read More

GFI/SORBS considered harmful, part 3

Act 1 • Act 2 • Intermezzo • Act 3 • Act 4 • Act 5
Management Summary, Redistributable Documents and Links
In the last few days we’ve talked about GFI’s lack of responsiveness, the poor quality of their reputation and blacklist data, and the interesting details of their DDoS claims. Today we’re going to look at (some of) the fundamental problems with GFI’s procedures and infrastructure that cause those issues. Some of the subset of issues I’ve chosen highlight are minor, some are major, but they show a pattern of poor decisions.
SSL Certificates
When you use SSL on a web connection it brings you two benefits. The first is that it encrypts the connection between your browser and the webserver, so that it’s very difficult for anyone to watch or tamper with your interaction with that webserver. The second, more important, reason is to make sure that you’re talking to the webserver you think you’re talking to, to avoid man-in-the-middle attacks.
This security relies on you trusting the certification authority that issues the SSL certificate that the website uses. A website providing services to the public should always use an SSL certificate created by one of a small number of reputable certification authorities that are pre-loaded into all webservers as “trusted”. These SSL certificates are something that need to be be purchased, but they’re very inexpensive – less than ten dollars a year.

Read More

GFI/SORBS considered harmful, part 2

Act 1 • Act 2 • Intermezzo • Act 3 • Act 4 • Act 5
Management Summary, Redistributable Documents and Links
Yesterday I talked about GFI responsiveness to queries and delisting requests about SORBS listings. Today I’m going to look at data accuracy.
The two issues are tightly intertwined – a blacklist that isn’t responsive to reports of false positive listings will end up with a lot of stale or inaccurate data, and a blacklist that has many false positives will likely be overwhelmed with complaints and delisting requests, and won’t be able to respond to them – leading to a spiral of dissatisfaction and inaccurate data feeding off each other.

Read More