More info… we’re looking in the mysql logs, and it appears that the digest did go out, but only to the first 309 subscribers (alphabetical order), then it stopped. Same thing when I did a manual resend just now. Only 285 emails went out, then I got an error page. Again, we have 1,700 subscribers (1,400 confirmed). Why is it stopping sending emails around the 300 mark?
@emanuel,
Restoring to an old database may have corrupted some Subscribe2 settings but I doubt that if the emails are showing in your logs.
Sending to an initial number and then failing is a typical symptom of a server side restriction. Have you spoken with your hosting provider? They can make changes without you being aware until something breaks.
In the meantime, try using an SMTP plugin like Configure SMTP to channel emails via an authenticated SMTP server, that should improve delivery rates.
Hello, I just wanted to ask if there is a log file generated that we’d be able to look at, thanks.
I contacted the host. They said they are not limiting the emails. They also tell me the emails are authenticating with SMPT. What settings may have been corrupted during the database backup that we could check?
Actually, the host provider is telling me that it is not sending through SMTP, but rather through a php mail function. I’ll go ahead and install Configure SMPT and see if that works. I wonder why, though, it was working for 4 months and then suddenly stopped?
I checked Spamhaus, your IP is not blacklisted there, FYI, to that is not the problem (though I’ve seen it happen to people in the past a couple times).
@cloudautomat,
There is no in-built logging. There may be logs helps on the server accessible to your provider and you can install an email logging plugin.
@emanuel,
Hosting providers frequently say that but all that I have encountered implant some for of limitation on sendmail() to deter spammers.
So this issue isn’t yet resolved. I installed Configure SMTP and configured now at least the “resend digest” button is working on the settings page. But it is still not sending the digest automatically at 3AM like it had been for months.
Mattyrob, here is a link to refresh your memory about what we went through when you first helped me set subscribe2 up four months ago:
http://wordpress.org/support/topic/emails-not-sending-15?replies=34
Essentailly, to get it to work, we put the alternate cron line into the wp.config file. It is still there.
So why suddenly would it stop working on January 8th? Again, the only thing that happened differently that day was that we restored the database from the previous day due to some other non-related errors.
And again, looking at the mysql logs, essentially it’s beginning to send the digest out, but then it quits after a certain number of people. On January 9th it sent to only the first 180 people. On the 10th to only 309 people. On the 11th to only 173.
And yet again, this is not due to a limitation on emails. I checked with my server (Bluehost) about that, and they also showed me in WHM where that setting was, so I confirmed it. Also, when I click the “resend digest” button it correctly sends to all 1,363 confirmed subscribers.
@emanuel,
It is worth attempting a reset of the Subscribe2 cron variables. It is actually pretty simple to do. Change the Subscribe2 settings to per-post notifications and save. Then change back to your preferred digest interval and save again.
Also, bear in mind that the WHM limitations on sending apply to the we server sendmail binary, and probably don’t apply to emails pushed via SMTP. You may still be running into a limitation on the SMTP server that drops the emails.
I’ll reset the variables and report back tomorrow morning. As for limitations, though, remember that when I click the “resend digest” button all the emails are sent fine. It’s only the scheduled digest emails that stop sending after a few hundred approximately.
@emanuel,
True. The Resend Digest uses the same generating and sending code as the actual cron event. The only difference is that it is manually set in motion rather than an automated background process.
Where does the Subscribe2 cron event live? I mean can I have a sysadmin friend go in somewhere and look at it? I’m assuming when the settings are reset (which I just did), something is written somewhere besides the subscribe2 database table. Right? Something on the server itself to call up the cron job.
@emanuel,
Nothing is written to the server. Resetting the Settings wipes the stored database variables for when the cron digest was last sent and that’s all. If the WordPress cron hook had been erased then no emails would send at all when the digest was due.
