Basically, what we're seeing is this:
* Create a mass mailer list
* Add CiviCRM groups to that list
* Send to list, it sends to those in the group(s)
* If the user clicks unsubscribe, the visit the /massmailer/unsubscribe/ page
* If the user clicks unsubscribe, they appear unsubscribed...

HOWEVER, if I re-send to that list, the user WILL receive the message. AND if the user clicks on the unsubscribe link, they will be RE-SUBSCRIBED to the list.

The only external factor that I can think of that would cause this (unless it's just a bug that nobody has reported!!??) is that we back date our mailing by one day to ensure it goes out immediately.

Thoughts?

Comments

Amazon’s picture

Phillip can you give us the configuration details of how you set up your unsubscribe links in PHPList?

We are having trouble getting to the unsubscribe link.

phillipadsmith’s picture

I simply used the [unsubscribe] tag in the footer of the message. It produced this link in the e-mail:
http://mydomain.com/?q=phplist&uid=feb22362d114451f00fd53b401277bd1

Which seems to re-direct to:
massmailer//0/feb22362d114451f00fd53b401277bd1?PHPSESSID=2270844bde0c2248d6eaa6abd2827a2b

Let me know if there are other details that you need.

Best,

Phillip.

killes@www.drop.org’s picture

Version: 4.6.x-1.x-dev » master

I cannot reproduce the problem.

killes@www.drop.org’s picture

I now can. The report is about the admin interface not the one for users.

killes@www.drop.org’s picture

Status: Active » Fixed

I think I fixd it , please test

pauln600’s picture

Status: Fixed » Active

I tried the current cvs version, but it still seems to be a problem - unsubscribe removes the person from the PHPlist tables, but apparently not from the civicrm group (smart group or otherwise). So when a new message is sent and the PHPlist subscribers are rewritten with members of the group, the email that was unsubscribed is recreated in PHPlist.

onionweb’s picture

For it to work correctly, massmailer/phplist would have to set the privacy option in Civicrm to "do not email" on unsubscribe.

At the moment, the module can read what that option is, but it can't set it.

dalin’s picture

I disagree. I think that the the contact should be removed from the group instead. This allows for multiple mailing lists. Or atleast have the option to unsubscribe or mark as do-not-email.

onionweb’s picture

What if the group you are mailing to is something like "members". You'd be removing the contact from a group that they actually need to belong to.

If you want to create groups just for sending mail to then mass mailer should only be able to send to "mailing enabled" groups created specifically for mass mailer's use.

Otherwise you create a situation where the end user or admin is presented with a list of all groups, not just email list groups, and if they send mail to a regular group, users who opt -out will also be removed from groups they should belong to.

pauln600’s picture

Seems most likely that someone will want to opt in or out of receiving any messages from an organization, as opposed to particular lists belonging to an organization, and if so, setting the 'do not email' flag should be the default behaviour. Most organizations will, above all, want to avoid sending something to anyone who has chosen (or thinks they've chosen) not to receive any email. Trying to control subscriber status by subscribing and unsubscribing from groups seems like a dangerous way of managing individual contact preferences.

phillipadsmith’s picture

Hi folks,

Just want to get this conversation rolling again. Bascially, after a meeting with Paul, we determined the following to be true:

  • Currently, in phpList, if a user unsubscribes using an unsubscribe link, they are put on a blacklist and are not contacted again from any list
  • Currently, in phpList, if a user uses their preferences link, they can adjust their settings

Based on this logic, it would seem to us that if a user clicks unsubscribe in a message generated by the mass mailer module that they should have their DO NO CONTACT flag set in CiviCRM. That would ensure that they are not contacted again through any mass mailer lists, wether they be basic lists or lists of subscribed groups (or smart groups). However, an individual using CiviCRM could still choose to contact that person, either by phone or by direct e-mail.

The groups that I'm working with agree that when a user unsubscribes from a mailing list, they should NOT be removed from any subscribed groups, as those groups may be (and are) used for other functions, like letter mail, phone calling, reporting, etc. So, it would seem that the DO NOT CONTACT flag would be the direction most inline with phpList's own functions. If a user visited their preferences page, they could simply opt-out of any public lists that they didn't want to be on.

Thoughts?

Phillip.

JasonDiceman’s picture

if the 'do not email' flag is active, does that mean I can not send to that contact at all, or only not through mass mailer?

dalin’s picture

Ok, I've been convinced, it would be better not to un-subscribe them from the groups.

But I think that it would be better to use the Do-Not-Email flag instead of the Do-Not-Contact flag as the latter would include phone and mail whereas all they really want is for your pesky emails to stop.

jasondiceman@drupal.org’s picture

Title: Unsubscribe not working for CiviCRM groups that are subscribed to a mass mailer list » What about a new flag?

What about creating a new custom field(s) that specifically relate to subscription to PHPlist lists?

-jd

phillipadsmith’s picture

Title: What about a new flag? » What about a new section in CiviCRM

A new flag would be one way to go, for sure. Or, as suggeted above, the do no e-mail flag might also work. However, what Paul had suggested originally was to have a new section in the person's profile that specifically spoke to their list subscriptions -- this is in the CiviCRM details screen for an individual's record -- that would show what lists they were (or were not) subscribed to, what messages they'd been sent, or if they were currently bouncing, etc.

Admittedly, this means pulling a lot of data from phpList back into CiviCRM, but would probably be the most useful in the long run. However, I guess that leaves the most important question still hanging: What's the future of mass mailer, given the progress on CiviMail and other options? Are folks still committed to making a simple, easy to set-up, mass mail option avialable to people?

Phillip.

Evan Leeson’s picture

I sure hope so. What I would like to see is a bulk e-mail solution for Drupal like campaignmonitor.com and 12All. These services (one ASP and the other stand-alone) allow you to e-mail a list by pointing the software at a web page. The software then converts the page into a multipart e-mail and sends it out. This is much easier than using templates inside the mailer application, since it is easy to build your e-mail out of content on your system. I haven't used 12All much yet, but I have used campaignmonitor a fair bit and it is rock solid. it is worthy of the "just works" designation. They have an API, and I have been considering ways to get a module built for Drupal to work with this service. It is not free, but mass mail can be sent for as little as .5c per msg. I'm willing to pay for the level of reliability and performance they deliver. 12All is a license-based commercial application that costs 150 bucks, ao you install locally with no extra costs, but you have the expense of maintaining the software, as well as all the other headaches that come with running a mailer engine such as blacklists, etc.

dalin’s picture

Title: What about a new section in CiviCRM » should phplist unsubscribe remove the contact from a group, or mark them as "do_not_email"

Currently, in phpList, if a user unsubscribes using an unsubscribe link, they are put on a blacklist and are not contacted again from any list

Mmmm, not quite. You can put an [UNSUBSCRIBE] or [PREFERENCES] link in your email. When a user unsubscribes, their email is added to the phplist_blacklist table. With the preferences link they can remove themselves from lists individually (They are then removed from phplist_listuser). If there is only one list the user can only unsubscribe.

In my mind an Unsubscribe should result in the contact being marked do_not_email, but when a user removes themselves from a list, they should be removed from a group.

This way the admin has control by choosing what type of link to put at the bottom of an email.

The current codebase does neither, but there is a patch up for review to do the blacklist=do_not_email.