Fixing a problem with "Unsubscribe" in Outlook.com

One of the problems that some of our users have been experiencing in Outlook.com is using the "You can unsubscribe" widget:

The widget above shows up when we think the message is bulk, and the message contains a List-Unsubscribe header, and that header contains a mailto. We parse out the mailto and send a message to the address, unsubscribing you from the list. If the List-Unsubscribe header only has a http link, we do not show the widget. If it has both a mailto and a http link, we still only parse out the mailto.

One problem users experienced around this widget was when the List-Unsubscribe header was malformatted:

 List-Unsubscribe: < mailto : bulk@example.com >

In the above, it's intuitive to you and me what the email address is, but there are spaces in the middle of the mailto link. This was causing parsing issues and leading to users getting weird bounces in their inbox.

We're fixing this problem. We're making the email address parser more robust so that it more intelligently extracts the email address and is less prone to failure. Just like how spammers were malformatting the From: address, bulk senders (not spammers in this case) were malformatting the List-Unsubscribe. In each case we had to make our parsers smarter, so that the widget does what users expect it to.

This change should be released in the next couple of weeks.

A few of you may be curious why we don't support the http part of the List-Unsubscribe header. There are two reasons:

1. Not all List-Unsubscribes are single click. Some of them go to a page and then force you to click another box, or click several boxes to "manage your subscription", and so following that http link may not actually unsubscribe you from the newsletter since we don't click around on the page after we would follow the link. Thus, you'd be unsubscribing but not actually having anything result from it.
   .
2. The geeky second answer is that it would be a synchronous operation. That means that you'd click the link, we'd spin up another web window in the background and block you from doing an action until the click succeeded before we could message back to you whether or not it succeeded. That can happen in web pages that resolve slowly, or not at all. That's an unacceptable user delay, we'd take all the heat for the UX responding slowly, even though it's the newsletter's back end that is not responsive.The fix for this is to make it asynchronous, that is, not blocking. You'd click and then in the background we follow the link and the "session" would be closed.
   .
   Then, we'd have to find a way to notify you that the operation succeeded or failed. That sort of thing is possible, but it requires some design to get it working.

That's the rationale.

It turns out that for #1, there is a new Internet standard, RFC 8058 - Signaling One-Click Functionality for List Email Headers. It became a standard just this past year, in January 2017. This solves the problem in #1 by adding an additional header to signal to the web UX that following the http link in the List-Unsubscribe header is a single click action, so web UX widgets can safely use that and the action will be what the user expects.

For #2, that still requires some engineering effort. I've asked our team to look into it, but I don't have a timeline on it just yet.

• Anonymous
  May 03, 2017
  Hi Terry,about list-unsubscribe message: "This email looks like a newsletter but we can't be sure that the unsubscribe function is safe ... Block sender instead...": can you detail the reason of this warning please ?Regards,Pascal