Recent Posts

NY Times on unsubscribing by email

More than a decade ago I was included in one of these. It wasn’t work related per se, but the address list included a lot of experienced, BTDT, names-on-RFCs technology folks.
Yeah, even they got stuck in the mess of replying all, unsubscribing, lecturing people about not replying to all. It was a mess, but funny given the names involved. #neverdothis #noreplytoall

Abuse, triage and data sharing

The recent subscription bombs have started me thinking about how online organizations handle abuse, or don’t as the case may be. Deciding what to address is all about severity. More severe incidents are handled first. Triage is critical, there’s never really enough time or resources to investigate abuse.

What makes an event severe? The answer is more complicated that one might think. Some of the things that ISP folks look at while triaging incoming complaints include:

How many blocklists do we need?

There’s been a discussion on the mailop list about the number of different blocklists out there. There are discussions about whether we need so many lists, and how difficult the different lists make it to run a small mail system (80K or so users). This discussion wandered around a little bit, but started me thinking about how we got to a place where there are hundreds of different blocklists, and why we need them.

There is a lot of history of blocklists, and it’s long, complicated and involves many strong and passionate personalities. Some of that history is quite personal to me. Not only do I remember email before spam, I was one of MAPS’ first few employees, albeit not handling listings. I’ve talked with folks creating lists, I’ve argued with folks running lists. For a while I was the voice behind a blocklist’s phone number.
The need, desire and demand for different lists has come up over the years. The answer is pretty simple: there are many different types of abuse. One list cannot effectively address all abusive traffic nor have policies that minimize false positives.
Lists need different policies and different delisting criteria. The SBL lists based on volume of email to addresses that are known to have not opted in to receive mail. The PBL lists IPs where the IP owner (usually an ISP) says that the IPs are not supposed to be sending mail by their policy. URIBL and SURBL list domains, not IPs. Some lists have delisting requirements, some let listees remove themselves.
The policies of listing and delisting are not one size fits all, nor should they be.
There are two widely used lists that have significantly different delisting policies: the SBL and the CBL.
The SBL focuses on IP addresses they believe are under the control of or supporting the services of spammers. They measure this by primarily relying on spamtraps, but they also accept forwarded mail from some trusted individuals. Getting delisted from the SBL means explaining to Spamhaus what steps were taken to stop the spam from coming. It’s a manual process with humans in the loop and can require significant business process changes for listees. (We’ve helped dozens of companies resolve SBL listings over the years, contact us if you need help.)
On the other hand, the CBL is a mostly automated list. It lists ources of mail that aren’t real mail servers sending real mail, but are sending a lot of stuff. As they describe it:

Traffic Light Protocol

If you’re sharing sensitive computer security information it’s important to know how sensitive a document is, and who you can share it with.
US-CERT and many other security organizations use Traffic Light Protocol as shorthand for how sensitive the information in a document is. It’s simple and easy to remember with just four colour categories: Red, Amber, Green and White. If you’re likely to come into contact with sensitive infosec data, or you just want to understand the severity of current leaks, it’s good to know that it exists.

Ask Laura: Is it spam?

Google takes on intrusive interstitials

Starting next January, Google will be modifying its mobile search results to lower the ranking of sites that use interstitials that interfere with the users experience. In a blog post announcing the change they explain:

Open subscription forms going away?

A few weeks ago, I got a call from a potential client. He was all angry and yelling because his ESP had kicked him off for spamming. “Only one person complained!! Do you know him? His name is Name. And I have signup data for him! He opted in! How can they kick me off for one complaint where I have opt-in data? Now they’re talking Spamhaus listings, Spamhaus can’t list me! I have opt-in data and IP addresses and everything.”
We talked briefly but decided that my involvement in this was not beneficial to either party. Not only do I know the complainant personally, I’ve also consulted with the ESP in question specifically to help them sort out their Spamhaus listings. I also know that if you run an open subscription form you are at risk for being a conduit for abuse.
This abuse is generally low level. A person might sign up someone else’s address in an effort to harass them. This is a problem for the victim, but doesn’t often result in any consequences for the sender. Last week’s SBL listings were a response to subscription abuse happening on a large scale.

Gmail showing authentication results to endusers

A bit of older news, but worth a blog post. Early in August, Gmail announced changes to the inbox on both the web interface and the android client. They will be pushing authentication results into the interface, so end users can see which emails are authenticated.

These are not deliverability changes, the presence or absence of authentication will not affect inbox delivery. And the gmail Gmail support pages clarify that lack of authentication is not a sign that mail is spam.
This isn’t a huge change for most ESPs and most senders. In fact, Gmail has reported more than 95% of their mail is authenticated with either SPF or DKIM. Now, Gmail does a “best guess” SPF – if it looks like an IP should be authorized to send mail for a domain (like the sending IP is the same as the MX) then it’s considered authenticated.
It’s good to see authentication information being passed to the end user.

Ongoing subscription attack

Brian Krebs posted a couple days ago about his experience with the subscription bomb over the weekend. He talks about just how bad it was over the weekend.

Spamhaus comments on subscription attack

Steve Linford, CEO of Spamhaus commented on my blog post about the current listings. I’m promoting it here as there is valuable information in it.