[BUG] Critical Bug Report and Enhancement Request for List-Unsubscribe Functionality [Urgent]

pradeep sharma

pradeep sharma

Active Member
Dear Twested1919,

I have identified a critical malfunction within the List-Unsubscribe mechanism, specifically when activated via Google's interface, which fails to execute as intended. This issue has been replicated multiple times, confirming its persistence.

Issue Analysis:

Primary Concern:The fundamental issue stems from the fact that the current implementation of the List-Unsubscribe button directs to a URL necessitating user interaction, specifically, the submission of an unsubscribe reason. This contradicts the expected behavior, where a simple, non-interactive URL should suffice for unsubscribing. The operation is hindered when Google, employing proxy servers, attempts to access this URL, expecting a straightforward action. The current header for the List-Unsubscribe function is as follows:

Code: 
https://domain.com/lists/gr304pp8ax6c0/unsubscribe/jd3435k2bkd51/cr264rqtezdb7?source=email-client-unsubscribe-button>, <mailto:contact@domain.com?subject=Campaign-Uid%3Acr264rqtezdb7%20%2F%20Subscriber-Uid%3Ajd3435k2bkd51%20-%20Unsubscribe%20request&body=Please%20unsubscribe%20me%21>

The preferred structure should eliminate interactive elements, as illustrated below:

Code: 
https://domain.com/lists/gr304pp8ax6c0/unsubscribe/jd3435k2bkd51/cr264rqtezdb7/unsubscribe-direct?source=email-client-unsubscribe-button>, <mailto:contact@domain.com?subject=Campaign-Uid%3Acr264rqtezdb7%20%2F%20Subscriber-Uid%3Ajd3435k2bkd51%20-%20Unsubscribe%20request&body=Please%20unsubscribe%20me%21>

Secondary Concern: Regarding the configuration of the "List-Unsubscribe header email," it is currently assigned within the customer group settings. I propose relocating this option to the delivery server settings for the following reasons:

  1. Domain Email Flexibility: When utilizing the same customer group for multiple clients, the limitation to use a uniform domain email, as determined by the customer group settings, restricts the adaptability to employ distinct domain emails for different clients. Should the single domain designated in the customer group face blacklisting, it jeopardizes the email deliverability and reputation for all clients within that group. Enabling the specification of custom domain emails at the delivery server level would provide the necessary flexibility to assign unique email-domain per client as per the delivery server, thereby mitigating the risk associated with domain blacklisting.
  2. Infrastructure Segregation: As an Email Service Provider (ESP), the infrastructure, encompassing domains and IP addresses, is vulnerable to the detrimental actions of a subset of clients. To safeguard the integrity and reliability of the infrastructure, it is advisable to segregate services and operational components. By allowing the "List-Unsubscribe header email" configuration within the delivery server settings, akin to the bounce server configuration, it would facilitate a more granular and isolated management of services. This approach would enable the addition of multiple list-unsubscribe servers, enhancing operational resilience and reducing the risk of cross-contamination among clients.
In summary, migrating the "List-Unsubscribe header email" configuration from the customer group to the delivery server settings would not only enhance flexibility and customization for ESP clients but also bolster the overall robustness and reliability of the ESP's infrastructure.

Additionally, it's imperative to clarify the role and functionality of the "List-Unsubscribe-Post" header, specifically:

Code: 
List-Unsubscribe-Post: List-Unsubscribe=One-Click

This directive informs the client, such as Google, that the unsubscribe process is designed to be executed silently in the background. Upon a user's activation of the List-Unsubscribe button, the request is processed without redirecting the user to the unsubscribe webpage or presenting a pre-filled email compose window for sending an unsubscribe request. This ensures a seamless and non-intrusive user experience, facilitating the unsubscribe action to occur in both web and email modalities without explicit user redirection or interaction. It is crucial to differentiate this functionality from the standard unsubscribe process to prevent any confusion regarding the operational flow of unsubscribe requests.

In light of the aforementioned issues and recommendations, I urge the consideration and prompt resolution of these concerns to enhance the efficacy and reliability of the List-Unsubscribe functionality.

Thank you for your attention to these matters.

Best Regards,

Pradeep

########### attached pics of user reported spam increased after migrating to mailwizz keeping smtp,domain,data,and lists same...

1709670085396.png


1709670458602.png
1709670554103.png1709670662911.png
 
Last edited:
Hello,

pradeep sharma said:
The fundamental issue stems from the fact that the current implementation of the List-Unsubscribe button directs to a URL necessitating user interaction, specifically, the submission of an unsubscribe reason. This contradicts the expected behavior, where a simple, non-interactive URL should suffice for unsubscribing.
Click to expand...
This is not correct, if it was a direct link, it could be triggered by anti-spam software and would falsely trigger unsubscribes.
Instead, following the standards, we include two headers for the list-unsubscribe:
1. is the regular List-Unsubscribe one, which includes a URL and an email address
2. another header that says when the button is pressed, a POST request must be made to that URL.

Now, when somebody clicks the "Unsubscribe" button from the email client, google for example, will make a POST request to the unsubscribe URL, which looks like this:
Code: 
http://mailwizz.test/index.php/lists/gy77512vk9610/unsubscribe/ps114hykc6e05/gn523l3fr7bab?source=email-client-unsubscribe-button

And the result, as expected, is the subscriber gets unsubscribed:
Screenshot 2024-03-06 at 09.09.07.png

pradeep sharma said:
Additionally, it's imperative to clarify the role and functionality of the "List-Unsubscribe-Post" header, specifically:
Click to expand...
Sure thing, best is explained as:

Code: 
How does it work?

