August 2014: The Month in Email

Isn’t August the month where things are supposed to slow down? We’re still waiting for that to happen around here… it’s been great to be busy, but we’re hoping to continue to carve out more time for blogging as we move into the fall.
August
As usual, we reported on a mix of industry trends and news, the persistence of spam, and did a deep dive into an interesting technical topic. Let’s start there: Steve wrote a post explaining Asynchronous Bounces (yes, it’s a GNFAB), with some examples of how they’re used and how they can cause operational problems.
In industry news, we did a roundup post of some Gmail changes and a followup post on security issues with non-Latin characters in addresses. We also celebrated the long-awaited release of a wonderful resource from MAAWG that I am very proud to have helped author, the white paper Help! I’m on a Blocklist! (PDF link). We receive dozens of these calls every week, and though we are always happy to help people solve urgent delivery crises, we spend most of our consulting time and attention working with people to build sustainable email programs, so this document is a great “self-service” resource for people looking to troubleshoot blocklist issues on their own.
In other industry and MAAWG-related news, we noted that the nomination period for the J.D. Falk award has opened (you have just a few more days, procrastinators) and took a moment to reminisce about our friend J.D. and his incredible contributions to the field.
On the topic of creating, sending, and reading more attractive email, we posted some  resources from Mailchimp and crowdsourcing templates from Send With Us. We also incorrectly reported on a not-actually-new interface from AOL, Alto. Interesting to note that there’s been so little followup from AOL (and almost no post-launch coverage) in the two years since launch.
We also touched on a few myths: email saves trees and low complaint volume is good.
And finally, in November of 2013, I unsubscribed from every possible email I received on a specific account. I followed up on that briefly in a Part 2 post, and this month went back and wrote a Part 3 followup. Spoiler alert: spam is still a problem. Of course, we got some comments that we were probably doing it wrong, so Unsubscribe Barbie showed up to add her thoughts. We try not to be snarky around here, but sometimes we just don’t try very hard.

The origins of network email
Changing your email address

Related Posts

Who pays for spam?

A couple weeks ago, I published a blog post about monetizing the complaint stream. The premise was that ESPs could offer lower base rates for sending if the customer agreed to pay per complaint. The idea came to me while talking with a deliverability expert at a major ESP. One of their potential customer wanted the ESP to allow them to mail purchased lists. The customer even offered to indemnify the ESP and assume all legal risk for mailing purchased lists.
While on the surface this may seem like a generous offer, there aren’t many legal liabilities associated with sending email. Follow a few basic rules that most of us learn in Kindergarten (say your name, stop poking when asked, don’t lie) and there’s no chance you’ll be legally liable for your actions.
Legal liability is not really the concern for most ESPs. The bigger issues for ESPs including overall sending reputation and cost associated with resolving a block. The idea behind monetizing the complaint stream was making the customer bear some of the risk for bad sends. ESP customers do a lot of bad things, up to and including spamming, without having any financial consequences for the behavior. By sharing  in the non-legal consequences of spamming, the customer may feel some of the effect of their bad decisions.
Right now, ESPs really protect customers from consequences. The ESP pays for the compliance team. The ESP handles negotiations with ISPs and filtering companies. The cost of this is partially built into the sending pricing, but if there is a big problem, the ESP ends up shouldering the bulk of the resolution costs. In some cases, the ESP even loses revenue as they disconnect the sender.
ESPs hide the cost of bad decisions from customers and do not incentivize customers to make good decisions. Maybe if they started making customers shoulder some of the financial liability for spamming there’d be less spamming.

Read More

June 2014: The month in email

Each month, we like to focus on a core email feature or function and present an overview for people looking to learn more. This month, we addressed authentication with SPF.
We also talked about feedback mechanisms, and the importance for senders to participate in FBL processes.
In our ongoing discussions about spam filters, we took a look at the state of our own inboxes and lamented the challenge spam we get from Spamarrest. We also pointed out a post from Cloudmark where they reiterate much of what we’ve been saying about filters: there’s no secret sauce, just a continuing series of efforts to make sure recipients get only the mail they want and expect to receive. We also looked at a grey area in the realm of wanted and expected mail: role accounts (such as “marketing@companyname.com”) and how ESPs handle them.
As always, getting into the Gmail inbox is a big priority for our clients and other senders. We talked a bit about this here, and a bit more about the ever-changing world of filters here.
On the subject of list management, we wrote about the state of affiliate mailers and the heightened delivery challenges they face getting in the inbox. We got our usual quota of spam, and a call from a marketer who had purchased our names on a list. You can imagine how effective that was for them.
And in a not-at-all-surprising development, spammers have started to employ DMARC workarounds. We highlighted some of the Yahoo-specific issues in a post that raises more questions.
We also saw some things we quite liked in June. In the Best Practices Hall of Fame, we gave props to this privacy policy change notification and to our bank’s ATM receipts.
We also reviewed some interesting new and updated technology in the commercial MTA space, and were happy to share those findings.

Read More

Best practices: A Gmail Perspective

At M3AAWG 30 in San Francisco, Gmail representatives presented a session about best practices and what they wanted to see from senders.
I came out of the session with a few takeaways.

Read More