Subscribers not auto-blacklisted after x consecutive bounces

ℹ️ Support
1

I still run an older phplist version because the plugin interface changed at some point and I couldn’t keep up. Also, everything still works more than OK, so no pressure. Or so I thought.

PS. I also only send two bulk emails per year so I’m starting to notice below issue just now.

For the longest time this has worked well btw. After 4 consecutive bounces (set in config.php) the subscriber gets blacklisted. I only send twice a year so it can take two years before a subscriber is actually blacklisted, but ok.

I am currently sending out an email and quite accidentally I noticed a subscriber who SHOULD have been blacklisted, but he’s not ? The interface clearly shows bounces were received and processed for this subscriber, with proper date stamp and everything.

So the cron job that checks the emails and updates the bounce list in the database works.

/usr/local/bin/php -q /home/xxx/public_html/xxx/admin/index.php -c /home/xxx/public_html/xxx/config/config.php -pprocessbounces

What however could cause phplist not to blacklist these subscribers ?

Last year somewhere php was updated, other than that nothing has changed for many years.

Where do I look to try and fix it. I understand completely when you say ‘update phplist’ but please understand I need to try and remedy this first under current conditions. The email needs to be sent ‘now’ before I spend weeks trying to update phplist (yes, I’m that uncomfortable with it + the plugins, it worries me)

Does the issue of not blacklisting sound familiar ? Perhaps it is an issue that has been encountered before ? Or what process could be failing exactly ? Where do I look for errors (if there are any - I certainly am not seeing any errors)

I now also realize I used to get emails when the cron job blacklisted subscribers and I have not seen such emails in a while.

2

I got some server side support, they ran -pprocessbounces manually and got output:

PHPlist - 9 bounces to fetch from the mailbox
PHPlist - Please do not interrupt this process
PHPlist - Closing mailbox, and purging messages
PHPlist - reprocessing
PHPlist - 7135 bounces to reprocess
PHPlist - Database error 2014 while doing query  Commands out of sync; you can't run this command now
PHPlist - Database error 2014 while doing query  Commands out of sync; you can't run this command now
PHPlist - Database error 2014 while doing query  Commands out of sync; you can't run this command now
PHPlist - Database error 2014 while doing query  Commands out of sync; you can't run this command now
PHPlist - Database error 2014 while doing query  Commands out of sync; you can't run this command now
PHPlist - Database error 2014 while doing query  Commands out of sync; you can't run this command now
PHPlist - Database error 2014 while doing query  Commands out of sync; you can't run this command now
PHPlist - Database error 2014 while doing query  Commands out of sync; you can't run this command now
PHPlist - Database error 2014 while doing query  Commands out of sync; you can't run this command now
PHPlist - Database error 2014 while doing query  Commands out of sync; you can't run this command now
PHPlist - Database error 2014 while doing query  Commands out of sync; you can't run this command now
PHPlist - Database error 2014 while doing query  Commands out of sync; you can't run this command now
3

A second (manual) run gave a different result:

PHPlist - A process for this page is already running and it was still alive 71 seconds ago

And a third and last run failed with a failed download ?

PHPlist - 0 bounces to fetch from the mailbox
PHPlist - Please do not interrupt this process
PHPlist - Closing mailbox, and purging messages
PHPlist - Download failed, exiting
4

I had a similar problem like this. I believe the issue was that my database was big, and that the various queries to lookup a bounce took too long. In the end, I don’t remember exactly what I did, I might have extended the wait time for each command to finish, or just deleted the bounces (or some of them, i.e. before a given date), and that fixed it for me. In either event, you need access to the database, or the php commands/config file.

5

I have access. I just don’t know what I’m doing. I changed the BatchSize in the php (see different thread) but I don’t think that worked (not sure how to test)

7

via the front end, log of events, I could see this just now:

777381 2025-11-25 23:30:08 Database error: Data too long for column ‘data’ at row 1
page: processbounces

777380 2025-11-25 23:30:08 Database error: Data too long for column ‘data’ at row 1
page: processbounces

8

The Subscription tab on the Subscriber Profile page for that subscriber should show what has happened. The subscriber should have been marked as unconfirmed.

