Introduction
I was recently watching a live stream of the excellent Deliverability Summit conference in Prague and was particularly interested in the responses to an audience question during a panel on operating your own on-prem email infrastructure regarding the differences between commercial MTAs vs. Open-Source MTAs.
The panel spoke about how Open-Source MTAs such as Postfix, SendMail, Exim, Qmail, and Haraka had several shortcomings that made them a poor fit for the work of sending email in large-scale environments such as single-sender organizations with large a userbase, and multi-tenant senders such as Email Service Providers (ESPs).
Here at KumoMTA, we agree with their critiques, they are the reasons we created KumoMTA in the first place: to bring a viable Open-Source MTA option to the community that meets the needs of large-scale senders.
In this article, we will outline the common challenges faced when using Open-Source MTAs for large-scale sending environments, and how KumoMTA changes the email infrastructure landscape.
Common Challenges of Open-Source MTAs
In answering the question, the panel listed off some of the common challenges faced when using an Open-Source MTA in a large-scale sending environment:
Open-Source MTAs are Built for Receiving
The first comment is that Open-Source MTA servers are built for receiving and intended for processing incoming traffic before it is passed to a mailbox server (Message Delivery Agent or MDA). While very good at processing incoming emails, commercial MTAs are designed and optimized for sending. Commercial MTAs are better at using multiple IPs and improving deliverability by implementing the latest standards such as DKIM, DANE, and MTA-STS.
Open-Source MTAs are not Built to Scale
Unlike Open-Source MTAs, commercial MTAs are designed around using a lightweight threading model in order to open tens of thousands of connections simultaneously. This allows for higher performance and scalability.
Open-Source MTAs are not Designed Around Integration
Developers expect modern integration around APIs and SDKs, and are not experts at email RFCs, MIME formatting, etc. Without APIs the user has to have more expertise.
We actually agree with everything that was said during the panel, and from our experience, there are additional concerns that have to be addressed:
Open-Source MTAs Have Poor Queue Management
Related to the concern that Open-Source MTAs are designed for receiving, not sending, is the concept of queue management. When all an MTA has to do is receive mail from the outside world and relay it to an internal Message Delivery Agent (MDA), it does not need a sophisticated queue management system: while a queue is necessary to satisfy the needs for the MTA to store-and-forward messages, the expectation is that messages will only have to be queued in case the MDA is unavailable, and there is only one (or a handful) of potential destinations. A simple queue is sufficient, and messages can easily be handled in a FIFO manner server-wide.
When a receiving MTA is used in a sending environment, the shortcomings of its queue management system are quickly exposed: suddenly instead of a single host to relay to, the Open-Source MTA has to relay to tens of thousands of destination hosts and domains, with each having its own policies and practices around throttling, greylisting, and bouncing. Instead of queues only needed when the host is down, the Mailbox Provider (MBP) may intentionally return temporary failures to slow down a sender, resulting in millions of messages being deferred and filling the queues.
Open-Source MTAs Lack Support Options
Large-scale senders, whether a single sender with many users or an Email Service Provider (ESP) have email at the core of their business. The messages they send drive engagement and a sizable portion (if not 100%) of their revenue, and a bug in their MTA of choice can spell disaster and lost revenue.
Commercial MTA vendors provide support that is often guaranteed by a Service Level Agreement (SLA). When something goes wrong users can connect directly with the vendor via chat, email, phone, or support portal and get the help they need to resume sending, even if the vendor has to issue an emergency patch to get the software working again.
While some Open Source projects have commercial support, the other concerns already listed still apply: for example: while there are commercial support options for Sendmail, it still remains an MTA designed for receiving, not sending. A support agreement will not change what an MTA was built for.
KumoMTA is a Different Open-Source MTA
The shortcoming of existing Open-Source MTAs and the growing issues with Commercial MTAs are the reasons why we created KumoMTA. After over a decade of working in commercial MTA infrastructure we knew that there was a gap in what Open-Source had to offer, and it was a solution focused on the needs of large-scale senders.
KumoMTA is the world's first Open-Source MTA architected from the ground up for the needs of large-scale senders. We designed our technology around those senders' key needs for scalability, flexibility, and deliverability.
By building a brand-new MTA using Rust, we were able to leverage our experience in building, scaling, and supporting a commercial MTA to create a new Open-Source solution designed specifically for large-scale sending environments, without the tech debt that accumulates over the years of supporting now-defunct standards, with the queue management, flexibility, multi-tenant support, and scalability needed by modern large-scale senders.
We knew we needed to introduce a solution that was safe to adopt thanks to its Open-Source license model; large-scale senders will never be trapped by their license, forced to pay their vendor year-over-year, or risk losing their sending infrastructure, instead our relationships are based on mutual support: when they succeed, we succeed.
Finally, we formed Kumo Corp, through which we provide our users with the SLA-protected support they need to ensure their mission-critical email infrastructure is safe to depend on, standing behind our users to help any time we are needed to ensure their platforms are stable and get the enhancements they need.
Summary
The existing pool of Open-Source MTA options has never properly served the needs of large-scale senders, resulting in most either choosing a commercial MTA solution or building their own. The landscape has changed as we introduce KumoMTA, the first Open-Source MTA architected from the ground up for the needs of large-scale senders, with the commercial-grade SLA-backed support needed to help large-scale senders succeed and grow their businesses. Learn more About Us and Contact Us to learn how you can incorporate this high-performance Open-Source solution into your sending environment.