Microsoft using the List-Unsubscribe header

An interesting observation from Brian Curry about how Microsoft is using the List Unsubscribe header in their interface. The short version is that Microsoft is only supporting mailto: links. They’re ignoring any List-Unsubscribe links that are a URL.
Here are some screenshots.  When the sender is using a List-Unsubscribe <http://> header, Microsoft states that there is no information on how to help the user unsubscribe, so the offer to block the sender instead. Like in these two messages.
When the List-Unsubscribe header uses a mailto: link, Microsoft uses completely different language in the popup and does let the user know any future mail will go to the junk folder.

What does this mean?

We’re seeing a definite bias towards the mailto: link by various ISPs. Gmail has stated they prefer a mailto: link and Hotmail is refusing to support a http:// link. I think it’s good practice for every sender to use mailto: links. If this isn’t something software can handle, then that feature should be on the development roadmap.
There are a couple other things that I think are worth mentioning here.
First is that Microsoft is making it trivially easy to block senders that don’t use the List-Unsubscribe header (or just use the http:// version). Yet more evidence the ISPs are prioritizing user experience and making it easy for users to control what gets into their inbox. Blocking senders is not something that folks revisit very often. In those cases where I’ve put an explicit block in my mail client I may check it once ever couple years. Of course, the mail I block isn’t normally commercial mail, it’s people. But the principle is the same – it’s easy to block a sender and once individual blocks are set, they’re rarely reconsidered. This makes it even harder for senders to get to specific inboxes.
The second is that using the List-Unsubscribe header gets future mail from that address delivered to the junk folder. Again, a sign that user experience is one of Microsoft’s priorities. That means senders who are sending in the 10 day CAN-SPAM window aren’t actually reaching their recipients. That mail is going right to bulk.
The other issue is that Google revealed late last year that mail delivered to the spam folder at Gmail, even when that mail was delivered there by Google’s filter, negatively impacts the sender’s reputation. I, and I think other folks, were under the impression that continuing to send mail to the bulk folder was not going to actively hurt reputation. We were wrong. The reputation hit isn’t quite as big as when the individual user moves mail to the spam folder, but there is still a hit. If Microsoft is also looking at total mail to bulk then sending after an unsubscribe could hurt reputation overall.
Overall, use the mailto header for list-unsubscribes. Even if the “one click” unsub link ever get standardized, mailto is likely to be preferred by the ISPs.

Related Posts

It's not a technical problem

You can’t technical your way out of the bulk folder. I wrote that a year and a half ago, and it’s even more true today. Filters at the big webmail providers continue to evolve to meet new threats and new spamming techniques. Sending technically perfect mail won’t get your mail into the inbox. Recipients have to want the mail and interact with the mail for good delivery.
 

Read More

Filters do what we tell them

In the email space we talk about filters as if they were sentient beings. “The filters decided…” “The filters said…” This is convenient shorthand, but tends to mask that filters aren’t actually deciding or saying anything. Filters are software processes that follow rules dictated by the people who create and maintain them. The rules flow from the goals set by the mailbox provider. The mailbox provider sets goals based on what their users tell them. Users communicate what they want by how they interact with email.

What we end up with is a model where a set of people make decisions about what mail should be let in. They pass that decision on to the people who write the filters. The people who write the filters create software that evaluates email based on those goals using information collected from many places, including the endusers.
What mail should be let in is an interesting question, with answers that differ depending on the environment the filter is deployed in.
Consumer ISPs typically want to keep their users happy and safe. Their goals are to stop harmful mail like phishing, or mail containing viruses or malware. They also want to deliver mail that makes their users happy. As one ISP employee put it, “We want our users to be delighted with your mail.”
Businesses have a few other goals when it comes to filters. They, too, need filters to protect their network from malicious actors. As businesses are often directly targeted by bad actors, this is even more important. They also want to get business related email, whether that be from customers or vendors. They may want to ensure that certain records are kept and laws are followed.
Governments have another set of goals. Universities and schools have yet another set of goals. And, of course, there are folks who run their own systems for their own use.
Complicating the whole thing is that some groups have different tolerances for mistakes. For instance, many of our customers are folks dealing with being blocked by commercial filters. Therefore, we don’t run commercial filters. That does mean we see a lot of viruses and malware and rely on other strategies to stop a compromise, strategies that wouldn’t be as viable in a different environment.
Filters are built to meet specific user needs. What they do isn’t random, it’s not unknowable. They are designed to accomplished certain goals and generally they’re pretty good at what they do. Understanding the underlying goals of filters can help drive solutions to poor delivery.
Use the shorthand, talk about what filters are doing. But remember that there are people behind the filters. Those filters are constantly maintained in order to keep up with ever changing mail streams. They aren’t static and they aren’t forgotten. They are updated regularly. They are fluid, just like the mail they act on.

Read More

It depends… no more

The two most hated words in deliverability. Many people ask general questions about deliverability and most experts, including myself, answer, “It depends.”
There are a lot of problems with this answer. The biggest problem is that it’s led to the impression that there are no real answers about deliverability. That because we can’t answer hypothetical questions we are really just making the answers up.
Depositphotos_53649203_original
The reason we use “it depends” is because the minute details matter when it comes to deliverability. Wether or not something will hurt or help deliverability depends on the specific implementation. Who’s doing the sending? What is their authentication setup? What IP are they using? How were the addresses collected? What is their frequency? What MTA is used? Are they linking to outside sites? Are they linking to outside services? Where are images hosted? The relevant questions go on and on and on.
I am going to stop saying it depends when answering generic deliverability questions. Instead I will be using the phrase “details matter.” Details do matter. Details are everything. Details drive deliverability.
Details Matter
The importance of details is why many deliverability people hedge their answers. The details do matter.
I will do my best to stop answering It Depends to deliverability questions. Instead, I’ll be answering with question and pointing out the details matter.
 

Read More