Queue Management Scopes - Provider Support & Current Use Cases

[MHillyer]

KumoMTA's Queue helper currently supports scoping queues by destination domain.

As with traffic shaping in the shaping helper, certain destination domains roll up into larger providers. A major example of this is Google Workspace and Microsoft365.

As an example, kumomta.com is hosted by Google Workspace and would not be configured for queue configs, but those configs would instead be expected at the provider level.

Currently make_queue_config has the following available attributes that are likely candidates for specifying in relation to a given provider:

• egress_pool
• max_age
• max_message_rate
• max_retry_interval
• protocol
• retry_interval

Questions to answer:

• Which of these are regularly configured with regards to destination domain, let alone destination provider?
• What are the scopes used typically in production that should be applied, and in what order of precedence?
  • Examples of scopes seen used include default, domain, tenant, tenant-domain, tenant-campaign
• What are users currently doing to work around the lack of provider support?
• Are there scopes that are being introduced by users or used to workaround scopes that are not currently available.

[MHillyer]

This is all in the context of a larger "Lua vs Helper" conversation: the helpers were never intended to be all and end all, just a way to introduce the most common use cases which a user could then fork the helper and maintain their own with their logic, or use the helper but then add some Lua after it runs to further manipulate things, or could forego the helper entirely and write their own Lua.

It turns out most users are sticking to the helpers, so now the question becomes whether the helpers are truly handling all the common use cases. We don't really want to shift to maintaining specific user use-cases in the helpers as it makes them more complicated, which makes it harder for users to fork and adopt, and it increases the maintenance footprint.

Where we see people doing workaround we do want to see how common those are. I know we've seen more than one org map the campaign field to represent sending domains or which pool to use when a given tenant has access to more than one pool, so what are the use cases everyone is seeing where they are somehow working around the current architecture of the helpers?

[jessehanley]

Our main use case as an ESP is MX-provider shaping which is handled by our app before MTA injection, and when we tinker with it it's typically in response to an incident or something we notice in our monitoring software (i.e alert that we have excessive deferrals from Yahoo, pull back/re-route traffic to another IP) or we just naturally let things retry based on safe defaults. It's very rare we touch the MTA traffic shaping after warm-up.

It's mostly the big three — google.com, msn.com, yahoo.com — that we're tinkering with during warm-up too. Very, very rarely do domain-specific shaping if ever.

[MHillyer]

Can you share more on how you do the shaping before MTA injection? Generally I'd consider shaping to be something done by the MTA so you've got me curious.

…

On Fri, Feb 13, 2026 at 1:11 AM Jesse Thomas Hanley < ***@***.***> wrote: *jessehanley* left a comment (KumoCorp/kumomta#479) <#479 (comment)> Our main use case as an ESP is MX-provider shaping which is handled by our app before MTA injection, and when we tinker with it it's typically in response to an incident or something we notice in our monitoring software (i.e alert that we have excessive deferrals from Yahoo, pull back/re-route traffic to another IP) or we just naturally let things retry based on safe defaults. It's very rare we touch the MTA traffic shaping after warm-up. It's mostly the big three — google.com, msn.com, yahoo.com — that we're tinkering with during warm-up too. Very, very rarely do domain-specific shaping if ever. — Reply to this email directly, view it on GitHub <#479 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC4KGZ36XHBOSTMFGJFRTIL4LVTIRAVCNFSM6AAAAACUYHSJ22VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTQOJVGEYDSNBWGA> . You are receiving this because you authored the thread.Message ID: ***@***.***>