Defect #31939
closed
Emails are dropped after timeout
0%
Description
Redmine 4.0.x uses ActiveMailer to send emails asynchronously. In my configuration, I am also using ActiveJob::QueueAdapters::AsyncAdapter.
On my server, I am facing the odd situation that, when notifying the projects users, the initial emails are rendered and sent within about 100ms. However, after 8-10 emails, ActiveJob reports a series of email delivery problems because the execution has expired (after 30sec each). Unfortunately, I am not able to figure out (a) what causes the timeout (the Redmine server or the Mail server?) and (b) how to modify the 30sec timeout value.
In any case, it would be very helpful if Redmine didn't drop emails that cannot be delivered instantly but instead makes a retry after a certain period of time. (Imagine that a mail server may be offline temporarily!)
Does anyone have an idea on how to implement such a "retry-after-x-seconds" approach? Thanks in advance!
Updated by Michael Gerz about 4 years ago
- Status changed from New to Resolved
Our mail server considered the quick sending of hundreds of email as a DoS attack.
Adding a local MTA solved the problem.
=> closing ticket
Updated by Go MAEDA about 4 years ago
- Status changed from Resolved to Closed
- Resolution set to Invalid
Thank you for your feedback. Closing.
Updated by Hendrik Jaeger 2 months ago
Michael Gerz wrote:
In any case, it would be very helpful if Redmine didn't drop emails that cannot be delivered instantly but instead makes a retry after a certain period of time. (Imagine that a mail server may be offline temporarily!)
Does anyone have an idea on how to implement such a "retry-after-x-seconds" approach? Thanks in advance!
This part is not adressed at all and since I’m experiencing the same problem of mails just being dropped and not retried, see #41515, I’d like to ask to reopen this ticket to address this as it’s really bad for most workflows when such mails are just dropped.
Thanks for your consideration!
Updated by Holger Just 2 months ago
We generally advise to use a persistent job queue rather than the default ActiveJob::QueueAdapters::AsyncAdapter such as Sidekiq, DelayedJob or others. These persistent job queues will generally retry failed jobs a number of times.