KumoMTA cluster and Traffic Shaping question

KumoMTA Cluster
1

As part of R&D test

I’ve created a cluster configuration with TSA following the **Multiple Node **documentation Deployment Architecture - KumoMTA Docs
in addition I have four kumo-proxy socks5 instances and everything works as expected ( outbound connections / limits / etc )

Now, I’d like to get rid of the TSA.

So, I have removed the TSA config, shut down the kumo-tsa-deamo, keep Redis for throttling between the two Kumo nodes, and include shaping as follows

kumo.on('get_egress_path_config',
  shaping:setup {
    '/opt/kumomta/share/policy-extras/shaping.toml',
    '/opt/kumomta/etc/policy/shaping.toml',
    '/opt/kumomta/etc/policy/shaping_custom.toml',
  }
)

-- in kumo.on('init')
kumo.configure_redis_throttles {
  node = 'redis://user:key@mta-redis-endpoint:PORT/',
  cluster = true
}

And again, everything works as expected ( outbound connections / limits / etc ) :+1:

Is there any aspect I might be overlooking that could compromise something?

I’m asking because I noticed this in the sample config:

-- Commented out by default since we recommend using the Traffic Shaping Automation

but maybe you’re only referring to better deliverability management (?) not at operational level

3

You did something that I always wanted to do but didn’t dare to do. LOL, don’t you really want to use TSA to guarantee the successful delivery of the mail? :laughing:

4

You should be fine. We recommend TSA, but it is not required. Much like other Automated Delivery throttle mechanisms you have used in the past. The one thing people tend to miss when disabling TSA is the line inside the init section.

5

shaper.setup_publish()

6

“As part of R&D test” :wink: Deliverability is out of scope in my test scenario

7

Basically undo this

8

:+1: Yes, actually as I mentioned in my post, I’ve already done everything and it’s working correctly. I just wanted to make sure I’m not missing anything important from an operational point of view.

9

You are golden