You are correct about DELIVERY_RETRY_WAIT being ignored. It could be implemented by changing line 33 of Mailman/Queue/RetryRunner.py from
SLEEPTIME = mm_cfg.minutes(15)
to
SLEEPTIME = mm_cfg.DELIVERY_RETRY_WAIT
however that doesn't explain why in your case the retries were continuous as they should be only once in 15 minutes.
> Is the code perhaps supposed to set a message's "deliver_after" to "time + DELIVERY_RETRY_WAIT" after a failure?
That would be another (and better) way to implement DELIVERY_RETRY_WAIT and may be the intent of deliver_after as it currently isn't set anywhere.
It would also avoid the possibility of too frequent retrying if somehow the time.sleep call is interrupted.
I have opened https://bugs.launchpad.net/mailman/+bug/1729472 for the issue of DELIVERY_RETRY_WAIT being ignored and I will fix that. I'm marking this "won't fix" as I don't intend to change the treatment of 552, at least for now.
You are correct about DELIVERY_RETRY_WAIT being ignored. It could be implemented by changing line 33 of Mailman/ Queue/RetryRunn er.py from
SLEEPTIME = mm_cfg.minutes(15)
to
SLEEPTIME = mm_cfg. DELIVERY_ RETRY_WAIT
however that doesn't explain why in your case the retries were continuous as they should be only once in 15 minutes.
> Is the code perhaps supposed to set a message's "deliver_after" to "time + DELIVERY_ RETRY_WAIT" after a failure?
That would be another (and better) way to implement DELIVERY_RETRY_WAIT and may be the intent of deliver_after as it currently isn't set anywhere.
It would also avoid the possibility of too frequent retrying if somehow the time.sleep call is interrupted.
I have opened https:/ /bugs.launchpad .net/mailman/ +bug/1729472 for the issue of DELIVERY_RETRY_WAIT being ignored and I will fix that. I'm marking this "won't fix" as I don't intend to change the treatment of 552, at least for now.