Looking to implement rerouting logic based on a specific SMTP reply pattern. Something like PowerMTA’s reroute-to-virtual-mta / backoff-reroute-to-virtual-mta directives. SetConfig action seems to support only egress path configuration variables, or am I missing something?
Hey there @nourishing-urial, thanks for posting. Please read the “Troubleshooting” and “How to Ask for Help” buttons below. If you would like a 1:1 support session from the KumoMTA team, details are at the “Book a Support Session” button below.
Kcli has a “rebind” function that is relatively new. Try this :
You may need to upgrade to the latest version first.
Or in-line, requeue may be a better option:
I saw that, and we are testing the latest -dev build. If it would be possible to trigger rebind using TSA, that would do the job.
Yeah I thought so too, but there’s no way to access the SMTP reply that triggered the message_requeued event
It would be awesome if TSA had a RequeueMessage action
then it would be possible to create rules like:
if smtp_reply.matches(ratelimit_regex) then
..requeue message to another pool..
else if smtp_reply.matches(spammycontent_regex)
.. suspend tenant ..
end
etc
The way to do this is to use requeue_message - KumoMTA Docs and rebind the message in that event handler, using whatever combination of setting the routing_domain or queue metadata is appropriate. You have to assign the message to a scheduled queue that has a different egress pool, as the pool assignment is queue-based, not message-based.
Is it possible to add a meta field to message that would contain the last SMTP error that caused it to be requeued?
we could then use something like msg:get_meta(‘last_error’)
to check whether it needs to be requeued to some other queue or not
however, having functionality in TSA would be “cleaner” IMHO, as all the SMTP reply matching would be in one place
and something like Action=TriggerEvent{name=“handle-smtp-delay”} would allow to create any kind of scenario
then someone could create a lua event handler and write any custom code there
re: TSA, that operates on a separate, asynchronous stream of log records, being sent to multiple replicas, and not synchronously blocking on messages, so TSA cannot directly operate in this fashion.
gotcha
I can add that to KumoMTA source if you’re open to it?