Postfix is probably the most recognizable and most accessible email engine available. That does not mean it is the best solution for your complex, high-volume email needs. We will discuss here why moving to KumoMTA might be a good solution as a postfix replacement.
In the beginning....
Way back near the beginning of Unix time itself, there was the original sendmail tool in 1983 that launched a whole new universe of communication possibilities. Sendmail was revolutionary at the time, but it was not particularly easy to manage nor was it particularly speedy at processing messages. In 1998, Postfix was launched as a potential solution to those drawbacks and introduced faster processing, a more modular configuration, and more efficient queue management. It became so popular that by the early 2000's it was packaged by default in most Linux distributions. If you were a developer at the beginning of the 21st century (2001-2010), and you needed to incorporate email sending, Postfix was, as they say, a "no-brainer".
Around that time, many email service providers were growing in volume and complexity, so a natural outcome was the development of large Postfix farms operated by Email Service Providers (ESPs) who could provide email services to the masses. In some cases, this meant thousands of Postfix instances coordinated by complex scripts, all funnelling data through another set of complex reporting systems, and managed by an emerging new engineering discipline, MailOps engineers. Today's brands each need separate mailing streams for alerts, marketing, and growth, each with its own pools of IPs. An ESP with hundreds of brands to manage, reporting on thousands of IP addresses, would need to set up many separate Postfix instances and manage them carefully to ensure one brand's mail does not affect another's sending reputation. While this technically works, it is overly complicated, fragile, and error-prone - there has to be a better way.
That was then; This is now.
KumoMTA was built as an open-source solution from the ground up to provide effective tools for mailops engineers who manage large-scale systems like the ones ESPs use to send billions of messages for thousands of customers every day. We looked at the core problems mailops engineers face in scaling, observability, and tuning flexibility, particularly as it pertains to managing many different sending streams for a variety of customers. In the email world, this is known as multi-tenancy, and the typical way to manage that with Postfix is to have at least one separate instance for every customer. With KumoMTA, you can define all of your customers and all of their pools of IPs in one server instance, then manage them with tenant throttling and IP traffic shaping rules. Here's a breakdown of the differences:
Multi-Tenancy
- In Postfix, each customer or message stream is usually its own Postfix instance in order to separate the shaping, reputation and reporting. This means increased resource strain and management complexity.
- In KumoMTA, a single configuration can manage thousands of separate customers, IPs and Pools, all with different shaping and reporting paths. Simple to manage and efficient with resources.
Restarts
- In Postfix, any change you make to a configuration requires a reload and restart. This adds complexity and can interrupt customer mail flows. Usually means waiting for a maintenance window for alterations.
- In KumoMTA, only rare core system changes to logging and listeners require a restart. You can add IP pools, change shaping, and modify queues while the system is running.
Message processing
- In Postfix, testing or modifying the message requires passing it through a separate process (milter). For instance, DKIM signing is a separate process loop (milter). Spam scanning is another separate process, and antivirus scanning is yet another. Each of these processing loops consumes time and resources.
- In KumoMTA, these happen in-line with the message flow, which reduces processing time and minimizes resource consumption.
Raw Speed
- In performance testing, Postfix topped out at 0.5 million messages per hour when configured for raw speed, no milters
and on a relatively large server. - On the same server, KumoMTA was able to process 6.8 million messages per hour while also DKIM signing every message with a 1024-bit key.
Reporting granularity
- In Postfix, logging of message activity is separate for each instance. If you have multiple instances, you need to manage multiple log feeds in your own reporting tools. Further, the DSNs (bounces, transient failures, deliveries, etc) are not fully processed at all, but rather passed on to another process for sorting and reporting.
- In KumoMTA, it is all done for you in-line with no performance impact. KumoMTA will consume bounces and transient failures as well as feedback loops, condense them to categorized logs and include message-stream-specific data to tie the issue back to the original sender.
Simplicity
Imagine being able to wrap up all of your Postfix instances, along with all the milters and reporting, put it all in a single box with one configuration and reporting interface, and also make it 10 times faster in the process.
That is the effect of moving to KumoMTA as a postfix alternative. Let us know when you are ready for a conversation.
------------------------------------------------------------------
KumoMTA is the first open-source MTA designed from the ground up for the world's largest commercial senders. We are fueled by Professional Services and Sponsorship revenue.
Join the Discord | Review the Docs | Read the Blog | Grab the Code | Support the team