Fixed Add support for One-Click E-Mail Unsubscribe Header

[Kirby]

XenForo currently implements (automatic) unsubscribe via mailto in header List-Unsubscribe.
This allows users to easily unsubscribe from admin-emails by clicking the unsubscribe link in supporting email clients, this generates an email that XenForo can automatically process to unsubscribe the user.

RFC 8058: Signaling One-Click Functionality for List Email Headers is a specification that anhances the functionality of List-Unsubscribe by specifying another header that allows supporting clients to issue an authenticated HTTP POST request to unsubscribe the user instead of sending an email.

Using HTTP POST instead of email has several advantages

• Depending on the client, sending an email might require additional user interaction (to complete and send the email) making it more complicated for the user
• The current email-based automatic unsubscribe processing implemented by XenForo requires a dedicated mailbox
• It requires the admin to configure this dedicated email account in XenForo
• It requires the server to have the IMAP PHP extension
• It requires the server to be able to make outbound connections to the server hosting the mailbox
• Processing a HTTP POST request is much easier and more reliable than requesting & parsing emails via IMAP / POP3

So all in all this approach seems easier to setup, more flexible and more reliable than the existing implementation.

While support by mail clients is not (yet) that widespread it IMHO wouldn't hurt if this was supported

 

[Chris D]

This has been supported since XF 2.1:

XF 2.1 - Welcome to XenForo 2.1 / Assorted improvements

Welcome to XenForo 2.1! We said there would be something special accompanying the final HYS in this series for XF 2.1, and here it is. This is your first opportunity to help us put the new feature set through its paces. We also said there would be a number of other miscellaneous...

xenforo.com

 

[Kirby]

@Chris D
Nope

XenForo implemented List-Unsubscribe with mailto; RFC 8058 requires List-Unsubscribe with a URL, an additional header List-Unsubscribe-Post and a valid DKIM signature inculding those headers.

 

[Chris D]

Fine. Not sure we’d go down that route when the functionality basically already exists.

Either way; if you want to make a good suggestion, please provide more details in the first place. Most people won’t have time to read a full RFC spec.

 

[Kirby]

Fair enough

I've updated the first post to include more information about One-Click unsubscribe (so a visitor reading this thread doesn't have to read the RFC to understand what this suggestion is about) and why I think this would be beneficial.

 

[Xon]

@Chris D Google and Yahoo are moving forward with requiring One-Click unsubscribe via RFC 8058:

Gmail And Yahoo Inbox Requirements & What They Mean For Senders | Mailgun

Gmail and Yahoo announce transformative updates to come in 2024. The updates impact senders but implementing the changes is easier than you think. Are you ready?

www.mailgun.com

The exact syntax to support this isn't terribly complicated:
8.1. Simple

   Header in Email

   List-Unsubscribe: <https://example.com/unsubscribe/opaquepart>
   List-Unsubscribe-Post: List-Unsubscribe=One-Click

   Resulting POST request

   POST /unsubscribe/opaquepart HTTP/1.1
   Host: example.com
   Content-Type: application/x-www-form-urlencoded
   Content-Length: 26

   List-Unsubscribe=One-Click

mailto: is optional, but a https url is required. The tricky part is DKIM signing must be used to cover the two headers

 

[bzcomputers]

This would be nice. With lots of daily new members, the first thing a few of them always do is immediately reply back "unsubscribe" to there registration confirmation email.

Rather than explaining to them "We have no subscription... we will not email you unless...". I just send them an email "Per your request, your account has now been deleted...", and delete their account. It's too much hassle with back and forth emails to individual members trying to explain it in anymore detail.

It would be much simpler with an unsubscribe link in all emails. They're happy, I'm happy with more members and workload is reduced.

...time to go attend to some more unsubscribe requests

 

[Chris D]

This would be nice. With lots of daily new members, the first thing a few of them always do is immediately reply back "unsubscribe" to there registration confirmation email.

Rather than explaining to them "We have no subscription... we will not email you unless...". I just send them an email "Per your request, your account has now been deleted...", and delete their account. It's too much hassle with back and forth emails to individual members trying to explain it in anymore detail.

It would be much simpler with an unsubscribe link in all emails. They're happy, I'm happy with more members and workload is reduced.

...time to go attend to some more unsubscribe requests

I don’t think it’s reasonable to expect that transactional emails such as registration confirmations would have any sort of unsubscribe functionality.

 

[Chris D]

@Chris D Google and Yahoo are moving forward with requiring One-Click unsubscribe via RFC 8058:

Gmail And Yahoo Inbox Requirements & What They Mean For Senders | Mailgun

Gmail and Yahoo announce transformative updates to come in 2024. The updates impact senders but implementing the changes is easier than you think. Are you ready?

www.mailgun.com