In addition to the List-Unsubscribe header, another line - the “List-Unsubscribe-Post” - is
added. Here is an example:

List-Unsubscribe: <mailto:listrequest@example.com?subject=unsubscribe>,
<https://example.com/unsubscribe.html?opaque=123456789>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

Simply opening the link from the List-Unsubscribe header in a browser, or by anti-spam
software, will show a landing page which does not cause an immediate unsubscribe, but
may offer a button to confirm the unsubscribe.
But performing a POST request on that URI, sending the key/value pair from the ListUnsubscribe-Post header will cause the unsubscribe without the need of interaction.
Quoted from above:
Simply opening the link from the List-Unsubscribe header in a browser, or by anti-spam
software, will show a landing page which does not cause an immediate unsubscribe.
Click to expand...
Which is what MailWizz does.

Still from above:
But performing a POST request on that URI, sending the key/value pair from the ListUnsubscribe-Post header will cause the unsubscribe without the need of interaction.
Click to expand...
Which again, is what MailWizz does. We're even a bit lax, and we only require a POST request, we don't even care about the incoming payload.

See this PDF for more info on these headers.

When such unsubscribe happens, the reason will be set automatically by MailWizz and it is "Unsubscribed via Direct POST request".

pradeep sharma said:
Secondary Concern: Regarding the configuration of the "List-Unsubscribe header email," it is currently assigned within the customer group settings. I propose relocating this option to the delivery server settings for the following reasons:
Click to expand...
That's the FeedBackLoop-ID, something totally different.


So I don't know, to be it seems we're doing the right things.
 
@twisted1919

It is not doing what it is supposed to do!
I tried several times.
I further dig and checked the NGINX logs i found the POST request like this

Code: 
66.102.8.108 - - [07/Mar/2024:17:34:09 +0530] "POST /lists/sw973vfqgh41b/unsubscribe/bb213znsfjaab/do935d6cy2fcd?source=email-client-unsubscribe-button HTTP/2.0" 302 0 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/1.0 (KHTML, like Gecko; Gmail Actions)"

but no action was taken by the post request at the application i.e subscriber does not get unsubscribed

Moreover, an email is also not sent from the user's inbox with an unsubscribe request and the same is not received.

Please allow me so that i can message you in private with some credentials so that we both can check.

How We can replicate this

1. We added an email into the list.
2. Send a campaign to the list using a domain with high reputation and where (Gmail Unsubscribe button showing)
3. Pressed Gmail Unsubscribe button on that email
4. Checked NGINX Logs (POST Request received at application)
5. Subscriber does not Unsubscribe
also
6. NO EMAIL was sent email user inbox to list unsubscribe email id used in List-Unsubscribe header and neither recieved.

Please help

Regards
 
Hi @twisted1919

I checked in postman and when i made a post request on postman to the web URL used in list unsubscribe header.. it was unsubscribed correctly.

BUT

the post request received from Gmail are not processed.
Can i can share details to you if you want.

The testing of this can only be done if there is Unsubscribe button is appearing in Gmail for sending domains and i have 1 such domain where i am constantly getting this button.

Please Consider this..

in my server there were 373 such requests for a small newsletter volume i send using this setup. i took nginx logs and marked them unsubscribed manually as a workaround to prevent further abuse from subscribers.
 
If you take a look in your logs, the status code you have there is 302 NOT 200, so there's something off with your server when it receives requests from gmail, not something related to MailWizz. I also see the request is made under http 2.0 instead of 1.1, which might indicate your server accepts such connections but does not handle them properly.
 
I ll Share the NGINX Logs from both GMAIL & POSTMAN then will see what's wrong and where.
I would request you that you can test if over your testing environment with Gmail unsubscribe button. I can share my sending domain SMTP details where this unsubscribe button is appearing.
I hope you understand my point.
 
@twisted1919

i did the testing and found the following

Below the request made with Gmail Unsubscribe button
Code: 
"POST /lists/he602ccd0w31c/unsubscribe/df2137827300b/jb679v1l5c77b?source=email-client-unsubscribe-button HTTP/2.0" 302 0 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/1.0 (KHTML, like Gecko; Gmail Actions)"

and

here is the request from postman

Code: 
"POST /lists/he602ccd0w31c/unsubscribe/df2137827300b/jb679v1l5c77b?source=email-client-unsubscribe-button HTTP/2.0" 302 0 "-" "PostmanRuntime/7.36.3"
223.190.83.155 - - [10/Mar/2024:13:45:45 +0530] "GET /lists/he602ccd0w31c/confirm-unsubscribe/df2137827300b/jb679v1l5c77b HTTP/2.0" 200 1645 "https://track-updates.technocon.org/lists/he602ccd0w31c/unsubscribe/df2137827300b/jb679v1l5c77b?source=email-client-unsubscribe-button" "PostmanRuntime/7.36.3"

So In both cases, the 302 redirect is taking place not 200

in Gmail unsubscribe, button post requests there is only 302 direct and in postman POST requests there is 302 redirects and then the GET requests to 302 URL

I found this link important
stackoverflow.com

What is the correct behavior expected of an HTTP POST => 302 redirect to GET?

What is the correct behavior expected of a POST => 302 redirect to GET? In chrome (and likely most every browser), after I POST (to a resource that wants me to redirect) and I receive a 302 redir...
stackoverflow.com stackoverflow.com

i am sure that this is not just my server issue. please look into this try to provide a solution!

Regards

Pradeep
 
Can you please open a support ticket and share with us the application backend credentials? Maybe SSH will be necessary.

Cosmin
 
You must log in or register to reply here.
Back
Top