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.
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.
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.
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 
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.
I checked that, itās pretty generic windows NT. I was hoping there was something in there that IDād it as Microsofts link crawler, but nothing is poping out as unique.
Can you try an actual user action to unsubscribe, and see if there is a difference?
This is an actual unsubscibe that I just did from Sendgrid. (note thereās more info here, I added the request method and IP to see if I could find something to control for but no luck, MS uses a few different IPs to crawl the links. I tried that too. In this case obviously Iām using my desktop to unsubscribe so there are some differences
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36 | IP Address: xx.xx.xxx.xxx | Request Method: GET
I agree, I have been following my logs for a few months.
NOTHING indicates itās a scannerā¦
I have been checking my logs for a while, there is no indication using the User Agent String whether itās a bot or normal user.
At on stage I thought to check the IP addresses, there is SOME possibility in there for SOME of the unsubscribes, but that is too unreliable if they switch the ip address (which they do).
I have added a āconfirmation pageā into my chain of events, the last mailout (Friday) has let to proper responses, my āconfirmation pageā is now solid.
SuiteCRM needs to add one, the massive unsubscribes are a real problem.
Happy to contribute ā¦ but this is āa little more involvedā to start with ā¦
Step by step how to try out the Fix, here: