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.
How is this done? I’m not aware of any phplist functionality that handles spam complaints.
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.
@Crenel84 Thanks.
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)?
I explained this previously
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.