The config setting BLACKLIST_EMAIL_ON_BOUNCE doesn’t do what you are expecting. It marks the email address, not the subscriber, as blacklisted. So the “Is this subscriber blacklisted” field remains as “No”. I don’t really understand the purpose of this but think that it is to do with stopping that email address being subscribed again, not to do with sending campaigns to the subscriber. But marking the subscriber as unconfirmed will have done that.

9

Thank you for that clarification.

However, from what I can see, the email addresses are not properly blacklisted once the threshold is reached.

This used to work fine. PS. It’s not my experience that subscribers get unconfirmed ?

For instance, in the past, when a subscriber / email had too many consecutive bounces, and I would look up that record via the email address, I would see a thumbs down in the search result, and once the record selected there would be a black bar at the bottom clearly indicating blacklisting.

Not getting the usual emails telling me users have been blacklisted due to consecutive bounces has made me suspicious, so I manually found a few examples. In these examples (subscribers / emails) I see that my last 2-3 campaigns pushed the consecutive bounces over the edge, and yet they were still not blacklisted and emails can still be sent to them in a following campaign.

This says two things: 1. The cron job to process bounces starts and successfully parses the inbox and adds the bounces to the database. 2. That same process never gets to the point where it actually blacklists the emails.

Or at least, that’s how I currently interpret the results (mind you I’m out of my element here). The errors posted here are, I suppose, signs that the script never reached the end ?

At this point I’m unsure what to do. I changed the batchSize to 250. This was a suggestion in another thread here, but that doesn’t seem to do the trick

10

@ibPeter I would forget about using BLACKLIST_EMAIL_ON_BOUNCE and remove it from the config.php file. Set $bounce_unsubscribe_threshold to the same value.

There might be a very large bounce email in the mailbox causing the “too long” error. If you can access the mailbox manually, such as through web mail, then delete all emails from the mailbox.

11

Thank you @duncanc, for your concrete suggestions.

There is no BLACKLIST_EMAIL_ON_BOUNCE in my config.php, so that’s not the issue.
$bounce_unsubscribe_threshold is currently set to 4 and the ‘examples’ I identified have 5-6 consecutive bounces. So that setting is currently being ignored (due to the script never getting to that point I think)

The mailbox is successfully emptied each time -pprocessbounces runs.
Just to double check I logged in just now to find only one single small bounce email that I’m sure will get purged when -pprocessbounces runs again via a cron job that executes every half hour.

Anything else I can do ?
I’m currently down under, so our time zones don’t exactly overlap.

12

This thread:

Makes me think it’s a mysql issue in the code. The newer mysql when php was updated must have an issue with something in the code of my older phplist install.

13

The code enters:

while ($bounce = Sql_Fetch_Assoc($req)) {
++$count;
if ($count % 25 == 0) {
    cl_progress(s('%d out of %d processed', $count, $total));
}
$bounceBody = decodeBody($bounce['header'], $bounce['data']);
$userid = findUserID($bounceBody);
$messageid = findMessageId($bounceBody);

if (!empty($userid) || !empty($messageid)) {
    ++$reparsed;
    if (processBounceData($bounce['id'], $messageid, $userid)) {
        ++$reidentified;
    }
}
}

in processbounces.php but seems to never get passed this loop. It dies somewhere in this loop.

I tried debugging by mailing myself at various places in the loop but I had to kill the process as I did not realize $total is 7140 at the moment. That was a bad idea :wink: gmail was not happy.

I’m not sure what this process is meant to do but clearly $total seems to increase as in above mentioned errors it was 7135

14

I just had a good chat with ChatGPT :slight_smile: and it turns out my phplist version is too old for PHP 7. Certain mysql functions won’t work anymore and ChatGPT alledges they are still used in my version.

Let’s put this to rest.

Sorry for wasting your time. I will do the work, the plugins worried me, ChatGPT is convinced it’s an easy conversion, let’s put that to the test :slight_smile:

It also assured me that:

:check_mark: Duncan Cameron’s plugins are still available and are updated

His plugins are actively maintained and compatible with the latest PHPList 3.6.x:

  • CommonPlugin → essential dependency, latest 3.24.x

  • CaptchaPlugin → still available

  • Segmentation → still available

  • Campaigns → still available

LOL, so, thank you again.