KumoMTA vs PowerMTA: ein ehrlicher Vergleich.

KumoMTA vs PowerMTA: was ist die kurze Antwort?

Wenn Sie einen reifen PowerMTA-Betrieb haben, der gut läuft, behalten Sie ihn — es gibt keinen Preis dafür, ein System zu wechseln, das zustellt. Wenn Sie bei hohem Volumen neu anfangen, oder wiederkehrende Lizenzkosten beseitigen wollen und moderne, cloud-native Werkzeuge bevorzugen, ist KumoMTA zu einer ernsten Antwort geworden, die es vor wenigen Jahren nicht gab. Und wenn Sie nicht tatsächlich in dem Maßstab senden, für den diese Plattformen gebaut sind, ist die ehrlichste Empfehlung, keinen von beiden zu nutzen und Postfix zu betreiben, das nichts kostet und die überwältigende Mehrheit des echten Versands abdeckt.

Das ist die ganze Entscheidung in drei Sätzen, und der Rest dieses Stücks erklärt, warum — die Architektur, die Kosten, das Support-Bild und die Migration —, damit Sie die Begründung prüfen können, statt sie auf Vertrauen zu nehmen. Wir hosten beide Plattformen, also haben wir hier ein Interesse; wir haben versucht, das offenzulegen und Ihnen die Version dieses Vergleichs zu geben, die wir uns wünschen würden, wenn wir wählten, nicht die Version, die die meisten verwalteten Server verkauft.

Eine Einordnung hilft vor dem Detail: Dies ist weniger ein Kampf zwischen zwei Produkten als eine Wahl unter drei Antworten, mit Postfix als dem stillen Dritten. Ein Großteil der Energie in „KumoMTA vs PowerMTA“-Debatten kommt von Versendern, die bereits, oft ohne zu prüfen, angenommen haben, dass sie überhaupt einen dedizierten Massenversand-MTA brauchen. Diese vorgelagerte Frage zuerst zu klären — ob Sie wirklich in dem Volumen senden, für das diese Werkzeuge existieren — erspart mehr Kummer als jeder Funktionsvergleich, und deshalb kehren wir immer wieder zu ihr zurück.

Worin unterscheiden sie sich unter der Haube?

Die Architektur ist, wo die beiden am stärksten auseinandergehen, und sie erklärt fast jeden praktischen Kompromiss. PowerMTAs threaded C-Design ist auf den Durchsatz auf einer einzelnen, gut spezifizierten Maschine optimiert, mit einem Pro-Warteschlange-Modell, das für jede Kombination aus VirtualMTA und Empfänger-Domain getrennte Warteschlangen erzeugt — ein Modell, das gut verstanden und über viele Jahre verfeinert ist. KumoMTAs asynchrones Rust-Design setzt auf Nebenläufigkeit und moderne Hardware und zielt darauf, sehr hohe Nachrichtenraten mit weniger Handarbeit und einer cloud-nativeren Betriebsform zu bewältigen.

Die Konfigurations-Philosophie folgt daraus. PowerMTA wird mit Direktiven konfiguriert — mächtig, präzise und dicht, mit Throttling pro ISP und virtuellen MTAs, deklarativ ausgedrückt. KumoMTA wird in Lua konfiguriert, was heißt, die Konfiguration ist echter Code: Sie können Logik ausdrücken, nicht bloß Einstellungen, und Verhalten wie die Warteschlangen-Isolation pro Mandant direkt bauen. Keines ist im Abstrakten einfacher; Direktiven sind leichter auf einen Blick zu lesen, während Scripting mächtiger ist, wenn Ihr Routing-Bedarf wirklich komplex ist.

# pmta.conf — direktivenbasiert, ~200 Parameter
<virtual-mta vmta-pool-a>
    smtp-source-host  198.51.100.21  mail.example.com
    <domain gmail.com>
        max-msg-rate   120/min
        max-smtp-out   20
        backoff-mode   auto
    </domain>
</virtual-mta>
# mächtig und dicht; das Tuning pro ISP ist Expertenarbeit

-- KumoMTA — die Konfiguration ist Lua, also echte Logik
kumo.on('smtp_server_ehlo', function(domain)
  if domain:find('gmail.com') then
    return { max_connection_rate = '10/min', max_deliveries_per_connection = 20 }
  end
end)
-- Isolation pro Mandant: ein Versender senkt nicht die Reputation eines anderen
kumo.on('get_queue_config', function(domain, tenant)
  return { queue_name = tenant .. '-' .. domain }
end)

