`List-Unsubscribe` header broken on double opt-in confirmation emails

[blu3id]

Version:

• listmonk: v6.1.0
• OS: Docker

Description of the bug and steps to reproduce:

1. Ensure Include `List-Unsubscribe` header setting is enabled.
2. Create a public double opt-in list.
3. Subscribe a user to the list.
4. Issue a POST request to the List-Unsubscribe header in the email sent to the user (What the List-Unsubscribe-Post: List-Unsubscribe=One-Click tells mail clients to do).

Expected result: User is marked as unsubscribed for the unconfirmed list(s) or blocklisted?
What actually happens: Nothing - if you examine the response to the POST you see a "Unsubscribed successfully" message.

Discussion:

I came across this accidentally exploring the code and looking closely at headers etc. to investigate #3037. The issue is the unsubscribe URL is populated as follows using the "dummy" UUID: /subscription/00000000-0000-0000-0000-000000000000/{subscriber-uuid} this means that the POST handler is unable to identify the list to unsubscribe the user from.

While this "bug" doesn't pose a big issue it technically is abusing the List-Unsubscribe header standard as the "one click" doesn't do anything. Though the argument can be made that the user hasn't confirmed their subscription so there is nothing to unsubscribe from.

I don't know what the best approach to fixing this would be options I can think of:

1. Blocklist the user (though could have unintended behaviour as would unsubscribe from other lists)
2. Mark the user as unsubscribed for all unconfirmed lists in the opt-in email
3. Don't include the header in opt-in confirmation emails
4. Leave as is

[czottmann]

Chiming in here, hope that's okay: I'd go with (3) as in my opinion, opt-in emails do not belong to any particular list, they are part of the administration/maintenance.

[knadh]

Please see:

• List-Unsubscribe header not in double opt-in confirmation #2224
• e8fd12b

[blu3id]

Completely forgot to search closed issues 🤦 sorry.

Interesting discussion previously. Note that the addendum in the last comment identified that this was likely not because of the missing header.

I'm personally of the view that this probably shouldn't be on opt-in emails particularly if it isn't functional.

However given the history here this is clearly not the best way forward reverting previously requested behaviour.

So the options I see are:

1. Make this header actually do something (option 1 and 2 from my OP above) - not my preference
2. Add another option to include or not List-unsubscribe in opt-in emails so people can make their own choices and update documentation to make clear this is non-functional by design.

Happy to do a PR for 2 if that is agreeable as a way forward?