Hello!
I’ve been looking into the requeue_message event to see if it is possible to set the retry interval on a transient failure on a per-message basis. Sadly, I don’t think it will work according to the docs unless I change the queue it is sitting on (which I don’t think I want in this case).
Is something like this theoratically possible with an event?
Thanks!
What is your use case?
There are certain providers that return a dynamic value for e.g. greylists. For transactional mail I was tinkering with the idea of parsing the smtp response > requeuing with the provided delay in the response (with some jitter)
especially if the set default retry interval is ~5 minutes, but the provider returns “retry in 60 seconds” or (I’ve seen this one before):
retry in 900 seconds > we retry too soon > retry in 593 seconds
Can you get me some samples of a provider giving different retry intervals? I’ll work on a ticket for it.
It’s a provider using SmarterMail: http://internetmailserver.net/
I meant some sample 4xx responses.
Ah, sorry 
451 Greylisted, please try again in 900 seconds
451 Greylisted, please try again in 593 seconds
450 4.2.1 <REDACTED@REDACTED.com>: Recipient address rejected: Domain REDACTED.com greylisted. Please try again in 60 seconds.
451 4.7.1 <REDACTED@REDACTED.fi>: Recipient address rejected: Greylisted for 1 minutes
these are some quick examples I could find
Ok, and in the interim you just set the retry high?
Yep, depends on the MBP, but default is 5 minutes
and that exponentially backs off of course
Ok, retry for now is a queue level attribute, so per-message isn’t really something that can be done, but I’ll open a ticket for it so we can review.
Ahh, so my understanding of requeue_message might work if I dynamically create a queue in there ad hoc, basically? (though I suppose that might harm performance, but theoratically speaking)
Yes, you could in theory build a queue for that retry period, but you will want to ensure it has a unique identifier. If you build a queue with the same name as the existing one the outcome will be unpredictable.
And yes, performance impact on that approach is untested.
Interesting. My idea behind it was: as long as there’s a time indication in the response > ignore queue retry_interval and do not back off either > no time in the response (anymore)? > fallback to queue retry_interval and continue back off where it left off based on the number of attempts
It was just a quick idea that I played around with, it isn’t really a priority, but if I feel like it soon, I will see if I can play around with the source a bit more, who knows.