We are considering starting to use KumoMTA for sending/tracking deliverability of emails in our SaaS application by self hosting it on AWS via Docker. However, we have a lot of doubts/questions that are preventing us from starting. If we can get some brief pointers about them, that would definitely help us adopt KumoMTA faster in Production.
Does KumoMTA need to be deployed as a publicly accessible server from the internet (in a public subnet)? Or can it live in a private subnet attached to a NAT Gateway for security?
If the KumoMTA servers need to be publicly accessible from the internet, then how to secure it against bots, spam and brute force attacks?
Are there benchmarks on how many emails can KumoMTA send/receive per day on reference hardware to help us decide on which machine specs to choose to host it?
What’s the advisable way to deploy KumoMTA?
A single node powerful machine and vertically scale it on demand?
A static high availability setup with N nodes in front of a network load balancer and each node is hooked up to a static ip?
How can our application receive webhook events whenever there are deliverability/bounce events regarding emails we sent?
Are there any regular maintenance operations required for KumoMTA in Production that we should be aware of?
How can we integrate a Spam Filter tool with KumoMTA? Any recommendations?
Do we need to regularly rotate the static IP addresses allocated to the KumoMTA servers and update their DNS records for reputation/enhanced deliverability or it is not necessary?
Thank you for your consideration. I’ll try to answer these below.
1 & 2: KumoMTA can be installed almost anywhere. It was designed as an on-premises MTA that could be installed in physical servers, private cloud, or public cloud. It has been tested on discrete physical servers, VMware private cloud, and all the popular public clouds (AWS,Azure, GCP). You are in complete control of the deployment environment.
That also answers your second question about security. You are in complete control of security and we recommend installing in a private network that is proxied to public IPs. We actually provide a Socks5 proxy for that purpose.
By default, KumoMTA will only listen to localhost so it is inherently secure out-of-box. You have control over who or what connects to it.
3: we ran a set of benchmark tests several months ago and blogged the results. We are currently on the process of running a new set of tests but expect similar results.
In testing we have seen a customer process nearly 20 million messages per hour on an Azure 48core cloud instance. My own demo system is constantly sending a stream of 5Mmh on an AWS 24 core instance.
Sorry for the delay in getting this finished. Here you go for the rest:
4: The best way to deploy really depends on your environment, goals, and expertise. We have users with a single large instance and we have users with dozens of containers in a k8s framework. I would highly recommend starting with something easy and mid-sized that you can leave as your development system for the future. For instance, an AWS c5a.xlarge (4cores and 8gb RAM) with 30 Gb of gp3 storage is more than adequate to do a test install and config evaluation. You can easily upgrade or replace it when needed. If you prefer to test on bare metal, I have installed on a spare laptop with 8 cores and 16Gb RAM quite easily. We can certainly consult on this when you are ready.
5: KumoMTA handles Webhooks natively and can also deliver logs via Kafka and AMQP. There is sample documentation here on exactly how to set up a single basic webhook to pass all logs to your endpoint:
6: When it comes to regular maintenance operations, this is like any other server you own and manage. It is a good idea to monitor drive space, connection usage, and logs. There is decent documentation on most of that. KumoMTA also has some built-in management for things like drive space.
7: For AV/AS scanning, KumoMTA has a ton of API capabilities for this kind of thing. We have [soon to be documented] integrations with a couple of well known Spam and antivirus tools, but you have the ability to integrate with Lua code to any service that will allow you to use it. This again is something we can consult on with you when you are ready because it depends on your specific use case.
8: Rotating IPs? If you are being a responsible sender and managing your activity well, then rotating IPs should never be necessary on any platform. KumoMTA provides a ton of functionality for reporting and managing IP reputation that can prevent IP burnout if used properly. The TSA function was specifically designed to help with that.
@faithful-ostrich Thank you very much for taking the time to address my questions with this detailed response. Very much appreciated and helps a lot!
A follow up question on no.2 regarding security, I understand that KumoMTA can be deployed in a private network and either proxy traffic to Public IPs or just assign a NAT Gateway with a static public IP to the private network and then sending emails should be taken care of.
However, my concern is more related to how KumoMTA would be able to receive non-immediate feedback from receiver mail servers about bounces/deliverability events (ex: emails were initially accepted during sending, but then the receiving mail server later attempted to report a few things to the sender). If KumoMTA is not publicly accessible, then that wouldn’t be possible, no?
Ah. Yes, Out-Of-Band bounce handling is an included feature. Assuming your KumoMTA deployment is in a private network, you can NAT inbound traffic on port 25 to KumoMTA from public to private networks. Then in KumoMTA, you configure “listener_domains” to only accept OOB bounces only if they are addressed to your known bounce addresses.
IE:
You send a message like this:
rcpt to:awesome_tom@gmail.com
data
Message-ID: <01010192-000000@mail.kumomta.com>
From: "Marketing Team" <marketing@marketing.kumomta.com>
To: "Mr Mairs" <awesome_tom@gmail.com>
Subject: Stuff to test
Date: Tue, 25 Feb 2025 09:26:13 +0100
This is the body of a message
.
Your “bounce domain” (ReturnPath, MAIL FROM, etc) is mail.kumomta.com
so in your config you would set
log_oob = true```
When the message bounces out-of-band, the ISP sends a bounce message back to the bounce address ( MAIL FROM) which you have now configured to accept, process as bounce message to log and then drop.
Since the ESMTP listener should only accept relay messages from your defined injectors, from a security point of view, all other email that is not a bounce message will just be dropped.