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

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

Are blocklists always a good decision?

One of the common statements about blocklists is that if they have bad data then no one will use them. This type of optimism is admirable. But sadly, there are folks who make some rather questionable decisions about blocking mail.
We publish a list called nofalsenegatives. This list has no website, no description of what it does, nothing. But the list does what it says it does: if you use nofalsenegatives against your incoming mailstream then you will never have to deal with a false negative.
Yes. It lists every IP on the internet.
The list was set up to illustrate a point during some discussion many years ago. Some of the people who were part of that discussion liked the point so much that they continued to mention the list. Usually it happens when someone on a mailing list complained about how their current spamfiltering wasn’t working.
Some of the folks who were complaining about poor filtering, including ones who should know better, did actually install nofalsenegatives in front of their mailserver. And, thus, they blocked every piece of mail sent to them.
To be fair, usually they noticed a problem within a couple hours and stopped using the list.
This has happened often enough that it convinced me that not everyone makes informed decisions about blocking. Sure, these were usually small mailservers, with maybe a double handful of users. But these sysadmins just installed a blocklist, with no online presence except a DNS entry, without asking questions about what it does, how it works or what it lists.
Not everyone makes sensible decisions about blocking mail. Our experience with people using nofalsenegatives is just one, very obvious, data point.

Read More

The sledgehammer of confirmed opt-in

We focused Monday on Trend/MAPS blocking fully confirmed opt-in (COI) mail, because that is the Gold Standard for opt-in. It is also Trend/MAPS stated policy that all mail should be COI. There are some problems with this approach. The biggest is that Trend/MAPS is confirming some of the email they receive and then listing COI senders.
The other problem is that typos happen by real people signing up for mail they want. Because MAPS is using typo domains to drive listings, they’re going to see a lot of mail from companies that are doing single opt-in. I realize that there are problems with single opt-in mail, but the problems depends on a lot of factors. Not all single opt-in lists are full of traps and spam and bad data.
In fact, one ESP has a customer with a list of more than 50 million single opt-in email addresses. This sender mails extremely heavily, and yet sees little to no blocking by public or private blocklists.
Trend/MAPS policy is singling out senders that are sending mail people signed up to receive. We know for sure that hard core spammers spend a lot of time and money to identify spamtraps. The typo traps that Trend/MAPS use are pretty easy to find and I have no doubt that the real, problematic spammers are pulling traps out of their lists. Legitimate senders, particularly the ESPs, aren’t going to do that. As one ESP rep commented on yesterday’s post:

Read More