Traffic Shaping not working?

Hey,
I’m currently struggeling with the Traffic Shaping setup and need some assistant.
I have 50 public ips on that servers, everything is in the common Tenant and run on kumod 2025.05.06-b29689af.
for mercedes i want only 1 delivery in one hour (for testing), but its not working at all.

My shaping file for testing:

[provider."mercedes"]
match=[{DomainSuffix="mercedes-benz.com"}, {DomainSuffix="mercedes-bank.com"}, {DomainSuffix="amg-mercedes.com"}, {DomainSuffix="mercedes-amg.com"}, {DomainSuffix="bkk-mercedes-benz.com"}, {DomainSuffix="mercedes-benz-bkk.de"}]
provider_max_message_rate = "1/h"
provider_connection_limit = 1
max_message_rate = "1/h"

output from resolve shaping domain:

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

kumomta output

I suggest you eliminate interference by removing '/opt/kumomta/share/policy-extras/shaping.toml' and '/opt/kumomta/share/community/shaping.toml' from init.lua, leaving only your own configuration. This is because kumomta reads them in order.

Did that already

And bases on the output my configuration gets applied

Or just put them first since they are on-order.

I am mobile so I may not be reading this correctly. Are you saying it is not working because you set the rate to 1/hr and you are seeing more than that?

In the image I think I see 2 deliveries from 2 different Sources 20 seconds apart.

This seems normal to me. If you want to rate to spam all the IPs in the pool then you may want to look at shared throttles.

It’s not really a typical use case because this is just for testing. Normally the throttle would apply to each source, but if you want all the sources to share one throttle you may want to look at this

Thanks Tom for your reply. Like you‘re saying, i see 2 deliveries within 20 sec from the same host and all the sending ips are on that one.

Do i get it right, that max_message_rate is only working per IP and not per host?

When I was trying to do that with max_message_rate 1 per min, it seamed to work, i saw directly that messages got delayed.

In my case , for rate limit , I use in shaping.toml

["gmail.com".sources."sourcename"]
max_message_rate = "1/min"
connection_limit = 1

And yes, shaping is always by egress_source, because that’s how the remote end sees incoming traffic. This is especially true when you consider that each egress_source can have its own EHLO hostname. The reality is that host does not exist as a concept to the remote MX, so there’s no use case for throttling by host in shaping.lua.

As always, that’s not to say users can’t implement things their own way outside shaping.lua, it remains a pre-built helper for common use cases and is not the only way to do things.

thank you :slightly_smiling_face: guess i know what to do :slightly_smiling_face: