What changed?

How come my list of third-party opt-ins from two years ago is now having problems, the question goes. What changed? I'm still doing everything right.

I'm getting that question a lot lately, and a colleague suggested that I post my answer here, to share it with readers.

So, what happened? Why are you getting blocked today, based on utilization of a practice that was considered perfectly acceptable a few years ago?

Keep in mind that ISPs never were really all that keen on allowing in third-party opt-in mail to begin with. Going back for years, if you ever ran into deliverability issues requiring ISP involvement to resolve the issue, they would regularly decline to assist when confronted with an obvious case of mail being sent to third-party lists. But, unless it was obvious, blatant, they didn't always notice. Ultimately, quite a few marketers were able to successfully send third-party advertising emails, keeping complaints low enough to stay under the radar.

But, things have changed since then. Recently, various ISPs have gotten much better at blocking that kind of mail. A whole bunch of squiffy senders who ride the line of permission so close suddenly found their ability to deliver mail take a sharp turn for the worse back in November or December.

Why? Because the ISPs just got smarter. Yahoo, in particular, became much better at figuring out who the co-reg/third-party guys are. Now that they are more easily identified, Yahoo is able to more easily apply policy decisions to this mail. The net is, Yahoo, and other ISPs have clamped down.

Based on that alone, senders are learning that what was OK a few years ago is no longer OK.

Also, keep in mind that an email address isn't forever. The days of just mailing somebody forever until they unsubscribe are gone. Hate it or not, ISPs are looking at engagement rates to identify good vs bad list senders.

What does this mean? ISPs can tell which emails are rarely interacted with, which lists are mostly dormant. If you're sending to a lot of people who never open or click any emails, if you're sending emails that get very few opens or clicks, you're ending up on the low end of the reputation measuring stick, as measured by these engagement-related metrics. The solution is to implement subscriber life-cycle management strategy -- figure out what to do with dormant addresses. (Short answer: stop sending to them.)

"This was a valid opt-in two years ago" is as useless a statement as "my email is CAN-SPAM compliant." They're both true statements, but they no longer have any relevance as it relates to your sending reputation or your ability to get your mail delivered to the inbox.

Permission and deliverability are moving targets. ISPs are constantly stack ranking senders and blocking the ones on the bottom. Eventually, if your practices don't improve over time, and keep up with the times, you're going to eventually find yourself at the bottom of that stack ranking.

Score one for the Good Guys

The Composite Blocking List, a very popular anti-spam blacklist, reports that the Rustock botnet seems to have been disabled. Spam levels have plummeted as a result. Likely not forever, but it's still nice to see the bad guys struggling. Security journalist Brian Krebs covers it in more detail over on his site.

On the Legality of Spam Filtering

But my email fully complies with CAN-SPAM, the argument goes. How can ISPs be allowed to block my mail? I comply!

Here's how. Read section 8C of the CAN-SPAM law. It says:

NO EFFECT ON POLICIES OF PROVIDERS OF INTERNET ACCESS SERVICE-- Nothing in this Act shall be construed to have any effect on the lawfulness or unlawfulness, under any other provision of law, of the adoption, implementation, or enforcement by a provider of Internet access service of a policy of declining to transmit, route, relay, handle, or store certain types of electronic mail messages. 

Seems pretty straightforward, no?

No false-starts, do-overs, or mulligans for Email

Guest post by Neil Schwartzman. Reposted from the Word to the Wise blog with the permission of the author and publisher.

Josh Baer, former VP of Datran Media and current CEO of OtherInBox.com has been floating an idea at the DMA’s Email Experience Council and a few other places, and recently got some traction in Ken Magill’s Magill Report.

What Josh is proposing is to create the technical means by which a Sender can decide when email ‘expires’ and is automatically removed from a recipient’s inbox, either by deletion, or perhaps archiving (in the case of Gmail). This would supposedly help the end-user, by removing marketing offers that are no longer available.

Why this Idea Shouldn’t Happen

Email users’ rights trump everything. We get to decide what comes into our inbox, and what doesn’t. Just as fundamentally, we get to decide what is removed from the inbox, too. I no more want a marketer to decide for me to remove email they have sent, than I do deciding to add me to their list without permission.

Adding the ‘expires’ header, and having an email provider complicity remove an email from my inbox borders on 1984-like creepy. I want to know what has been sent to me, and not have Big Brother, or Big Business, remove stuff they decide is no longer relevant. Perhaps my goal in life is to create a complete archive of every Groupon offer ever sent to me – this would put an end to my dreams.

Beyond users’ rights, this scheme will confound receiving systems’ and reputation systems’ ability to determine the complaint rate of a given email campaign, which will be quite dynamic under this plan.

Email providers use complaint rates (and bounces, and myriad other data-points) during a campaign to determine if they should continue accepting email (some campaigns can take hours to complete their run, depending upon the size). If I send 10,000,000 emails over the course of a couple of hours, and set half of them to expire in say, 3 hours, the receiving system sees leading-edge complaints are taken with a number eventually reaching 10MM as the denominator, and so the actual complaint percentage may be kept artificially small, at the end of the day.

Why This Idea (Probably) Won’t Happen

Some folks are dismissing this out-of-hand, saying it would “never” get traction at any of the big receivers, like Hotmail, Gmail, and Yahoo! But I’m not entirely sold on that argument. It seems to me that when marketing, sales and a receiver come into close contact, it would be natural to treat a source of revenue with kid gloves, and as receiver revenues ebb, there may be a temptation to consider an idea such as this one with more gravitas than it merits. One need only look at Goodmail’s long-term attempts at revenue sharing with Receivers like AOL, Yahoo! And Comcast (apparently the revenue was never more than a trickle, if anything) to realize not everything is always rosy in that regard. Marketers may hold disproportionate sway in an uncertain email provider economy.

That aside, this is asking a lot of the email providers in terms of infrastructure change on behalf of a small slice of the area of their concern. Marketing email accounts for a reported 10% of the legitimate email load (in other words, everything a typical user gets that isn’t spam, rejected at the router, or by other filtering means).

As an official of a very large American ISP said to a group of marketers at a conference some years ago, “On my list of 10 things to do today, you are number 11”.

There would have to be a compelling groundswell of user desire and need for this idea to be considered, and I don’t see that happening, particularly at this point in time. There is a very large technical need to implement domain—based reputation systems looming, and the deployment of DKIM on inbound and outbound email is a pressing concern for both Senders and email providers. Their technical docket is very full, and will be for the foreseeable future as IPv6 deployment, the replacement for depleted IPv4 IP addresses pushes this agenda ever-higher.

Expiring email is a distraction that benefits only a few people in the community, and offers a tempting manner to game reputation systems and complaint rates. And, it ignores the right of end-users to determine what shows up, and stays, in our inboxes.

Spamhaus & URL Shortening Services

On March 5th, Spamhaus announced a change to its DBL (Domain Block List). They're now breaking out a separate category of listings specific to spamvertized URL redirectors that appear in spam. Meaning, if URL redirectors like bit.ly show up in a lot of spam, they're likely to be listed in this new zone and are likely to be blocked by users of the Spamhaus DBL.

Spamhaus provides a mechanism by which ISPs and filterers can choose whether or not to block based on these listings -- there's a separate result code specific to this type of listing. If your spam filter allows it, you can customize your settings to block or not block based on this type of listing.

This new functionality from Spamhaus is rather a big deal, in my estimation. What they're doing is putting redirect services on notice that the days of blacklists avoiding listings of these services to prevent false positives are over; if your redirect domain shows up in spam, you have a problem that you need to address, and your domain is likely to get blacklisted if that problem persists.

By offering that separate result code, Spamhaus is effectively allowing filterers and ISPs to decide whether or not to respect these listings (block based on these listings). The choice is left to the ISP or filterer, but I am pretty sure that ISPs *will* indeed block based on these listings -- causing new, significant pain for redirect services who have ongoing spam issues.

I wouldn't want to be in bit.ly's shoes right now, but as somebody who receives over 750,000 spam emails every month, I applaud these efforts by Spamhaus to help address the ever-growing problem of spammers utilizing these redirectors to try to get around blacklistings. Redirect services need to put measures in place to prevent malicious misuse of their services -- and not few do that today. A site like a bit.ly needs to check and ensure that a URL doesn't land on a bad, blacklisted domain -- or else it risks finding itself blacklisted as a result.

Comcast’s Impressive System for Notifying Infected Users

Return Path's J.D. Falk reports on Comcast's efforts to let customers know when their home computers are infected: Pushing infectees into walled garden, redirecting them to a page warning them that their network connection is infected.

J.D. Writes: "As one of the world’s largest access providers, our partner Comcast has put a ton of thought into developing a notification system for their users. Their motivation is clear, and close to the heart of anyone working in security for end user systems: 'to advise the user that their computer is infected with malware, that their security is at severe risk and/or has already been compromised, and that it is recommended that they take immediate, corrective action NOW.'"

J.D. also touches on the concern over network neutrality, and the potential concern over this type of monitoring being considered at odds with network neutrality. I'm an advocate for network neutrality, for sure. But I am also an advocate for locking down and securing computers that are spewing infections and spam. I, personally, think this is the right thing to do, and I don't think that this process is incompatible with the broader goals of network neutrality. What do you think?