Feature request: better control of bulk mails per time

[opentype]

There is already the BULK_MAILS_PER_CYCLE constant to solve issues with hosts that have trouble with many emails at once. 
Equally, if not more important, is how many emails are sent in a given timeframe. It’s normal for hosts and email services to have some kind of limit in that regard, but with the way IPS sends out bulk mail, it unpredictable when these limits are being hit and there is no way around this problem when the limits are hit. 

I suggest a solution like a MAX_MAIL_CYCLES_PER_TASK constant or setting to limit the amount of cycles run each time a cron is being fired. So, for example, I could set 1 run of 100 emails with the cron running every minute resulting in 1000 mails in 10 minutes. 

I understand that IPS isn’t all that focussed on features that would only help self-hosted customers, but it seems like an easy implementation which could help a lot of users. It’s actually the behaviour that people are already expecting. 

[Marc Stridgen]

On 1/27/2024 at 10:55 AM, opentype said:

I understand that IPS isn’t all that focussed on features that would only help self-hosted customers, but it seems like an easy implementation which could help a lot of users. It’s actually the behaviour that people are already expecting. 

I have to admit, I find that to be quite an unfair assessment, as this is not the case at all. What is actually happening is that we tend not to add software functionality to solve what are ultimately hosting issues. To further clarify that statement, we don't even do that for cloud either. If there is a cloud problem, we solve the cloud problem, rather than writing things into the software to work around it.

So in this instance, we're trying to solve the problem of mail limitations by limiting the mail that is sent. The correct way to resolve this is to ensure you don't have a mail provider with limitations which will hinder the running of your software.

It's worth noting too, that solutions such as these come with their own problems. Using your example, we would end up seeing people who have limited it to the 1000 every 10 mins, and yet have 1500 emails needing to be sent being produced. Meaning that the backlog simply builds up indefinitely until something breaks. This is just one I can think of straight of the bat. 

[opentype]

I would rather say calling it a “hosting issue” is the unfair assessment, when having such limits is essentially a default in the entire hosting industry.

https://kb.mailpoet.com/article/150-lists-of-hosts-and-their-email-sending-limits

And even if I would go through the trouble of moving everything to a paid service like for example Amazon SES (just to get bulk mails out without issues despite having a perfect email delivery otherwise), I then have their sending limits per day. The issue remains, just with different limits. 

It’s not some edge-case issue on a cheap shared hosting environment that we are asking to “work around”. It’s just a reasonable way to deal with email delivery in standard hosting environments. And in contrast, it feels rather unreasonable, that I can have a perfectly working local SMTP delivery; in my full technical and legal control; highly optimized delivery through DNS settings; no privacy issues because no 3rd-party services are needed; working perfectly fine for all transactional mails; all at no extra costs … and then potentially have bulk-mails fail in an unpredictable manner because the background tasks may or may not take the right amount of time.