FluentCRM 2.9.48 Release Announcement

Karl Emil Nikka Our developers are checking this. We're doing some R&D and you'll get a promising update on this soon.

Karl Emil Nikka I think this is an interesting question. When a 3rd party platform is integrated and may make changes independently (as with the AI feature pushing) it makes sense to maintain a fallback editor in case they do something wacky. This is also relevant to users' constant requests for LTDs. I guess that Shahjahan has some negotiated price for usage and can't know what future costs will be. However, maintaining even a little flexibility to swap it out can give him a stronger negotiating hand. Either way, when you have a fixed annual cost cost component for maintaining a product, it would be a risk mismatch to sell an LTD.

Karl Emil Nikka I read your ticket and the issue. FluentCRM does not handle per lists subscriptions and you can actually send emails without selecting any lists or select multiple lists. So we don't know actually from which list we have to unsubscribe them.

So it's not a bug in technical point of view.

Shahjahan Jewel Yes, it is a bug. It doesn’t follow the RFC.

Karl Emil Nikka Not sure which RFC it does not follow. As per our design, if someone unsubscribe, then it will unsubscribe from the system. Our lists / tags are just like taxonomy to segment the contact.

Shahjahan Jewel I should’ve included the details. RFC 2369 and RFC 8058 define how the list-unsubscribe header should be implemented (quote below).

The URI in the List-Unsubscribe header MUST contain enough information to identify the mail recipient and the list from which the recipient is to be removed, so that the unsubscription process can complete automatically.  Since there is no provision for extra POST arguments, any information about the message or recipient is encoded in the URI.  In particular, one-click has no way to ask the user what address or from what list the user wishes to unsubscribe.

Karl Emil Nikka  I think we follow the RFC here. Please note that, In FluentCRM Lists is not equal to the list header mentioned in the RFC. So it's an one-click unsubscribe and in RFC's list mean unsubscribe from the system. I think it's how it works in Brevo or Kit or active campaign. In Mailchimp, it's different: A List in Mailchimp means it's totally a separate company / account and also works as same. When you unsubscribe it unsubscribe from the entity.

Shahjahan Jewel In that case, we interpret the RFC differently, but I can’t say for sure that my interpretation is the correct one. I’ll stop bothering you about it. Thanks for your replies.

Shahjahan Jewel I'm OK with this. If somebody doesn't want to receive my emails, I don't want him to unsubscribe from every list/tag.

If someone unsubscribes, I simply respect his decision and don't want him on my list/ecosystem.

I hate when some systems tell me that I unsubscribed from one list but that I could receive emails from other lists... -_-

Jose Luis Duron +1, they always have the email preference management to choose which kind of emails they want to receive. I'm not sure why email marketers have to respect lazy people who wants to unsubscribe from a specific list with one click.

And even if email clients want to respect that, remove the email length or HTML restrictions so we can add unlimited content and links within a single email without the fear of landing in spam..

Nazir Himel and Jose Luis Duron Please note that I’m only talking about the list-unsubscribe header, not the subscription management page. The reason is want this addressed is because we have to completely different kinds of newsletters. One is a regular newsletter. The other one is alerts in case of vulnerabilities. Subscribers might want to unsubscribe from the newsletter but keep getting notices about vulnerabilities.

Karl Emil Nikka I get that. Then again, if the subscribers do not want a specific kind of email, you can help them do so by setting up the email preference management page correctly. They can simply choose what kind of emails they want to receive in the email preference management page. If you don't know how, I'm happy to help you set it up.

Nazir Himel We replaced the whole subscription management system for this particular purpose. I’m only talking about the list-unsubscribe header, which isn’t affected by the preference management page.

Shahjahan Jewel If you follow the RFC then the FluentCRM concept of "lists" is misleading. Etiher way, something is wrong. I'm afraid I think this is a fundamental flaw that means FluentCRM is unsuitable for businesses that want to use it for more than one of (1) newsletter, (2) marketing automations (3) transactional email, and (4) community notifications.
We can't expect end user contacts to understand that Unsubscribe on one type of email will unsubscribe them from other types of email. And if we need to maintain transactional or community notifications we can't send marketing emails with a great big invitation to nuke their subscription to everything.
I realise this is not a trivial feature to add, but it would fix a serious problem.

Shahjahan Jewel (Christopher Miller) After reading the RFCs again, I cannot draw any other conclusion than that my initial statements were correct. The sender is called a “mail sender” and a list is called a “list”.

The URI in the List-Unsubscribe header MUST contain enough information to identify the mail recipient and the list from which the recipient is to be removed, so that the unsubscription process can complete automatically. Since there is no provision for extra POST arguments, any information about the message or recipient is encoded in the URI. In particular, one-click has no way to ask the user what address or from what list the user wishes to unsubscribe.

I can’t find anything supporting that the “list-unsubscribe” header should unsubscribe the contact from all of the “mail sender’s” lists. On the contrary, the RFC is very specific that the link must include information about which list the contact should be unsubscribed from.

Please see ticket #116821 for a suggested workaround within FluentCRM’s current limitations.

Karl Emil Nikka Strong agree. I have read the RFC and it is very clear. I would also add that FluentCRM is taking list-unsubscribe to mean withdrawal of GDPR-compliant consent to be emailed at all. When GDPR is so clear about requiring explicit informed unambiguous consent to receive email marketing, and we all work hard and jump through hoops to get that, it's crazy to interpret the meaning of one-click list-unsubscribe as withdrawal of all email consent from an organisation (including non-marketing), without the contact being explicitly made aware that is what is happening.

Conversely, it makes absolute sense for the instant unsubscribe to apply to that type of email only, especially when there is a more detailed manage subscription link at the bottom.

I have created a list called "UNSUBSCRIBE All" which is available in the manage subscription page to trigger an automation which removes from all lists, and removes the marketing consent tag, but it does not perform a full FCRM unsubscribe, so that non-marketing emails can still be sent.

This previously solved the problem, even if it is a bit hacky; BUT the list-unsubscribe header reintroduced the issue in a way I can't mitigate, since the list-unsubscribe header link does not contain any information about which email or list it came from.

As far as I can see, the correct implementation is that where a campaign is sent to a single defined list or subset of a list, the list unsubscribe header (and the unsubscribe footer) should trigger a removal from that list only. Plus there should be an explicit option on the manage subscriptions page to unsubscribe from all lists, and also the ability to opt a specific campaign or automation email out from including the unsubscribe options, in case the email is non-marketing.

Christopher Miller Agree. Shahjahan Jewel, if you still don’t share our interpretation of the RFCs, please let us know so that we can start working on third-party solution.

Christopher Miller (Shahjahan Jewel) The support team has now confirmed that it’s unlikely FluentCRM will be a RFC compliant newsletter tool. That’s very unfortunate.

“Our R&D has already reviewed your ticket and has informed that it is unlikely to be implemented as FluentCRM is designed differently. Still, we forward your recent suggestion to our R&D for further consideration.”

My suggestion (from January 2025) was the following.

”To address this, FluentCRM must first check if the contact is subscribed to multiple lists. If the contact is subscribed to only one list, the specified list should get removed and the subscription status should switch to “unsubscribed”. If the contact is subscribed to multiple lists, the specified list should get removed but the subscription status should remain unaffected.”