Today we're pleased to announce that KumoMTA is out of beta a full two months early!!
Development on KumoMTA started in February 2023 and progress has been swift. After two public betas with few critical issues identified, we're pleased to announce that we're removing the Beta flag from our latest release and calling our latest release GA.
This release was delayed by a couple of weeks in part because of our other exciting announcement: our first production installation. One of our supporters has successfully deployed KumoMTA into a production-sending environment and provided invaluable feedback which we wanted to incorporate into this release, and we are happy to report there is now production traffic being sent continuously via a KumoMTA install.
Our new release is available now for installation, instructions on installing KumoMTA can be found in our User Guide. Read on to learn more about the new features added, and what we're working on in our next release.
Note: while this marks our first non-beta release, we still appreciate all testers who stay on the -dev branch releases in order to help test the new features we continue to introduce.
Our latest release includes several new features, the most notable are listed below, for all changes see the changelog:
In our previous release we introduced support for HAProxy, helping address the need of cloud senders to distribute their sending IP infrastructure across multiple proxy nodes, often needed by users of public cloud platforms due to limitations on the number of IP addresses that can be attached to each virtual machine. Rather than managing many MTA nodes, deploying a smaller set of MTA nodes that use a larger pool of proxy nodes to route outbound traffic over the sender's IP space is simpler.
We started with HAProxy because most commercial MTA solutions support it. We wanted it to be easy to migrate those users to KumoMTA, but in the process, we learned that HAProxy is a poor fit for large-scale email senders due to its target use case being inbound proxying. HAProxy is typically used to proxy incoming connections from external hosts, so it does not provide error information back to the connecting host, meaning that when an MTA uses HAProxy for outbound proxy, and something goes wrong, the connection simply times out without any context. This lack of critical information means that admins won't know if the proxy couldn't secure the correct outbound IP or that the proxy couldn't connect to the remote MTA (or that the remote MTA closed the connection without any communication).
SOCKS5 is a protocol that supports outbound proxying so that when a SOCKS5 proxy is used for relaying the MTA gets actionable information when errors occur rather than indecipherable timeouts. While KumoMTA will work with any SOCKS5 proxy server, we have developed one for use with KumoMTA. We recommend SOCKS5 proxy over HAProxy for all users that are not migrating to an existing HAProxy environment and even then recommend moving to SOCKS5 during or after migration. Read more about proxy configuration in the user guide.
Modern scalable architectures are built on new methods for delivering event data, no longer relying on local plaintext logs that get copied or consumed for delivery to analytics systems, and instead using service-based approaches such as webhooks and AMQP. Our Beta 2 release brought webhook support into KumoMTA, and our June release adds AMQP support.
Our AMQP implementation is built on the same architecture we developed for webhooks, leveraging our high-performance queueing system for storing events prior to delivery, ensuring that no events are lost in the event that the server cannot reach your AMQP architecture.
For more information on configuring AMQP publishing of events using RabbitMQ, see our AMQP documentation in the User Guide.
As we have architected KumoMTA, our first priority has always been to ensure that the platform is as flexible as possible to give administrators the ability to customize their KumoMTA installation to work with this environment and use cases, but flexibility can come with decreased simplicity.
To help new users get started with KumoMTA, we've introduced helpers, specialized scripts that can be incorporated into your installation to implement common use cases in a standardized way. These helpers enable you to record your desired configuration into a TOML or JSON file, with those settings implemented automatically by the helper.
As of this release, the following helpers are available:
Our next release is focused on deliverability automation. One of the most sought-after solutions we've heard from our community revolves around the need for the MTA to identify when a remote host is telling their server what to do, and act on that request in real-time.
The Mailbox Providers generally do a good job of providing direction in the responses their servers provide to incoming hosts, but it's untenable to expect an admin to be watching the responses to make manual adjustments to their server's behavior based on those responses; there would be too much latency and a high risk that the MBP's servers would interpret any delay in following their directives as poor practices on the part of the sender, impacting sending reputation.
With this release, we'll implement the tools for a cluster of sending MTAs to collectively identify feedback and act on it in near-real time to ensure that the instructions of the receiving MTAs are respected and followed.