TSA - Implement PowerMTA alike backoff behavior

Hi , quick TSA sanity check.

Migrating from PMTA and replacing with TSA automation in shaping.toml.

**Setup:
**
Multiple IPs per pool
Using policy-extras.shaping
MX rollup enabled (default)
Large regex list (~150 patterns) matching rate limits / greylisting / temp blocks

When a regex matches, I apply:

SetConfig max_message_rate = “5/h”
SetConfig connection_limit = 1
duration = “30 minutes”
trigger = “Immediate”

**Questions:
**

  • Is TSA + SetConfig the correct architectural replacement for PMTA backoff patterns?
  • Does this apply per (egress_source, site_name) (so effectively per IP per MX site)?
  • Any concern with performance having ~150 regex patterns in one automation block?

Just want to confirm this is the most Kumo-native approach before deploying broadly.

Thanks :folded_hands:

I personally can’t speak to PMTA, but for your other questions:

Does this apply per (egress_source, site_name) (so effectively per IP per MX site)?

Yes, the threshold and the configuration it applies are scoped to the combination of source + site_name

Any concern with performance having ~150 regex patterns in one automation block?

Probably. Each individual regex is checked sequentially, so if you have 150 regexes then each log record will have 150 regexes evaluated against it.

Whether that is good or not depends on how many bounces and transient failures are generated by your workload and how expensive each of the regexes are. That CPU cost of that matching is paid for both on the MTA node where the event occurred (as part of pre-filtering which cuts down on bandwidth to TSA) and on each of the TSA nodes where the decision making occurs.

You may want to consider consolidating the regexes into a smaller subset that uses alternations and good use of anchoring. So rather than:

regex = ["foo", "bar", "baz"]

do:

regex = "(foo|bar|baz)"

that will allow the regex engine to compile a more effective state machine for matching those inputs overall.