I’m looking for guidance on handling queue priority for transactional mailers in KumoMTA.
We send both bulk/marketing and transactional (OTPs, password resets, order confirmations, alerts, etc.) from the same instance. From what I’ve read in the docs and the blog post about the priority flag, KumoMTA doesn’t have a traditional priority flag and instead relies on separate scheduled queues (via campaign / tenant / domain) to keep transactional traffic from getting stuck behind large bulk queues.
A few questions:
On what basics how can we implement the queue priority for transactional mailers?
Any tips or config patterns to use specifically for transactional (retry intervals, max_age, shaping, etc.)?
In which toml/lua file do we need to configure/implement the queue priority.
Would really appreciate any real-world experience or recommended setups. Thanks!
For this, you may want to re-read that blog. There is no priority flag to set. It is not needed. If you truly do not want transactional messages to wait 3 milliseconds, you can give them a unique campaign id or use a separate pool for transactional.
Just curious to know how kumo-mta identifies whether the incoming volume is transactional or promotional for a particular tenant, even though we provide a dedicated pool for transactional emails and without passing/providing a unique campaign ID.
It does not, to KumoMTA an email is an email until you impose your own logic on the process, because it splits down to a very granular queue hierarchy naturally, most don’t need to add specific logic to identify transactional mail, such as where you’re using a dedicated pool for it.
In a pool each pathway is its own queue, so each destination gets a separate queue for each sending IP.