Hello everyone. I will state my question based on our usage scenario. We need to serve many customers, even hundreds of them. After the customers have configured the domain name resolution, we need to configure the email-related settings for them. When using Kumo, which parts need to be modified? Let me first talk about my understanding. Since I am new to Kumo (I have only been looking at the configuration for two days), please correct me if there are any mistakes in what I say.
1.I need to add kumo.start_esmtp_listener for each customer, where hostname = ‘edmxxx.customerdomain.com’.
2.Add the configuration of this customer in sources.toml.
3.Add the configuration of this customer in dkim_data.toml.
4.Add the support for this customer in queues.toml. Are there any other things?
I am thinking that I might develop a GUI in the future to simplify the configuration for administrators.
In addition, a simple configuration question. If I modify the *.toml files, do I need to restart the kumo service every time for the changes to take effect? Or how long do I need to wait for the changes to take effect? According to my tests, the changes do not take effect immediately. In order to test the effects as soon as possible, I restart kumo every time. I am currently preparing to replace Momentum (PowerBy Message System) with kumomta. I need to sort out the complete replacement process and the subsequent progress. Thank you.
kumod 2025.01.29-833f82a8
Momentum is a big part of my history.
Listeners are for incoming messages, most ESPs don’t set up listeners per customer.
Configuration is cached by five minutes as a default, you can wait or restart but restart is not required.
DKIM_data may not need a change if you have paths configured and place the key file accordingly.
Hi Mike , thanks for response . Yes . we will support 2 domain for our customer . So Listeners will config 2 hostname.
Your customers will inject to unique, or is this for bounces?
You have listeners per customer in Momentum?
Our customers manage contacts and email materials on one of our automated platforms. Our automated platform will send the data to be sent to Momentum for sending. We will allocate “channels” for each customer, that is, resources such as IP pools. We do not configure each listener for each customer. (I am not an email administrator. I have just started learning knowledge related to emails.)
Yeah so you probably won’t need a listener for every customer.
Did you read the Momentum migration article?
I plan to go through all the documents of kumomta this week. During the process of reviewing the documents in the previous two days, I found that this is a very good product. I will strongly recommend it to our boss and plan to complete the replacement this year. To be honest, momentum was introduced around 2015. At that time, I didn’t know why we should use momentum. I also need to compare the configuration differences between KumoMTA and momentum to provide more persuasive evidence.
2015? I may have been involved.
Yes, I have already read this document. It is very persuasive. However, we have also done a lot of additional development based on momentum. Based on momentum, we have done monitoring, the GUI for channel configuration, and our support staff are already used to configuring momentum. Therefore, I need to sort out the differences as detailed as possible so that it is convenient to quickly switch to KumoMTA.
That makes sense. In 2015 I ran the global sales engineer team. Odds are I or one of my team helped set it up the first time.
We currently have hundreds of IP addresses as an IP pool. If we directly use some of the IPs for Kumomta to send, is it possible that we can shorten or even skip the warm-up process?
You could move the IPs to HA Proxy which Momentum recent releases support and so do we, then both systems can use the IPs without any warmup.
Maybe you’ve heard of Webpower. Currently, it’s called Spotler