Recent Posts

Responsive design just got easier at Gmail

Today Gmail announced they are supporting media queries in Gmail and Google Inbox. This should simplify the creation of emails for multiple platforms. The full list of supported rules can be found on the Google Developer Site.

Microsoft deprecating SmartScreen filters

At the beginning of the month Microsoft announced that they were deprecating the SmartScreen filters used by the desktop Microsoft mail clients. These are the filters used in Exchange and various version of Outlook mail. This is yet further consolidation of spam filtering between the Microsoft free webmail domains, Office365 hosted domains and self hosted Exchange servers. The online services (hotmail.com, outlook.com, Office365, live.com, etc) have been using these filters for a while. The big change now is that they’re being pushed down to Exchange and Outlook users not hosted on the Microsoft site.
EOP was developed for Outlook.com (and friends) as well as Office365 users. From Microsoft’s description, it sounds like the type of machine learning engine that many providers are moving to.
Microsoft has published quite a bit of information about these filters and how they work on their website. One of the best places to start is the Anti-spam Protection FAQ. Something senders should pay attention to is the final question on that page: “What are a set of best outbound mailing practices that will ensure that my mail is delivered?” Those are all things deliverability folks recommend for good inbox delivery.
Poking around looking at the links and descriptions, there is a host of great information about spam filtering at Microsoft and how it works.
A page of note is their Exchange Online Protection Overview. This describes the EOP process and how the filters work.

The perfect email

More and more I’m moving away from consulting on technical setup issues as the solution to delivery problems. Delivery is not about the technical perfection of a message. Spammers get the technical right all the time. No, instead, delivery is about sending messages the user wants. While looking for something on the blog I found an old post from 2011 that’s still relevant today. In fact, I’d say it’s even more relevant today than it was when I wrote it 5 years ago.

Email is a fluid and ever changing landscape of things to do and not do.
Over the years my clients have frequently asked me to look at their technical setup and make sure that how they send mail complies with best practices. Previously, this was a good way to improve delivery. Spamware was pretty sloppy and blocking for somewhat minor technical problems was a great way to block a lot of spam.
More recently filter maintainers have been able to look at more than simple technical issues. They can identify how a recipient interacts with the mail. They can look at broad patterns, including scanning the webpages an email links to.
In short, email filters are very sophisticated and really do measure “wanted” versus “unwanted” down to the individual subscriber levels.
I will happily do technology audits for clients. But getting the technology right isn’t sufficient to get good delivery. What you really need to consider is: am I sending email that the recipient wants? You can absolutely get away with sloppy technology and have great inbox delivery as long as you are actually sending mail your recipients want to receive.
The perfect email is no longer measured in how perfectly correct the technology is. The perfect email is now measured by how perfect it is for the recipient.

Ask Laura: Should I let my ESP give me a shared IP?

Incentivizing incites fraud

There are few address acquisition processes that make me cringe as badly as incentivized point of sale collection. Companies have tried many different ways to incentivize address collection at the point of sale. Some offer the benefit to the shopper, like offering discounts if they supply an email address. Some offer the benefits to the employee. Some offer punishments to the employee if they don’t collect addresses from a certain percentage of customers.
All of these types of incentive programs are problematic for email collection.

On the shopper side, if they want mail from a retailer, they’ll give an address simply because they want that mail. In fact, asking for an address without offering any incentive is way more likely to get their real address. If they don’t want mail but there is a financial incentive, they’re likely to give a made up address. Sometimes it will be deliverable, but belong to another person. Sometimes it will be undeliverable. And sometimes it will be a spamtrap. One of my delivery colleagues occasionally shares addresses she’s found in customer lists over on her FB page. It’s mostly fun stuff like “dont@wantyourmail.com” and “notonyour@life.com” and many addresses consisting of NSFW type words.
On the employee side there can also be abuses. Retailers have tried to tie employee evaluations, raises and promotions to the number of email addresses collected. Other retailers will actively demote or fire employees who don’t collect a certain number of addresses. In either case, the progression is the same. Employees know that most customers don’t want the mail, and they feel bad asking. But they’re expected to ask, so they do. But they don’t push, so they don’t get enough addresses. Eventually, to protect their jobs, they start putting in addresses they make up.
Either way, incentivizing point of sale collection of information leads to fraud. In a case I read about in the NY Times, it can lead to fraud much more serious than a little spam. In fact, Wells Fargo employees committed bank fraud because of the incentives related to selling additional banking products at the teller.

