Currently the message is not expired . and could not be changed to bounce status.
iam trying below conf also . but not working as expected
`kumo.on(‘get_queue_config’, function(domain, tenant, campaign, routing_domain)
print (“enter get_queue_config”)
if domain == 'amqp' then
return kumo.make_queue_config {
max_age = '5 minutes',
retry_interval = '10 minutes',
max_retry_interval = '30 minutes',
protocol = {
custom_lua = {
constructor = 'make.amqp',
},
},
}
end
return kumo.make_queue_config {
max_age = '5 minutes',
retry_interval = '10 minutes',
max_retry_interval = '30 minutes'
}
end)`
I suggest you look at adopting the queue helper and hooks helper to simplify your code. See Example Server Policy - KumoMTA Docs and Configuring Queue Management - KumoMTA Docs
It will also make your install easier to support.
This is helpful. currently the message goes to expired status.One more help, how this message goes to bounce ? My expectation is,after 3 TransientFailure the message need to change bounce status
My expectation is,after 3 TransientFailure the message need to change bounce status . how to configure this ?
That is not supported.
ok
Technically “bounce after 3 transient fails” is not supported, but you can do something similar and approximate with math.
If you want the message to try 3 times in one hour and then bounce, you can set:
retry_interval = '20 minutes',
max_retry_interval = '20 minutes',
max_age = 60 minutes
Or if you don’t care how long it actually takes, but 3 tries is the requirement, then
retry_interval = '20 minutes',
max_age = 145 minutes
This is because the first delay will be 20 minutes, then next will be 40 and the next 80.
20+40+80 = 140 so after 3 retries, the max time will be hit and it will convert to a bounce.
Having said that, once it is in the queue, the time is set. if you want to clear what is already in the queue, you can intentionally bounce everything or send it all to dev/null with
msg:set_meta("queue","null")
return
but be warned, that will send all messages ( new and in queue) to be dropped without any recovery options.
This is helpful. Currently, I have the log type ‘Expiration’, but my expectation is to get the log type as ‘Bounce’ after a TransientFailure attempt. Is this possible?
That is exactly what happens. After the temp fails time out, the messages is permanently bounced
As expired.
But since we don’t know why it didn’t delivery before expiry, we don’t want to claim it as anything more concrete. Users look to the tempfail messages to understand why it expired.
Right, but it is a 5xx not a 4xx