The exact syntax to support this isn't terribly complicated:
8.1. Simple

   Header in Email

   List-Unsubscribe: <https://example.com/unsubscribe/opaquepart>
   List-Unsubscribe-Post: List-Unsubscribe=One-Click

   Resulting POST request

   POST /unsubscribe/opaquepart HTTP/1.1
   Host: example.com
   Content-Type: application/x-www-form-urlencoded
   Content-Length: 26

   List-Unsubscribe=One-Click

mailto: is optional, but a https url is required. The tricky part is DKIM signing must be used to cover the two headers

Read this myself yesterday. We’ll try to tackle this with 2.2.14 and above.

 

[bzcomputers]

I don’t think it’s reasonable to expect that transactional emails such as registration confirmations would have any sort of unsubscribe functionality.

You would think it wouldn't be necessary, but with everyone's reluctancy to be on any sort of email list anymore, they seem to just reply "unsubscribe" to any email they receive.

Whether the unsubscribe link actually does anything or not on transactional emails I think just having the unsubscribe link there would reduce admin/mod workload with replies to transactional emails that just say "unsubscribe". I think we all get them, and some of us a lot of them.

 

[Chris D]

Having an unsubscribe link that doesn't do anything is even more bizarre and probably exacerbates the situation if they happen to get a second transactional email for something else.

Deleting accounts, especially brand new accounts in your example, also seems counter intuitive to me.

It's certainly not unreasonable, if you don't want to see or action such requests, for the from email to be a "noreply" email. That's certainly the norm. You wouldn't find me ever actioning such requests.

I do perhaps feel that making certain email intentions clearer might be beneficial though.

"You are receiving this email because..."

Or in the case of email verification, particularly for new accounts, clarify what they have/haven't (just) opted into.

I'd also like to make (our) unsubscribe links more prominent in emails that have them. Probably moving them to the top, rather than the bottom. The client's themselves rendering an unsubscribe button - if that actually happens - will be a huge help too. Despite us including what was, at the time, the preferred approach for the unsubscribe header, I don't think many clients were actually rendering the button. I believe, at least at the time, this was due to only including the unsubscribe mechanic on emails from servers that had built up a significant enough reputation or volume to warrant it. I hope with this renewed focus this changes, and they'll display the unsubscribe button as a result of the header in all cases where it is present.

 

[Kirby]

I don’t think it’s reasonable to expect that transactional emails such as registration confirmations would have any sort of unsubscribe functionality.

Agreed, it's not necessary for emails like registration confirmation, lost password, email TFA, etc. - but it IMHO definitly would make sense for notification type emails that already have email-stop links in the HTML (like watched_thread_reply).

Those emails currently do not have a List-Unsubscribe header.

Ideally I think they should have one with a https URL compatible with RFC 8058.
If accessed via GET present the form that is currently used for email-stop (eg. let the user choose to stop notification emails for this specific content, all notifications for this content type or all notifications) - if accessed via POST stop notifications for the specific content.

Especially for activity summary emails which are not really transactional this really would make sense (to me).

 

[Chris D]

Wow do we really only include the List-Unsubscribe header on outgoing emails sent via the admin control panel? That feels like an oversight to me. It was perhaps intentional at the time, but I absolutely agree that should be included in more cases.

 

[Chris D]

With our intention to resolve this, and some functionality I feel is incomplete/missing, reclassifying this as a bug to be resolved in the next releases.

 

[bzcomputers]

Having an unsubscribe link that doesn't do anything is even more bizarre and probably exacerbates the situation if they happen to get a second transactional email for something else.

Deleting accounts, especially brand new accounts in your example, also seems counter intuitive to me...

I see where you're coming from and agree that some of my issues can likely be addressed with an additional line in transactional emails stating something like... "You have not been subscribed to any email list...". There will be many who will still not read it though and the "unsubscribe" requests will still come , but hopefully in fewer numbers.

 

[Kirby]

Wow do we really only include the List-Unsubscribe header on outgoing emails sent via the admin control panel?

As of XenForo 2.2.13, XenForo only adds List-Unsubscribe to emails sent via ACP > Communication > Email users.

The unsubscribe processor disables the options to receive admin and activity summary emails but doesn't do anything in regards to other notification emails.

 

[Chris D]

I think the way forward is for that to appear on more outgoing emails, and it will be equivalent to the stop-all action we have, which should revert all watches to "alerts" and disable the admin/activity summary emails.

 

[Suzanne O]

It will help with those who ask where the unsubscribe button is!
I know that my mate who runs bigfooty has loads of people asking.
If you get this fixed he will be happy.

 

[Chromaniac]

would this require bounce/unsubscribe features to be configured? i deal with this manually so far but if they would be needed for this, i better start working on setting them up. last time i tried, it was a hassle considering i do not do email on my own domain which means i would need to create two different email ids on third party services. any recommendations?

 

[Chris D]

We highly recommend bounce anyway, but that's unrelated to this.

Fair to say that unsubscribe handling in its current form will probably be deprecated immediately and will be removed in 3.0. The new unsubscribe handling starting with 2.2.14 will not require the configuration of an incoming mailbox.