Email Campaigns Auto Unsubscribing?

Every time I delve into email Campaigns I find something else that either is not working, or just don’t understand. Grr. It’s so complicated!

I managed to create the campaign, and send out the test entries. Then for some reason, when I send to my gmail address it automatically unsubscribes me. I got the email, opened it, it tracked the open, then without clicking on the unsubscribe link, it unsubscribed me.

Is this something unique to gmail? Or is something else going on? Anyone ever experienced this?

What suite V are you using?

@dhuntress this particular installation is on 7.13.1

I should probably add, that my other email address test went fine. It was only gmail. I then un-opted out myself. Sent the test again, and it opted me out again.

Is it really “unsubscribing” you, deleting your address from the database or from the Target list? Or just not sending you any email?

It sounds like you’re simply hitting the mechanism that suppresses sending the same email twice to the same address. This won’t happen on test target lists, but will on the other kinds of target lists.

Thanks @pgr sometimes a picture is worth a thousand words:

image

I did in fact receive the email, opened it, but did not click on the unsubscribe link. It did track the open.

I see.

Isn’t there a generic, per-user opt-out option somewhere? I mean, something not tied to the Campaign, but to the user/Contact. Note that you might have more than one record in the CRM using that email since you probably keep using it for tests. This might be confusing SuiteCRM.

I would also suggest adding some logging to check if the code in modules/Campaigns/RemoveMe.php is being executed.

Thanks @pgr, I’ll have a look. This is the only one of that email address I have. I was using my business email and that seems to work fine. It’s only gmail that auto unsubscribes. I wonder if this is something unique to gmail, if they are crawling the links or something?

I’ve heard of this before, it’s certainly possible.

Try my suggestion of checking if Removeme.php is getting called. If it is, the next step would be to try differentiate automatic calls from human calls. This is not always possible, but I woulnd’t be surprised if the User Agent on the request was different.

Ok I’m back on this project again. I sent 12 emails out and 12 opt outs. Only 6 opened the email so it’s not possible 12 unsubscribed. No emails bounced and there are no emails returned in the bounce account.

Just when I thought I had this figured out. Anyone else have this issue?

I have “opt in” turned to “Disabled” in email settings. Normally I would have it set to “Opt in” and then opt everyone in manually by bulk update.

What happens when you add a log to modules/Campaigns/RemoveMe.php to print the User-Agent from the request? Is it a google crawler? If yes, then just return without unsubscribing them.

1 Like

Hey @chris001 thanks. I’m going to be testing that this morning. It’s not just Google. I “assumed” it was Google because it was happening to only the Gmail address I used for testing. However, the rest of the test emails were internal to O365 account and the gmail one was the only external one. Now all the external ones are getting unsubscribed. So now I’m wondering if its and O365 thing. I’ll post what’s going on in the logs shortly.

O365 has the same type of email link crawler as google, that browses the links in emails, to make sure they’re not giving their users links to pages with malware or reported phishing/scams.

Makes sense this email link crawling is what’s causing the unsubscribe. Because when you browse to the page /index.php?entryPoint=removeme&identifier=xxxx, you immediately get back “You have elected to opt out of receiving emails.”

I believe there’s a standard way to indicate in an email that it’s an automated mailing, that the user has consented to receiving, and that a particular link in the email is for unsubscribing, so that the email app can automatically do it for the user, when the user taps a button in their mail app, so they don’t have to actually browse to the unsub page.

Ok in all cases, gmail or not, this is the user agent that is initiating the removeme.php link:

User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729)

I’ve been doing some more research on this, and wow, the more I dig into email the more complicated it becomes! Apparently, there are lots of email security scanners that crawl the links with a GET request and cause this to happen. and the suggestion is to limit the remove me functionality to only POST requests. Something like:

if ($_SERVER['REQUEST_METHOD'] === 'POST') {

But you’d have to send the user to another page with a form that submits the unsubscribe by a POST request.

This kind of makes sense. Many email campaign management systems send the user to a page first where he then confirms the unsubscribing.

1 Like

I have had a similar problem - I wrote some code to add an extra “confirmation” form.

I think there needs to be a confirmation form built into SuiteCRM since more and more mail servers use “mailscanners reading the links” in an email, which in case of the REMOVE me leads to an immediate unsubscribe.

2 Likes

Thanks @jobst for posting the issue! Fixing this will protect campaign report data from inaccuracies (no more security crawler activity getting to the reports), and prevent microsoft and other anti-malware link-scanning email providers from unintentionally yet instantly unsubscribing all of their users’ email addresses from email campaign lists!

Yes I’ve seen this before but elsewhere - user registration link that was always expired on delivery to o365 box

I had to put recaptcha on the page form so that the crawler couldn’t click the link before intended.

OR Put a time limit on the unsubscribe function

There’s a really helpful post on StackExchange that details some other bits and pieces to combat this :slight_smile:

Hey all, I normally use Sendgrid for outbound emails. I just changed this client over to Sendgrid for campaign email vs. O365. Sendgrid works perfectly. It looks like they re-write the unsubscribe link and handle the unsubscribe and then re-direct it back to SuiteCRM unsubscribe page. There is no “auto” unsubscribing and actual unsubscribing works as intended.

This works for me, but would be nice to have a “feature” that handles this better.

What about the suggestion of checking the User Agent string as it reaches Removeme.php?

A simple if there could solve your problem, assuming there are ways to distinguish the web crawler from the actual user action, by inspecting the User Agent string sent with the request. I believe there are.