• This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.

Email Queuing Enhancements 1.1.1

No permission to download

tommydamic68

Well-known member
#2
Not sure if Its what I am looking for. Will this limit the number of emails sent per hour? Most shared hosting only allow 500 emails per hour.

Thanks,
 

Xon

Well-known member
#3
Not sure if Its what I am looking for. Will this limit the number of emails sent per hour? Most shared hosting only allow 500 emails per hour.

Thanks,
This addon was made for the purpose of ensuring the XenForo application will actually hand off email to the configured mail transport (SMTP in my case).

Every so often; DNS, routing, mail server config has a derps and I want the email to just resend without risking losing notifications. It doesn't do any rate-limiting.

What I recommend is @xfrocks's [bd] Mails addon, and then signup for a free https://mandrill.com/ The first 12k emails per month are free.
 

tommydamic68

Well-known member
#4
This addon was made for the purpose of ensuring the XenForo application will actually hand off email to the configured mail transport (SMTP in my case).

Every so often; DNS, routing, mail server config has a derps and I want the email to just resend without risking losing notifications. It doesn't do any rate-limiting.

What I recommend is @xfrocks's [bd] Mails addon, and then signup for a free https://mandrill.com/ The first 12k emails per month are free.
Yes I already do that, it's quite a mission to send my newsletter that way.
 

Xon

Well-known member
#5
Yes I already do that, it's quite a mission to send my newsletter that way.
The reason I suggested [db] mails addon is it submits email via http. It does not use your shared provider's SMTP and hence does not need to worry about SMTP rate limiting.
 

Xon

Well-known member
#6
ah, ok got it. And it supports [bd] mail's use of alternative transports? Thinking mandrill specifically....
I actually developed it using an alternative transport* which uses the same process as [bd] mail for registering as a mail transport in XF.

*this one, it is a non-production email transport. It throws away your email and logs a message to the forum's error log. Great in testing, very bad for a live forum.
 

nrep

Well-known member
#11
Hi Xon, interesting addon - I think this is what I'm looking for (to pair with [BD] Mails), but I wanted to check a couple of things :).

Does this mean e-mails will be sent as quickly as they are at the moment? For example, if a password reset button is clicked, does the user have to wait 10 mins for the queue to process - or is it instant? I send myself a test e-mail from the bulk mailer tool, but it seemed to take longer than usual to arrive.

If there is a waiting period, does it only process one batch per period, or are all queued e-mails sent?
 
Last edited:

Xon

Well-known member
#12
Hi @nrep, thank you for your interest. That addon combination will work together.

Emails are deferred to the next time the mail queue is evaluated, which can take between 30 seconds to a or minute later depending on how deferred tasks are processed. Depending on load at the time (ie installing an addon and rebuilding all the caches, or re-indexing) email sending may be significantly delayed.

The addon works in batches per deferred run, and any leftovers are left for the next run of queue evaluation again and subjected to deferred task scheduling.

The batch size is configurable, with the default being 20. On my own site, I've adjusted the batch size to be 100.

The waiting period applies for when something goes wrong. If an email fails, emails are placed in a failed email queue and a cron task checks the queue every 5 minutes. There is then additional configuration to only retry failed emails every 'x' minutes.

If there is interest; I can adjust this addon so XF will try to send the email instantly and if anything goes wrong; it places it into the failed email queue rather than pushing everything through the standard XF mail queue.
 

RoldanLT

Well-known member
#15
Is this a bug?
I just changed my bounced email, imap settings.

But this addon still trying to send using the old email.
Maybe because it was cache/stored on deferred and not updated with the current bounced email I'm using.

How to sort this?
 

Xon

Well-known member
#16
Is this a bug?
I just changed my bounced email, imap settings.

But this addon still trying to send using the old email.
Maybe because it was cache/stored on deferred and not updated with the current bounced email I'm using.

How to sort this?
The return address (aka bounce email) is burnt into the email object which has been queued for sending. So if you have a chunk of email still in the queue, they will be using the old bounce email address.

It is something of a design limitation.
 

Xon

Well-known member
#18
This addon still try to send emails even if I disabled Forum Wide Email via config.php.
It respects that flag when email is about to be queued for sending, but once in the queue it was missing the check to see if it should send.

Expect an update shortly to fix that.