Shaping automation rules not triggered

KumoMTA Traffic Shaping
1

Hi!

It’s the first time since using KumoMTA that we really had this issue (yay) and I noticed that even though we see:
451 4.7.650 The mail server [xxx.xxx.xxx.xxx] has been temporarily rate limited due to IP reputation. For e-mail delivery information, see https://postmaster.live.com (S775) [Name=Protocol Filter Agent][AGT=PFA][MxId=11BC10417C2F6E38] [CY4PEPF0000EE33.namprd05.prod.outlook.com 2025-10-16T06:53:08.888Z 08DE0820C2F6DCE2]

it keeps trying to send it via this IP. It feels like it’s not really suspending it.

For example, the shaping rule looks like this:

[provider."outlook"]
match=[{MXSuffix=".olc.protection.outlook.com"}]
max_deliveries_per_connection = 50
provider_connection_limit = 2

[[provider."outlook".automation]]
regex = "The mail server.*has been temporarily rate limited"
trigger = {Threshold="1/hr"}
action = "Suspend"
duration = "30m"

When checking resolve-shaping-domain:

{
  "connect_timeout": "1m",
  "openssl_cipher_suites": null,
  "idle_timeout": "1m",
  "ehlo_domain": null,
  "provider_name": "outlook",
  "aggressive_connection_opening": false,
  "max_deliveries_per_connection": 50,
  "reconnect_strategy": "ConnectNextHost",
  "additional_message_rate_throttles": {},
  "try_next_host_on_transport_error": true,
  "ignore_8bit_checks": false,
  "tls_certificate": null,
  "mail_from_timeout": "5m",
  "readyq_pool_name": null,
  "consecutive_connection_failures_before_delay": 10,
  "auth_timeout": "1m",
  "low_memory_reduction_policy": "ShrinkDataAndMeta",
  "remember_broken_tls": "3days",
  "enable_rset": true,
  "rset_timeout": "5s",
  "connection_limit": {
    "limit": 2,
    "force_local": false
  },
  "smtp_auth_plain_username": null,
  "additional_connection_limits": {
    "shaping-provider-outlook-unspecified-limit": {
      "limit": 2,
      "force_local": false
    }
  },
  "openssl_cipher_list": null,
  "additional_source_selection_rates": {},
  "enable_mta_sts": true,
  "data_timeout": "30s",
  "prohibited_hosts": [
    "127.0.0.0/8",
    "::1"
  ],
  "tls_prefer_openssl": false,
  "enable_pipelining": true,
  "smtp_auth_plain_password": null,
  "rcpt_to_timeout": "5m",
  "max_message_rate": "100/s",
  "tls_private_key": null,
  "smtp_port": 25,
  "dispatcher_wakeup_strategy": "Aggressive",
  "refresh_interval": "1m",
  "enable_tls": "OpportunisticInsecure",
  "allow_smtp_auth_plain_without_tls": false,
  "skip_hosts": [
    "::/0"
  ],
  "refresh_strategy": "Epoch",
  "enable_dane": false,
  "max_connection_rate": "100/m",
  "source_selection_rate": null,
  "ehlo_timeout": "5m",
  "system_shutdown_timeout": null,
  "banner_timeout": "1m",
  "max_ready": 1024,
  "use_lmtp": false,
  "data_dot_timeout": "1m",
  "opportunistic_tls_reconnect_on_failed_handshake": true,
  "starttls_timeout": "5s",
  "maintainer_wakeup_strategy": "Aggressive",
  "no_memory_reduction_policy": "ShrinkDataAndMeta"
}

Not sure if I’m missing something. Appreciate the help!

3

Upon further checking, they’re indeed not published:

# Generated by tsa-daemon
# Number of entries: 0



# Generated by tsa-daemon
# Number of entries: 0```
4

Provide only one troubleshooting method:
Check whether Kumomta has passed the events to tsa.

kcli provider-summary --by-pool --limit 30 | grep 'http://xxxxxx:xxxx.tsa.kumomta'

PS: “xxxxxx” represents your deployment architecture. You can verify it by removing the grep command.

5

Ah.. ouch. Those are all failing:

http://kumomta-tsa-0.kumomta-tsa-headless.kumomta.svc.cluster.local:8008.tsa.kumomta unspecified       0 1,871 0 0 454```
6

hah, as always: it’s DNS.

7

All back up and running, thanks for pointing me in this direction. Forgot about provider-summary. Thanks Jack :grinning_face_with_smiling_eyes: