Topic

I have done two tests to day in sending 140 emails each time.
The emails are 20 new forum topic notification emails being sent to 7 of my personal emails
So a total of 140 emails each time in the queue. This is the closest I can get to emulating each my 135 members being subscribed to new notifications for a particular forum (eg my announcements forum on my site).

I submit these 140 emails whilst the queue is ‘waiting’ so the overview shows 140 emails in the queue before it starts.

my test 1 settings were
Interval = 5 minutes
max job length = 90 secs
emails per job = 7
flexible job = enabled

the log “queue” tab shows 140 emails are sent.
the smtp server log files show 138 emails received and delivered.
so 2 have been lost
actually its 4 lost as 2 of the 138 are resends of another email
(I have the subjects of my ‘test topic emails’ labelled and numbered so I can cross check numbers sent, to whom and which are missing.)

So is it possible my queue job is still crashing due to max execution time out (120 secs)?? And could it be here that the emails are being lost or repeated due to the database not correctly being updated due to the crash??

so thinking flexible job was giving me 3 runs (of 7 = 21 emails per queue run in 120 secs as per previous tests) I did test 2 with emails per job =6. So 3*6 =18 emails per queue run in 120 secs.
End result was much the same 140 emails but 1 lost and 1 repeated.

any thoughts on how I can get all emails delivered properly to my smtp server?

what do you think would be the result of turning flexible job off, setting emails per job to 20 (or less), and max job length set to 90 (or less)?? So sending 140 emails would take 35-40 minutes (7 queue runs 5 minutes apart). I can live with this throughput now that I am bypassing the queue for wp-members password reset emails.

Replies

Hi,

If you see that 140 emails are in the log, then 140 have been sent. If the emails are marked as sent (not failed), that means that my plugin was able to send it, and the PHPMailer class responsible for delivery (class used by WordPress) has sent email and that this class was not aware of any error during the sending – SMTP server has not returned any errors at the moment of sending. That is only my plugin can do if the PHPMailer says that sending is OK, it was OK up to the moment email reached SMTP, and SMTP said that it is OK. What happens with email after that, is beyond plugin control. If the SMTP returns an error, PHPMailer returns that error to the plugin and plugin can mark the email as failed.

There are many factors that can affect deliverability on SMTP: type of SMTP software, internal configuration, and timeouts… For example, Postfix SMTP has internal timeouts and they can affect drop rates.

I will release GD Mail Queue 5.0 Pro later today that has few more enhancements to Queue. Some of the changes from 5.0 Pro will be added to 3.6 Free next week (manual settings for sleep between emails and batches, dashboard block for showing the latest logged errors). Maybe you can tweak the sleep times to see if they affect the SMTP reaction.

In the past 15 years since I had my first server online, I have changed 6 hosting companies, and I have found that SMTP can be very unreliable, depending on the hosting company and email volumes. It is no wonder that many companies specialized in email delivery (including Google Gmail, Amazon SES, SendInBlue, MailGun…) now offer SMTP only as a fallback, their primary focus is email delivery through REST API. It has nothing to do with SMTP, it is a normal HTTP protocol, it is less prone to errors. GD Mail Queue Pro has support for 6 email services through REST API, and I am seeing that more people rely on REST API. Hosting companies and ISP companies usually impose various limits on SMTP, and the REST API approach is immune to these.

Regards,
Milan

Dev4Press - Premium plugins for WordPress.

1 user thanked author for this post.

dataman

hmm ok
seems its a technology issue based around host server limitations which I can’t influence without paying more. Even then I’m not convinced my problems will go away. And I represent a community organisation with a very limited budget as well. Cost benefits of paying more just seem way out of balance to me at the moment.

I’ll keep playing around on my dev site and see what 3.6 might do for me in a week or so.

thanks for your detailed reply

In my experience, whenever I was setting any kind of shared hosting, email delivery was always the issue. When I first switched to the VPS server some 8 years ago, the main reason for the switch was email delivery that I had no control over on shared hosting. Even with VPS, there are limitations, but nowhere near to the shared hosting. I still have some minor delivery issues from time to time, but when you count all the notifications sent daily, and various other things, I think I have ranged from 500 to 5000 emails sent each day, and based on server logs, I can’t remember when was the last time I have seen the email being dropped.

With the next update, you can test sleep times too, to see if you can affect anything. Also, some SMTP servers have 60 seconds timeout, so maybe try keeping plugin timeout to 50 seconds, and see if that helps. The plugin will reconnect when SMTP timeout drops the connection, but that split second when that happens, it is possible that SMTP just flushes email waiting if its timeout is reached.

Milan

Dev4Press - Premium plugins for WordPress.

1 user thanked author for this post.

dataman

ok thanks again.