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

I have bounces coming to my primary email id and I get like 2-3 emails a month so I just process them manually. Not a very active forum so it has never been an issue. Thanks for the response! (Offtopic, but do I need to setup DKIM in backend if I already have it configured for SES?)
 
Chromaniac said:
I have bounces coming to my primary email id and I get like 2-3 emails a month so I just process them manually. Not a very active forum so it has never been an issue. Thanks for the response! (Offtopic, but do I need to setup DKIM in backend if I already have it configured for SES?)
Click to expand...
You will need to ensure SES's DKIM signing is covering the attributes List-Unsubscribe and List-Unsubscribe-Post which are likely not included by default

It looks like AWS may do this depending on if those attributes are set:

Using subscription management - Amazon Simple Email Service

Provides information about configuring Amazon SES to add an email footer unsubscribe link and/or a list-unsubscribe header to enable end users to unsubscribe from a list or from all customer emails.
docs.aws.amazon.com docs.aws.amazon.com
The easiest way would be to send a test email from the admincp and check if there is a List-Unsubscribe and if that header is also included in the DKIM signature (ie it should occur twice if you look at the message source)
 
bzcomputers said:
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.
Click to expand...
This issue can be dealt with rather easily:

Don't accept oncoming emails on the email address used to send emails but let them bounce directly (probably with a message to contact another email address if support is required).

This will not bring such emails down to zero, but as a little bit more effort is required to do this it will sigificantly cut down such emails (as well as broken autoresponders).

It does get more problematic if users falsely report emails as spam - how to deal with them?
Ignoring reports (probably received via FBL) is not ideal, setting their accounts to status Email invalid (bounced) isn't ideal either.

I wish it would be possible to set such accounts to a status Email reported as spam which notifies the user (via a non-dismissiable message on all pages) that emails are temporarily disabled due to them being reported as spam and giving the user a choice to either permanently disable emails or to acknoledge this mistake error and re-enabling any existing emails.

Somewhat related:
K

Thread 'Add a user option to pause (temporarily disable) all email & push notifications'

If a user is away for some time (like being on vacation for several weeks), it might be desired to not receive any (email) notifications during this time.

To achive this, the user currently would have to (at least)
  1. Opt-out from push notifications for every notification type
  2. Disable push notifications for new conversations
  3. Disable emails for new conversations
  4. Disable email notifications for every single watched item (Forum, Thread, etc.)
This is tedious and kinda disruptive as it can't be reversed easily (without noting down the previous state for each setting).

If it...
  • Like
 
Chris D said:
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.
Click to expand...
If this is implemented equivalent to stop-all it might be worth to also consider https://xenforo.com/community/threads/e-mail-unsubscribe-send-a-confirmation-email.214167/

Reasoning
Quite often users don't want to receive emails for watches, activity summary, etc. - but they do want to receive emails when they get a ne "direct message".
Now if they see an "Unsubscribe" button via their MUA GUI chances are pretty high they will click this - and afterwards wonder / complain why they do not get notifications for "direct messages" (as those are rightfully disabled as well via stop-all).
 
Last edited:
I started implementing this today with a view to it being mailto OR HTTP, not both.

Disappointing to learn that Apple and others such as Outlook do not support HTTP.

My aim was to eventually remove mailto and the automated processing entirely.

We could still go down that route, but it would mean that some mail clients would be excluded from easy unsubscribe handling until such a time that those clients add support for the full RFC 8058 standard.

On the plus side, of those email clients that do support it, they will see the header on more outgoing emails than before.

Specifically:
  • Activity summary
  • User email (from admin CP as before)
  • Watch emails
  • Conversation notifier
  • Welcome emails
Opting into the unsubscribe header behaviour is now as simple as calling ->setListUnsubscribeFromOption() on the Mail object.

Although there may be changes, currently this is the option (which replaces the existing unsubscribe email address option):

1705934330578.webp

XenForo's DKIM handling automatically handles including the List-Unsubscribe headers in its DKIM signature.

So this is shaping up quite well. I just need to decide whether it's worth adding support for Email AND HTTP. Not convinced.
 
Chris D said:
On the plus side, of those email clients that do support it, they will see the header on more outgoing emails than before.

Specifically:
  • Welcome emails
Click to expand...
That doesn't make sense to me - it is not possible to unsubscribe from further "Welcome emails" as there will be none?
Just like it's not possible to unsubscribe from lost password emails, TFA emails, etc.

Chris D said:
I just need to decide whether it's worth adding support for Email AND HTTP.
Click to expand...
I'd opt for exactly that.

As you've already noted, some clients (currently) only support email and that functionality already exists, so why not keep this until unsubscribe via HTTP is supported by more clients (I am pretty sure this will happen sooner or later) and just add HTTP?
 
Last edited:
Chris D said:
Opting into the unsubscribe header behaviour is now as simple as calling ->setListUnsubscribeFromOption() on the Mail object.
Click to expand...
Is there any reason this shouldn't be set by default and with an optout (by passing false to that function)?

There is at least 9-12 add-ons for sites I support which would need this flag added otherwise.
 
Xon said:
Is there any reason this shouldn't be set by default and with an optout (by passing false to that function)?

There is at least 9-12 add-ons for sites I support which would need this flag added otherwise.
Click to expand...
My first iteration was sort of like that but then you’d be opting out manually for any transactional emails.

Either way, keen to retain existing behaviour and then people can decide if it’s appropriate to opt in. It was opt in only anyway.


Kirby said:
Or: Just set headers whenever there is an email-stop link within the email, don't set headers if there is none.
Click to expand...
This, however, is an interesting idea. Noted.
 
We now have support for a one-click unsubscribe header and POST endpoint.

The code is still currently the first iteration whereby you have to explicitly opt in, but that's my next change.

The UI, however, has changed as discussed:

1706092451673.webp

You can now select both HTTP and mailto.

By default, in 2.2.14 and above, everyone will get the HTTP option enabled, but their existing unsubscribe email address will be retained and migrated to this option in addition to HTTP if set.

Best of both worlds.

These changes have been rolled out here if you wanted to test (we only have HTTP enabled).

The email-stop behaviour is still equivalent to email-stop/all though I have some ideas for changes here related to the concern about losing DM notifications.
 
Chris D said:
The code is still currently the first iteration whereby you have to explicitly opt in, but that's my next change.
Click to expand...
A further update: you can opt in manually if you need to, as mentioned in one of my posts above, but now the list unsubscribe headers are automatically added if the email contains something that looks like the receiving user's email-stop link (matching user ID and email confirm key).
 
Kirby said:
Hmm ... the last notification email I got for https://xenforo.com/community/threa...e-mail-unsubscribe-header.214160/post-1664730 did not contain List-Unsubscribe / List-Unsubscribe-Post headers.

Those headers are not included in the DKIM signature as well:

View attachment 297189

Has anybody else seen them?
Click to expand...
Man it's been a long week and I've only just remembered why this is.

Some email headers were not being added when a message was queued versus when it was being sent immediately. This has been fixed, but only just rolled out here.

I've had fairly debilitating dental pain this week and subsequent treatment so I'm going to blame that.
 

Similar threads

K
  • Suggestion Suggestion
Implemented E-Mail Unsubscribe: Send a confirmation email
Replies
2
Views
1K
Kirby
K
Top Bottom