We’re currently evaluating KumoMTA as a potential replacement for PMTA in my company, and I’m exploring the feasibility of implementing certain mechanisms using Kumo. Specifically, we’re interested in dynamically rewriting the sender domain based on the egress source from which a message is routed, particularly when warming up certain source IPs.
Our approach would involve the following:
On a per-site, per-source basis, only X messages per day would be sent from a “cold” egress source.
Any additional messages would be routed through “warm” sources, with the sender domain being altered to a secondary domain in those cases.
I’ve successfully managed to rewrite the sender using set_sender/remove_all_named_headers/append_header just before DKIM signing at the end of smtp_server_message_received. I understand this is the only place where this modification can be applied.
However, the challenge I’m facing is that the decision to rewrite the sender domain needs to happen later in the process, depending on the pool/source selected. Is there a way to send messages back to the scheduled queue after hitting a source rate limit (e.g., max_message_rate from make_egress_path) so they can be rewritten and routed using a warm pool?
From the documentation, I gather that the only way to warm up IPs is by assigning them lower weights within the pool. Is there a way to exclusively use cold sources initially and switch to warm sources after the rate limit is reached, similar to PMTA’s max-cold-virtual-mta-msg behavior? :
The first X messages for each domain submitted to the warm VirtualMTA each day are automatically rerouted to the cold VirtualMTA.
Your help would be greatly appreciated! Thank you
Btw I’m loving the powerful flexibility kumo has to offer, it’s been so fun testing it out so far
In this case you’d need to create a warm pool and a cold pool and adjust which pool you assign to. There is no granular direct assignment of messages to specific egress_sources.
Are messages hitting an egress_source’s max_message_rate not automatically assigned another (fake warm) egress_source? That way this source could be configured to send the message back to kumo. This time doing the domain rewrite and using the real warm source?
Using PowerMTA, I can specify warm and cold VMTA in vmta pool
When I reach a certain amount of emails on the cold, the routing continues on the warm MTA. This is the same logic I’m trying to reproduce here.
I understand I can assign a “normal” max_message_rate for my warm source and a daily-limit max_message_rate for my cold source.
Will KumoMTA prioritize the cold MTA and switch to the warm MTA when it reaches the daily-limit of the cold one?
When it selects a source, does it check the source’s max_message_rate to avoid adding too many messages?
But when it happens, I would need to rewrite the FROM and that’s where I’m struggling, any advice for implementing the logic?
@proactive-okapi I would actually do this with redis and assign at the time of reception based on the Redis lookup.
so in smtp_server_message_received event, look up the pool you want to assign to in Redis and get a count. if it is not there, add it and incremenet the count. if it is there, check teh count against whatever threshold you want .
Based on that you can changed pools right there.
IE (Pseudocode):
If (redis_value > 5000) then
msg:set_meta(‘tenant’, ‘pool_cold’)
else
mesg:set_meta(‘tenant’,‘pool_warm’)
end
Hi Tom
I guess that would work, in this case we would just have to mimic the way kumo automatically rolls up messages into groups of domains with the same MX, so that the counter is scoped to a destination site.
Also that would scope it to a whole pool and not an individual egress_source, but I think it is negligible with a pool made of equal-weights egress_sources.
Thank you very much for your tips, I’ll try it out!
Have a great day
It’s one of our customer requirement. They don’t want to use their domain on huge volumes and want to switch to a “generic domain” that wouldn’t hurt their deliverability
For example 10k mail / day on a cold MTA with customer.com and then switch to customer.generic.com for the rest of the traffic
