I noticed for the past few days no emails were being sent for posts on the forum. I checked the dashboard and found 0 emails for the past 3 days. No idea why, I had to reboot the server and then it started sending emails but here are a few issues I am noticing: There was no notification provided on the admin account that it’s having issues sending emails, even the logs didn’t show any errors After the reboot it starting sending the backlog of emails but the problem is after sending the initial batch of 100 emails now I’m getting an error Job exception: 454 4.7.0 Too many login attempts, please try again later and it’s stuck in that loop continuously trying to login to sending the remaining emails but the server is rejecting it. It looks like for EACH email it’s trying to login to the SMTP server. This IMHO is a bug, it should not login to the server for each email when there is more than one email to send, it should reuse the existing connection. Now it’s stuck in this trying to login loop even few seconds, how do I stop it and ask it to back off for 10-15 minutes and try again?

I don’t see this as a bug, either a configuration issue or a feature request for better logging. We are only doing what you tell us per your SMTP settings, if you set the password we try to authenticate.

How is this a logging issue? If there are 200 emails in the backlog (a whole different issue as to why the email module stopped working creating a backlog), it shouldn’t authenticate 200 times. It should authenticate once and then send the 200 emails in a single authenticated session. It would be inefficient to authenticate, send one email, disconnect and do this over 200 times. The other issue is that if the STMP is asking it to backoff it doesn’t but keeps hammering away at it, there should be a backoff algorithm to wait and then retry. I fail to see how these are logging issues.

Have you tried sending a text message from the admin /email page since this problem started?

[Bild] pfaffman: Have you tried sending a text message from the admin /email page since this problem started? Yes, that’s how I started to debug the issue, it didn’t send the eMail. Then I rebooted the server and email started working again (again no changes to any configuration) but now it started sending the 266 backlog emails and after the initial batch the STMP started throwing and error about too many logins and there where I figured out that Discourse was authenticating with the SMTP server for each individual email separately causing it to push back. I had to manually stop the server for 10 minutes then start it, it would send the next batch of 30-50 emails and then again the SMTP would push back, then I’d stop the server, wait 10 minutes and then start until the entire backlog was cleared. I still fail to see how this has anything to do with logging. It’s an inefficient and possibly incorrect way to implement sending multiple emails.

That is indeed very strange. What mail server is it?

I tried to take a look at the code to see how emails are built and delivered. I didn’t find any specific place where the emails are “queued” up into a backlog and then delivered. It looks like each service/module sends emails independently. However I couldn’t see any “queue”, so I’m just left wondering why discourse decided not to send any emails for 3 days and then to send 266 emails after rebooting the server. It’s almost like the notification system just went offline and then came back online after a reboot and iterated through all pending notifications from each module. Again I couldn’t find any “single” piece of code that does this. Since it appears that each notification is send independent of the other, I guess there’s no way to “reuse” an authenticated SMTP connection. The crux of the code appears to be: begin @message.deliver_now rescue *SMTP_CLIENT_ERRORS => e return skip(e.message) end Given my rudimentary understanding here, there doesn’t appear to be any control over the SMTP connection. If so, as there’s no way to control the SMTP connection, instead can there be a rate limit option provided in the eMail settings to not deliver more than X messages per minute or second? This would help where SMTP servers have rate limits and would help in situations like this when messages get backlogged (for whatever reason) and then suddenly cleared. alternatively can the email sender module process the SMTP error when it pushes back saying that it’s logged in too many times and back off before for X minutes before sending it again (again this could a configurable parameter in the settings) @eviltrout looks like you seem to have a fair amount on the eMail notifications. Any thoughts on the above?

We have no support for email rate limiting and no plans to add it.

Okay so how do you handle this situation when discourse is sending hundreds of emails in a short span and the SMTP server is rejecting the multiple logins for each email?

SMTP failure not reported and too many login attempts on backlog clearing

Product Support

pfaffman (Jay Pfaffman) 2. Juli 2019 um 02:27 20

Eine solche Einstellung gibt es. Suche nach „E-Mail deaktivieren".

Siehe auch Troubleshoot email on a new Discourse install - #362

Thema		Antworten	Aufrufe
Paid Job: looking for admin help Marketplace	6	1179	21. August 2019
Sidekiq queue too large - Google email provider problems Product Support	5	1474	29. Juni 2018
Mail test failure in discourse-doctor Product Support email	17	730	13. März 2025
Email not sending after update Self-hosting email	11	2239	10. November 2020
If local logins are disabled Product Support	29	1230	17. Juli 2026

SMTP failure not reported and too many login attempts on backlog clearing

Verwandte Themen