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.
Hi
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.
@aulda If you enable VERBOSE in your config file then phplist will log each email that is sends in the event log. That should help to understand the rate at which it is sending.
@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 shouldbounce@shouldbounce123shouldbounce.com
page: processqueue
4107262016-12-16 17:40:04Failed sending to shouldbounce@shouldbounce123shouldbounce.com
page: processqueue
4107252016-12-16 17:40:04It took 0.0069960000 seconds to send
page: processqueue
4107242016-12-16 17:40:04Error sending email to shouldbounce@shouldbounce123shouldbounce.com Could not instantiate mail function.
page: processqueue
4107232016-12-16 17:40:04Sending 141 to shouldbounce@shouldbounce123shouldbounce.com
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 !
Yes, every time a mail gets blocked by your host or errors, it is placed back in the queue for further processing. This is how you sometimes see 3500 emails sent w/ only 2000 subscribers
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 ?
I have no limit as far as I know and I’m certainly not sending fast at the moment anyway.
The From address does exist but is not on the same domain I suppose !? It’s a domain hosted on the same server but the server itself has a .biz extension.
But … again … this always worked ?
And the server tech just executed the script manually successfully ?
On the command line no issue … via cron all the earlier shown symptoms ?
@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.
I argued:
"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.
Another possible
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.
Thanks Duncan, I have got logging on and can’t see anything untoward in there…logs the emails it sends to actual people on the list but not the other activity it seems to be doing ‘behind the scenes’.
The hosting tech guy came back with this:
"While investigating I found that the script is resetting the password due to high number of dovecot logins to email : 314 dovecot_login:enquiries@theloaf.co.uk
Not sure if the mailing list is causing a separate login attempt to send the emails. Can you please confirm if you are using email client like outlook to send the emails."
I have no idea what ‘dovecot login’ would be, or if phplist does this. Though I use gmail to transact all my personal emails, I assume phplist operates independently of whatever email engine one uses?
This screenshot shows the live logging. It only seems to show the emails one by one and doesn’t indicate any extra activity going on in the background that might be causing an issue.
Thanks again for your help…sorry @ibPeter for hijacking your thread, but it seemed to be the same issue. Though I don’t know what a cron is, so perhaps we aren’t quite doing the same thing.
@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 enquiries@theloaf.co.uk
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.
