What is a list-unsusbcribe header, you might ask? It's an email header, typically hidden from the end user, that includes information that allows the MUA (mail user agent; meaning your email client, email reader, or webmail platform) to submit an unsubscribe request on your behalf. This is typically linked up to an "unsubscribe" button in a webmail provider's user interface. If you see an "unsubscribe" button or link in the Gmail or Outlook.com user interface for a given email message, that message likely contains a list-unsubscribe header.
The header itself is defined in RFC 2369 from 1998. It's very common for email service providers and list management tools to provide support for this header; and if you're building any sort of new tool or list mail sending service, I would recommend including it. Doing so makes it just as easy for a subscriber to click "unsubscribe" as it does for them to click "report spam." Making it easier to unsubscribe means you're likely to garner fewer spam complaints, and thus your deliverability and sending reputation will be at least slightly higher than they would have been without this functionality.
There are two methods of specifying how to unsubscribe a subscriber using the list-unsubscribe header. There's the HTTP method, and the MAILTO method. The HTTP method implies that when it is time to request unsubscribing of that particular user, a particular web page will be visited. The URL would typically include all of the parameters necessary to denote which subscriber, for which sender, is requesting to be unsubscribed. The MAILTO method implies that when it is time to request unsubscribing of that particular user, an email message will be generated to the email address specified in the list-unsubscribe header. (The destination email address typically would include all of the parameters necessary to denote which subscriber, for which sender, is requesting to be unsubscribed.)
A few days ago, Melinda Plemel of Return Path clarified that Microsoft is now only utilizing the MAILTO method and that they are not supporting the HTTP method at this time. (It is implied that Microsoft properties previously supported both the MAILTO method and the HTTP method, but I don't have a lot of experience with the HTTP method myself and I was not able to confirm this.)
TL;DR? Implement a list-unsubscribe header, or make sure your email platform provides one. If you're building it yourself, only implement the MAILTO-based functionality, as it is the most broadly supported. (I'm aware of multiple ISPs supporting the MAILTO method, but I am not aware of any others that are or were supporting the HTTP method, other than Microsoft.)
What is a list-unsusbcribe header, you might ask? It's an email header, typically hidden from the end user, that includes information that allows the MUA (mail user agent; meaning your email client, email reader, or webmail platform) to submit an unsubscribe request on your behalf. This is typically linked up to an "unsubscribe" button in a webmail provider's user interface. If you see an "unsubscribe" button or link in the Gmail or Outlook.com user interface for a given email message, that message likely contains a list-unsubscribe header.
The header itself is defined in RFC 2369 from 1998. It's very common for email service providers and list management tools to provide support for this header; and if you're building any sort of new tool or list mail sending service, I would recommend including it. Doing so makes it just as easy for a subscriber to click "unsubscribe" as it does for them to click "report spam." Making it easier to unsubscribe means you're likely to garner fewer spam complaints, and thus your deliverability and sending reputation will be at least slightly higher than they would have been without this functionality.
There are two methods of specifying how to unsubscribe a subscriber using the list-unsubscribe header. There's the HTTP method, and the MAILTO method. The HTTP method implies that when it is time to request unsubscribing of that particular user, a particular web page will be visited. The URL would typically include all of the parameters necessary to denote which subscriber, for which sender, is requesting to be unsubscribed. The MAILTO method implies that when it is time to request unsubscribing of that particular user, an email message will be generated to the email address specified in the list-unsubscribe header. (The destination email address typically would include all of the parameters necessary to denote which subscriber, for which sender, is requesting to be unsubscribed.)
A few days ago, Melinda Plemel of Return Path clarified that Microsoft is now only utilizing the MAILTO method and that they are not supporting the HTTP method at this time. (It is implied that Microsoft properties previously supported both the MAILTO method and the HTTP method, but I don't have a lot of experience with the HTTP method myself and I was not able to confirm this.)
TL;DR? Implement a list-unsubscribe header, or make sure your email platform provides one. If you're building it yourself, only implement the MAILTO-based functionality, as it is the most broadly supported. (I'm aware of multiple ISPs supporting the MAILTO method, but I am not aware of any others that are or were supporting the HTTP method, other than Microsoft.)
Comments
Post a Comment
Comments policy: Al is always right. Kidding, mostly. Be polite, please and thank you.