I actually posted this about 2 weeks ago, but on collecting more data I realize the initial title and question covers it poorly. So I I’m positing just this title with a link to the older article, and with a question to read my bulleted list of observations that I just added to that older question.
I hope this is not frowned upon. Feel free to delete this new Q if it offends.
I am having the exact same problem. As you noticed in your experience, Peter, phpList ‘appears’ to be sending a much higher number of messages out than there are subscibers in the list. However, I don’t think it is just a matter of ‘appearing’ like that. I think phpList is actually sending more messages than just one to each subsciber.
The reason I think this is that in the last two days my hosting provider has repeatedly blocked my account and reset my email password because their anti-spam server scripts have picked me up for sending out messages at a higher rate than the server maximums.
I have been in active discussion with the hosting provider helpdesk over this and have tried to throttle phpList appropriately to send emails out well within the maximum limits.
As per the recommendations of my hosting provider, I now have the phpList config set to batch sizes of 75, period of 1800 seconds and autothrottle set to ‘on’. As I watch the list being processed, it ‘seems’ to only send 3 messages every 72 seconds (a rate that reflects my config settings) but then it stops sending…seems to freeze. I think it is stopping because the server scripts of the hosting company are automatically resetting my password when my message volume exceeds their limits. This is causing phpList to get stuck and seems to send it into a loop. The only way I can get it out of the loop is by going into the database and changing the message status from ‘inprocess’ to ‘suspended’.
I should say that my mailing lists are very small (360 subscribers on the list I have been trying to process today) and I have been using phpList for years successfully without this kind of issue.
@duncanc I agree, I had no idea. Silly really, of course there would be logging …
4107272016-12-16 17:40:04Failed sending message 141 to email@example.com
4107262016-12-16 17:40:04Failed sending to firstname.lastname@example.org
4107252016-12-16 17:40:04It took 0.0069960000 seconds to send
4107242016-12-16 17:40:04Error sending email to email@example.com Could not instantiate mail function.
4107232016-12-16 17:40:04Sending 141 to firstname.lastname@example.org
Am I correct to assume that ‘the source of all evil’ is:
Could not instantiate mail function.
? Any idea what to look at now to fix this ?
PS. don’t get fixated on the bad email address. I get the exact same logging for all the good email addresses as well !
Things are becoming clearer. Any idea what is blocking the outgoing emails ?
Sending a test email, during the campaign’s editing phase, is never a problem ?
Yet from the first email onwards, during the actual processing of the campaign, all emails appear to fail sending.
I am not aware of a block from my server host. They would have informed me. I’m on a virtual server with a unique IP.
I can ask, but I assume to know the answer. So what else could be wrong ?
I now strongly suspect it has to do with the software / OS upgrade on the server.
Where should I look to try and fix this ?
Perhaps I should loop in the server folk.
The friendly hosting service support guy triggered the script manually (the one normally done via a cron job) and it executed properly (as far as I can tell). Emails actually went through this time. All test mails to myself.
So … why not when executed via cron ?
The Cpanel emails on every cron clearly reported output from the script ?
@ibPeter You will have to ask the hosting company to investigate why the mail() call is failing. They should be able to find something in the web server or php logs. The failure reason doesn’t seem to get passed back to phplist.
I have the feeling that on server side, the person handling this has given up after a lot of back and forth emailing.
Manually executing the script worked. He also installed another php script and tested that and it worked.
"And the path the cron is executed from ?
Could that have an influence somehow ?
I don’t know enough about this server stuff, but you also were able to start the phplist script manually.
So perhaps you started it from a certain path that is different from the cron ?
Or is it a user permissions thing ?"
His last response.
“Cron is just executing a
script, so unless the script itself is not logging anything then, there
is no way to get the logs. Actually there is no server error named
"Could not instantiate mail function”, that is coming from the script
itself. Google search shows all the links related to PHPMailer. I
suggest to enable the script debugging to find what is the exact error
PHP or server is returning."
Any feedback or ammunition to get it looked at again appreciated.
@ibPeter The text “cannot instantiate …” is produced by the phpmailer code, so any error reported in the server log or php log will be different. But if you give him the exact time of a couple of errors from the phplist event log then that might help. Also, it is probably the mail server process that would be logging an error not the web server.
Thank you @duncanc and all, I was able to send out emails overnight. I woke up to the positive result, as a result from the last action last night before I turned the lights off
Copied from the Hosting co conversation (after I respectfully asked to escalate the issue to a superior) :
The PHPList software
seems to support SMTP as an alternative to the PHP mail API, so I
suggest using that as a workaround. You can can use localhost as the
SMTP server, without authentication. This should allow you to bypass
whatever problem is occurring when PHPList calls the mail() function.
This is the first solution I would recommend, and it’s also been
suggested in your forum thread.
troubleshooting step would be to enable normal shell access for user_x.
This would result in cronjobs running under a normal bash shell,
similarly to the environment where Unni successfully ran the script.
Please let me know if you’d like me to enable normal shell access.
I asked for the latter before turning in ( enable normal shell access ) and that did the job.
It seems the crons were running in a ‘jailshell’ ?
I don’t know the first thing about this, but it was my hunch that it had to do with permissions.
I’ll keep monitoring this when I start sending out the real email load Monday and the days after.
For now, knowing about jailshell vs normal shell may help others as well.
@aulda from what you have shown phplist is sending at quite a slow rate, 3 emails in 72s, so that is not the cause of your problem.
Dovecot is the mail server software that handles POP3 and IMAP access to email accounts on your domain. phplist would not use that for sending, only when retrieving bounces from the bounce email address.
The response from the hosting company that you quoted was a bit garbled but refers to the email address email@example.com
I suggest that you ask them to explain more clearly exactly what is happening for that email address. It sounds like too high a frequency of logins, so ask whether they can identify the source of the logins, say the IP address, and also the times of the logins so that you can see if they match when phplist is processing the message queue.
Could not instantiate mail function means that phpList cannot connect to the mail server. The mail server is either not running, or the settings in the config.php file are wrong. It could also be that your hosting company has blocked the connection somehow.
I would start by rebooting your server, and see if that starts the mail server.