You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Currently, once an message is deferred it will be retried until the message is sent. However, some messages will never be sent. In my specific case there was an error from the mail server (451, with the reason: Recipient on suppression list).
Describe the solution you'd like
I'd like there to be a way to limit the amount of retries for a specific message. I looked into MAILER_EMAIL_MAX_DEFERRED, but that limits the amount of deferred messages to send. Having a retry counter on the message object and a setting that deletes the message once a threshold is reached, instead of retrying, could be a solution.
Describe alternatives you've considered
Manual intervention is the only alternative I have right now. I.e. deleting the message after a number of failures. But that means someone has to monitor the messages/logs.
The text was updated successfully, but these errors were encountered:
This seems like a reasonable feature request. I won't be working on it myself, but I'd be willing to review a PR for it. Usual things apply - documentation and tests would be required. Thanks!
jaap3
added a commit
to jaap3/django-mailer
that referenced
this issue
May 25, 2023
Is your feature request related to a problem? Please describe.
Currently, once an message is deferred it will be retried until the message is sent. However, some messages will never be sent. In my specific case there was an error from the mail server (
451
, with the reason: Recipient on suppression list).Describe the solution you'd like
I'd like there to be a way to limit the amount of retries for a specific message. I looked into
MAILER_EMAIL_MAX_DEFERRED
, but that limits the amount of deferred messages to send. Having a retry counter on the message object and a setting that deletes the message once a threshold is reached, instead of retrying, could be a solution.Describe alternatives you've considered
Manual intervention is the only alternative I have right now. I.e. deleting the message after a number of failures. But that means someone has to monitor the messages/logs.
The text was updated successfully, but these errors were encountered: