phpList is designed to prevent a customer from receiving multiple emails from a single campaign. Yesterday a customer notified me that they had received 15 copies of a current email campaign (still checking on the accuracy of that count). I checked the logs and see that the customer has multiple instances of their email address being processed in our cron job. The log records show the following types of information for the customer, repeated multiple times:
phpList - Error sending message 107 (39/55) to example@example.com (example@example.com) [10.9146660000] (5020)
phpList - sent 1 ETA Sat 17 Oct 04:12 sending 8 msg/hr
These types of log records, with a positive value after “sent,” often show dates that are far into the future.
Other examples show the following:
phpList - Error sending message 107 (38/55) to jess_styles@icloud.com (jess_styles@icloud.com) [0.2602900000] (4898)
phpList - sent 0 ETA unknown sending 0 msg/hr
These records provide no date or time information.
I cannot find anything else in the logs to help identify what is occurring. I have looked at the campaign metrics tab and find some very odd information. The campaign should have been sent out to approximately 32000 email addresses. The campaign stats show the following:
9155 “Sent”
23078 “still to process”
for a derived “total” of 32233
Yet phplist also shows 75467 as “Sent as HTML”
and 937 as “Not sent”
(By the way, I see nothing in the manual that explains what these designations actually mean. Is it there and I missed it?)
Has anyone encountered this type of problem, where there are multiple instances of “error sending message” in the logs for a single customer, along with instances of those customers actually getting the email multiple times?
That sounds like a miscommunication between your MTA and phpList. The MTA is reporting an error but is sending it anyway. To diagnose that, you will need to check your mail logs. It may help to lower the speed of sending by adding some throttling delays and batch processing. Most likely your MTA is choking on the flow of mails.
Our configuration sends directly to our ISP’s SMTP server. As a result we have no access to the logs on their server.
We have previously implemented throttling delays and batch processing via the config file in order to conform to their sending limits. We manage this via a cron. This has worked fine for many months but just recently started behaving as I describe above.
What we are missing is error reporting from phpList for the communication between phpList and the SMTP server. All we get back is “error sending message” language in the logfile. As a result, we have no way to troubleshoot the root cause.
If it worked and then stopped working, the best thing to do is to review the things that have changed recently. But if you do not have full access to all systems, it will be tricky to diagnose and find the cause. I use Postfix and send millions of emails and haven’t come across this yet, otherwise I would have fixed it. And obviously I have used phpList for quite some time. If you can find the cause, please let us know and we can work out how to avoid it.
Hi Michiel, thanks for your reply. We have performed a series of rollbacks but have not been able to identify the culprit. The three principal items in the mix are an upgrade from 3.0.8 to 3.0.12, a test of a custom rewrite of the Segmentation plug-in that was provided by Duncan Cameron and a specific email that seems to fail each time. We turned on verbose logging but it doesn’t provide much help.
By the way, do you perform your throttling and batch processing in Postfix or in phpList? If in phpList, how do you compensate in case your ISP access goes down? When it comes back up, the emails flood out without benefit of the throttling and batch processing.
I’m facing the same issue - and I’M quite desperate on this. are there any solutions so far?
Throttling doesn’t help and I keep getting messages on this by several of my readers, it is very annoying. I’m quite happy with the system on other subjects, but this is driving me mad - and towards changing the mailing system if there is no solution to the problem
phpList is designed to only send one copy of a campaign message to a subscriber.
What seems to be happening is that the communication between phpList and your outgoing smtp (mail) server is reporting an error, but is sending the message anyways.
I’d look into the settings for the mail server, and make sure (verify) that phpList is using the current valid settings of the email server.
It could be that the ISP changed some settings on the email server, but didn’t mention anything (which would explain why it used to work, but it doesn’t work now).
