One of the Professional Services we offer at Kumo Corp is config conversion from an existing system to KumoMTA. This helps people save engineering resources and gets customers to their goals faster. In one recent config conversion, we translated 890 lines of static configuration to 266 lines of Lua and provided it in a much easier-to-manage format. But we are all about open source, so we also want to make sure you can do it yourself if you want to.
In our documentation, we have tried to use as much descriptive language as possible to sync with what existing MTA users are familiar with. To be fair, there are only so many ways to make a variable name out of "Maximum Outbound Connections" and still have it obvious what the setting is for. All the same, we tried to make the configuration settings as obvious and as familiar as possible for those wanting to move from their current system to KumoMTA.
Take this example from a different MTA system describing a configuration named “my_vmta” that will have an IP address of 10.1.1.5 and an ehlo hostname of mymta.mycompany.com. With all domains, DKIM sign the messages before delivering.
<virtual-mta my_mta>
smtp-source-host 10.1.1.5 mymta.mycompany.com
<domain *>
dkim-sign yes
</domain>
</virtual-mta>
In the transition to KumoMTA configuration, these "virtual mta" settings (also called "bindings" or possibly a Postfix main.cf file) will mostly be described as an egress_source. Using the sample above, the KumoMTA version would look similar to this:
kumo.define_egress_source {
name = 'my_mta',
source_address = '10.1.1.5',
}
dkim_signer(msg)
Wherever possible, if it makes sense, we have tried to use similar, common-sense naming for variables.
| Original MTA | KumoMTA |
| ehlo_hostname or myhostname | ehlo_domain |
| bind_address or smtp_bind_address | source_address |
| virtual-mta or binding | egress_source |
| binding_group | egress_pool |
| Listener | esmtp_listener |
Another thing we did was to make all the obvious, common settings defaults. In the hundreds of MTA configs we have seen, there are certain things that everyone either does (or should do) on every MTA because it just makes sense to do it that way. Making them the default setting, saves you from having to manually add it to your config. For instance, SMTP transits on port 25 over the internet in the vast majority of cases - like 99% of the time. So why not just set that as the default and let mail ops engineers change it for special cases? We have set hundreds of safe defaults for time-outs, rotation periods, relay security settings, and metadata recording so you don't have to. We even went as far as automatically configuring Feedback Loop header configuration by default.
Finally, If you are looking to make a change in your MTA platform, I highly recommend exploring the helper documentation for KumoMTA. We have created helper modules to make migrating configs fairly straightforward. User MTA settings can all be saved in a single egress_sources file. Similarly, DKIM signing settings, outbound pools, and traffic shaping rules can all be neatly managed in specific helper files. All of which can be manipulated with the highly flexible Lua language.
If you want more hands-on help getting started, reach out and ask us about our professional services and support.