Kein Konfigurations-Stil ist objektiv besser; sie scheitern in verschiedene Richtungen. Direktiven sind schnell zu lesen und schwer subtil falsch zu machen, stoßen aber an eine Decke, wenn Ihre Routing-Logik wirklich bedingt wird. Scripting hat keine solche Decke, aber eine Konfiguration, die Code ist, kann auch Fehler tragen, die eine Konfiguration aus Einstellungen nicht kann. Welches Risiko Sie bevorzugen, hängt davon ab, wie komplex Ihr Versand wirklich ist und wie wohl sich Ihr Team dabei fühlt, Logik statt Parameter zu lesen.

Betriebssystem und Ökosystem-Passung

Ein praktischer Unterschied, der manche Entscheidungen direkt entscheidet: PowerMTA läuft sowohl auf Linux als auch auf Windows, während KumoMTA per Design nur Linux ist. Für die meisten modernen Versender ist das kein Hindernis, da Hochvolumen-E-Mail-Infrastruktur ohnehin überwiegend auf Linux lebt — aber wenn Sie eine echte Windows-Anforderung haben, sei es aus vorhandenen Werkzeugen oder betrieblicher Richtlinie, ist PowerMTA schlicht die passende Option, und diese Einschränkung kann die Entscheidung klären, bevor ein anderer Faktor gewogen wird.

Die Reife des Ökosystems schneidet auf subtilere Weise in die andere Richtung. Weil PowerMTA zwei Jahrzehnte der Standard war, kennt ein tiefer Pool an Ingenieuren seine Konfiguration bereits genau, und Muster für fast jede Situation sind irgendwo niedergeschrieben. KumoMTA ist jünger, also sind seine Community und Dokumentation, obwohl sie schnell wachsen und von Leuten gemacht sind, die den Problemraum kennen, schlicht neuer. Wenn Ihnen wichtig ist, jemanden einzustellen, der Ihren MTA bereits kennt, begünstigt diese Geschichte noch PowerMTA — auch wenn jedes Jahr die Lücke verkleinert, je mehr Teams KumoMTA einsetzen und darüber schreiben.

Die Kosten und die Lizenzfrage

Der konkreteste Unterschied ist das Geld. PowerMTA ist kommerzielle Software; mit seiner gebündelten Analytik beginnt es typisch bei rund achttausend Dollar im Jahr und klettert mit dem Volumen, was für einen etablierten Versender handhabbar ist, aber für ein Team, das Hochvolumen-Infrastruktur noch erprobt, eine echte Überlegung. Der Kern von KumoMTA ist kostenlos unter Apache 2.0, mit optionalem bezahltem Support und Enterprise-Funktionen vom Unternehmen dahinter, wenn Sie sie wollen — der Software-Kosten kann also wirklich null sein.

Es gibt einen feineren Punkt, der mehr zählt als die Schlagzeilen-Zahl: PowerMTA validiert seine Lizenz periodisch, und schlägt diese Validierung fehl — eine abgelaufene Lizenz oder ein Verbindungsproblem zum Lizenzserver —, nimmt der MTA keine neuen Nachrichten mehr an. Für geschäftskritischen Versand ist das eine betriebliche Abhängigkeit vom Lizenzserver eines externen Anbieters, die es bei einem quelloffenen MTA schlicht nicht gibt. Sie beißt selten, aber wenn doch, beißt sie zum denkbar schlechtesten Zeitpunkt, und es lohnt, sie neben den wiederkehrenden Kosten abzuwägen, nicht danach.

Die ehrliche Einordnung sind die Gesamtkosten, nicht die Lizenzkosten allein. PowerMTAs Gebühr kauft Reife, Vertrautheit und — historisch — Support, was für manche Organisationen gut angelegtes Geld ist; KumoMTAs Null-Lizenz verschiebt den Kosten in die Engineering-Zeit, es selbst zu betreiben und zu scripten, oder in einen optionalen Support-Vertrag. Keines ist automatisch günstiger, sobald Sie die Menschen ebenso wie die Rechnungen zählen, und der richtige Vergleich ist die Gesamtzahl für Ihr Team, nicht der Aufkleber auf der Software.

Zustellbarkeit und tägliche Kontrolle

Bei der Zustellbarkeit zeigt sich PowerMTAs lange Reife: es bietet ab Werk eine starke Verwaltung, mit ausgetretenen Mustern für IP-Pools, Throttling pro ISP und Bounce-Behandlung, die Ingenieure bereits kennen. KumoMTA gibt Ihnen dieselben Ergebnisse über Lua, was ein wenig Bequemlichkeit ab Werk gegen sehr viel Flexibilität tauscht — Sie können genau die Formungs- und Routing-Logik kodieren, die Sie wollen, einschließlich der Isolation pro Mandant, damit die Reputationsprobleme eines Versenders nie in die eines anderen überlaufen.

Der Kontrollunterschied ist am sichtbarsten, wenn etwas schiefgeht. Wenn ein Mailbox-Anbieter das Throttling verschärft oder eine IP vorübergehend sperrt, wollen Sie in Echtzeit zurückfahren, umrouten und die Formung anpassen — und mindestens ein bekannter Transaktions-Anbieter nannte genau diese feinere Echtzeit-Kontrolle, zusammen mit moderner Auto-Scaling-Infrastruktur, als Grund, warum er seine gesamte Plattform von PowerMTA zu KumoMTA bewegte, und berichtete danach von ebenso schneller oder schnellerer Zustellung. Ob diese Flexibilität den Scripting-Aufwand wert ist, hängt davon ab, wie oft Sie in das Verhalten des MTA hineingreifen müssen, statt um es herum.

Eine faire Art, es zu betrachten: PowerMTA gibt Ihnen ausgezeichnete Voreinstellungen und erwartet, dass Sie selten mehr brauchen, während KumoMTA Ihnen weniger Annahmen und mehr Reichweite gibt. Teams, die wollen, dass ihr MTA meist verschwindet und einfach zustellt, neigen dazu, Ersteres zu schätzen; Teams, die Zustellbarkeit als eine aktive, praktische Disziplin behandeln und sich aus jedem neuen Throttling-Muster herausscripten wollen, neigen dazu, Letzteres zu schätzen. Beide Philosophien stellen Mail gut zu; sie passen zu verschiedenen Temperamenten.

Und ehrlich — vielleicht keiner

Es lohnt, bei der Option zu verweilen, die das Marketing nie empfiehlt, weil sie am häufigsten die richtige ist. Postfix, in den meisten Linux-Distributionen enthalten, bewältigt die große Mehrheit des selbst gehosteten Versands ohne Lizenzkosten. Das Volumen, bei dem seine Grenzen wirklich zählen — Warteschlangen-Verwaltung im Maßstab, anspruchsvolles Throttling pro ISP —, beginnt weit in den Hunderttausenden Nachrichten pro Tag, was weit über dem liegt, was die meisten Unternehmen je erreichen. Unterhalb dieser Linie zu einem dedizierten Massenversand-MTA zu greifen, heißt, in Geld oder Komplexität für Fähigkeit zu zahlen, die Sie nicht nutzen werden.

Wir sagen das im Wissen, dass es manche Leser davon abbringt, überhaupt etwas von uns zu kaufen, und wir sagen es dennoch, weil die Alternative — jemandem einen Hochvolumen-MTA zu verkaufen, den er nicht braucht — der Weg ist, auf dem Vertrauen verloren geht. Der richtige MTA ist der, der zu Ihrem tatsächlichen Versand passt, und für einen großen Teil der Versender ist das noch der kostenlose, der schon in ihrer Distribution steckt. Wenn das Sie sind, ist das Nützlichste, was wir tun können, es Ihnen zu sagen und Ihnen zu helfen, ihn gut zu betreiben.

Das ist am Ende der Geist dieses ganzen Vergleichs: passen Sie das Werkzeug an die Aufgabe an, zählen Sie die Gesamtkosten statt der Lizenz allein, und respektieren Sie die Migration als das echte Projekt, das sie ist. Tun Sie diese drei Dinge, und das konkrete Logo auf der Software — Open Source oder kommerziell, KumoMTA oder PowerMTA oder gar keiner — zählt weit weniger als die Disziplin, mit der Sie betreiben, was Sie wählen.