KumoCorp/kumomta

Pool Assignment Re-Evaluation

Closed this issue · 3 comments

If egress pool assignment doesn't work, users will assign to a suspended default, and they will need to command the MTA to re-assign the message to a new egress pool.

wez commented

At a fundamental level, the operation required here is:

  • For each message in a matching scheduled queue
    • Remove from the containing queue
    • Update queue-related meta items such as tenant, campaign and queue
    • Re-insert the updated message into the queue system

There are a couple of approaches to implement the interface for this; for each of these there will a set of parameters similar to those in the bounce and suspend APIs that will be used to select matching queues.

I'm unsure about whether we should do just one of these or all of them.

  1. An API call that can specify fixed, hard-coded values for meta items, that will be used to unconditionally assign those meta items on each matching message. That might be exposed via something like: kcli rebind --domain foo.com --set queue=smarthost.com
  2. An API call that can be used to pass data to an event handler defined in the configuration that can use logic to decide what to do to each message.
kumo.on('rebind_message', function(msg, data)
   if something then
     msg:set_meta('queue', data.queue)
   end
end)

and via the cli:

$ kcli rebind --trigger-rebind-event --domain foo.com --data '{"queue": "smarthost.com"}'

3. Similar to 2., but instead of using an event handler that is pre-defined in the config on the running node, the handler could be passed in as a lua code fragment. This is honestly a bit scary as it is literally remote code execution, but in all three of these cases, these operations would be restricted to trusted admin IPs per the http listener

$ kcli rebind-eval --domain foo.com --data '{"queue": "smarthost.com"}' --lua '\
function(msg, data)
   if something then
     msg:set_meta('queue', data.queue)
   end
end'
wez commented

It's worth pointing out that rebind doesn't really directly assign a pool, it just re-evaluates the scheduled queue, which in turn implies a change in egress pool

wez commented

kcli rebind docs are now in the reference manual