August 2016: The Month in Email

August was a busy month for both Word to the Wise and the larger world of email infrastructure.

A significant subscription attack targeted .gov addresses, ESPs and over a hundred other industry targets. I wrote about it as it began, and Spamhaus chief executive Steve Linford weighed in in our comments thread. As it continued, we worked with M³AAWG and other industry leaders to share data and coordinate efforts to help senders recover from the attack.
In the aftermath, we wrote several posts about abuse, blocklists, how the industry handles these attacks currently, and how we might address these issues going forward. And obviously this has been on my mind before this attack — I posted about ongoing problems with internet security, how open subscription forms contribute to the problem, and other ways that companies inadvertently support phishing operations.
I posted about the history of email, and recounted some of my earliest experiences, when I had a .bitnet and a .gov address. Did you use email before SMTP? Before email clients? I’d be curious to hear your stories.
Speaking of email clients, I did two posts about how mail gets displayed to the end user: Gmail is displaying authentication results, which should provide end users with a bit more transparency about how authentication is used to deliver or block messages, and Microsoft is partnering with Litmus to improve some of the display issues people face using Outlook. These are both notable — if this is not your first time reading this blog, you know about my constant refrain that delivery is a function of sending people mail they want to engage with. If the mail is properly formatted and displayed, and people have a high degree of confidence that it’s been sent from someone they want to get mail from, that goes a long way towards improving engagement in the channel.
On that note, I spoke at length with Derek Harding about how marketers might change their thinking on deliverability, and he wrote that up for ClickZ. I also participated in the creation of Adobe’s excellent Teaching the Email Marketer How to Fish document (no, not phish…).
Steve was very busy behind the scenes this month thinking about abuse-related topics in light of the SBL issues, but he wrote up a quick post about the Traffic Light Protocol, which is used to denote sensitive information as it is shared.
Finally, for my Ask Laura column this month, I answered questions about delivery and engagement metrics and about permissions with purchased lists. As always, if you have a general question about email delivery, send it along and I’ll consider it for the column.

Arguing against the anti-spam policy

Not long ago I was talking with a colleague who works for an ESP. She was telling me about this new client who is in the process of negotiating a contract. Normally she doesn’t get involved in negotiations, but the sales group brought her. It seems this new client is attempting to remove all mention of the anti-spam policy from the contract. As she is the deliverability and compliance person, the sales people won’t agree unless compliance does.
Her sales team needs props for bringing her in to negotiate a contract where the anti-spam clause is removed.
This isn’t that unusual situation. Many well managed ESPs will include deliverability and compliance personnel in negotiations if the customer indicates they want changes to the language of the anti spam clause.
On the face of thing it seems reasonable for customers to want to negotiate compliance terms. They want to protect themselves from unexpected outages. It seems irresponsible to allow a service provider to have the ability to made such a business affecting decision.
Many folks try to negotiate their way out of anti-spam clauses. Just asking for changes isn’t a big deal. However, some companies push the issue with sales and contract folks to an extreme. They threaten to not sign if the anti-spam clauses are removed completely.
Threatening a contract over compliance issues can poison an entire working relationship. The fact is that most people who argue about anti-spam clauses and compliance issues are people who have had problems with other ESPs in the past. For better or worse, prospects that try and remove anti-spam clauses from contracts are often problem customers.
On the compliance side, if someone is pushing hard to get the spam clause removed, they think a few different things:

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: