I’m using phpList 3.6.14. This morning I sent a newsletter, and it was sent to two subscribers who were blacklisted last month after they reported my newsletter as spam (after they subscribed to it, of course). When I look at their subscription logs (“Subscription” tab), I see the initial subscription followed by “blacklisted” and “auto unsubscribed” entries and no entries indicating they were re-subscribed nor un-blacklisted. Looking at their subscriptions (“Lists” tab), I see they’re still subscribed.
Obviously, I have now manually unsubscribed them, but this is a serious problem.
Luckily in these two cases, the subscribers did not actually get a message. That’s only because I use AWS SES for sending and I recently changed the configuration so that any abuse complaints automatically put addresses into my SES suppression list. So, that safety net from AWS kept these two people from getting what really would have been spam, since they clearly don’t want my newsletter.
Any thoughts on why this critical functionality has failed so badly and how to resolve it?
I have another newsletter to send today, to a list about 3x larger than the earlier one, and this situation makes me pretty nervous. The SES suppression list will only have addresses from recent complaints, not people blacklisted before I changed that configuration.
ETA: I had someone else mark my newsletter as spam today. (I only do double opt-in, so these complaints are bogus, but that’s part of dealing with random people on the Internet.) Once again, blacklisted and auto unsubscribed… but not unsubscribed, still showing as subscribed to the list.
I’ll have to go through all of my lists and manually unsubscribe everyone who is blacklisted. This is a mess.
Through bounce rules. Since I’m using SES, I can use the complaints@ address that the spam complaints are routed through to trigger a “blacklist email address” action, and that does trigger as expected. The address is blacklisted, and the log says that the subscriber is also unsubscribed (which is not accurate). Yet two blacklisted emails today had mail sent to them.
The bounce rules are a bit of a mess. You need to use the ‘Add subscriber to the do-not-send-list and delete bounce’ rule instead. I don’t know why the rules for the email address exist as they deliberately do not mark the subscriber as blacklisted.
It has been working to add people to the blacklist, though:
Added to blacklist for reason Email address auto blacklisted by bounce rule 2
And I can see by looking at their subscriber record that they are showing as blacklisted. However, this subscription log entry…
email auto unsubscribed for bounce rule 2
…is false. They weren’t unsubscribed (or, alternatively, unconfirmed) from anything. And, clearly, being blacklisted meant nothing, and being unsubscribed would have been the important part.
That mail would be sent to someone who is blacklisted, and for whom the phpList UI clearly states will not receive mail, is kind of the last straw for me. I’ve used phpList for years, and I truly appreciate the effort behind it (and vital plugins, like AmazonSes, SegmentPlugin, and SubscribersPlugin), but I think it’s time for me to move on.
The alternative solution I was looking at (Sendy) is not working out well, to put it mildly. I would rather stay with phpList for a number of reasons, but I also don’t feel safe using it right now. Yet I did tonight, because I need to stick with a roughly-monthly newsletter schedule, and I’m spinning my wheels with Sendy.
Is there a way to trace through the logic after the fact to figure out why phpList included a specific subscriber in a campaign (in my case, people who were blacklisted)?
The bounce rules for “email address” add that email address to the user_blacklist table but do not mark the row in the user_user table as blacklisted. Whereas the bounce rules for “subscriber” do mark the row in user_user table as blacklisted, which means the email address will not be selected when sending.
But as I noted, the log shows that people are blacklisted and the phpList interface consistently shows them as blacklisted, including stating that they won’t get email, yet messages were sent to them. This sounds like bad data design, if two tables must be updated to reflect one piece of information, and it’s definitely misleading in the phpList UI to state that users won’t get email but they might.
Thanks for the tip about what tables to look at. I will check to see if the affected users were, in fact, only in the user_blacklist table and not marked as blacklisted in user_user.
I have, for now, given up on Sendy and am still using phpList. Multiple reasons for that, but in a nutshell, I didn’t trust Sendy enough - even though I was having serious issues with phpList. Sendy can do things for me that phpList currently can’t without plugins, and one thing phpList can’t at all regardless of plugins (would require a third party to add phpList integration), but there were multiple things about Sendy that put me off. This resulted in the decision to plod forward with phpList and hope things don’t get too bad.
Regarding the specific issues I had with phpList, I never could allocate the time, energy, and mental focus to dig into why it was sending to people that the UI claimed were blacklisted. What I’m doing with phpList is supportive of my “career” writing and publishing fiction, which has basically tanked in recent years due to extreme demands at my day job (e.g., working 15-18 hour days for months on end). If I ever recover some sort of work/life balance, I’d like to contribute to the phpList project - directly and via plugin development. For now, I have to just hope that the efforts of others will work out for me.