Momentum hat das Wartungsende erreicht. KumoMTA ist, wohin es als Nächstes geht.

Die meisten Migrationsentscheidungen wägen eine stabile Engine gegen eine bessere ab. Diese nicht, denn die Quell-Engine ist bereits aus der Zeit gefallen. Momentum, die On-Premise-MTA, die als Ecelerity begann und zwei Jahrzehnte lang einen großen Anteil der Unternehmens-E-Mail der Welt antrieb, hat das Ende ihres unterstützten Lebens erreicht. Das Argument für den Wechsel ist nicht, dass KumoMTA vorzuziehen ist, obwohl es das ist; es ist, dass Bleiben heißt, eine Produktions-Versandinfrastruktur zu betreiben, die keine Fehlerbehebungen mehr erhält, auf einer Uhr, die bereits an einer Frist vorbei ist und zur nächsten herunterzählt.

Die gute Nachricht für Momentum-Betreiber ist, dass das natürliche Ziel ungewöhnlich gut passt, und nicht zufällig. Die Open-Source-Engine, die sich als Momentums Nachfolger herausgebildet hat, wurde zum Teil von den Menschen gebaut, die Momentum selbst bauten. Das ist also weniger ein Sprung in etwas Fremdes als ein Wechsel zu dem, was dieselben Köpfe entwarfen, sobald sie frei von den kommerziellen Zwängen waren, die das Original prägten. Die Migration ist echte Arbeit, aber das Ziel wurde von Menschen gemacht, die genau wussten, woher die Quelle kam.

Wie dringend ist das Momentum-End-of-Life wirklich?

Die Daten sind nicht vage. Gemäß der eigenen End-of-Life-Policy von Message Systems endete die Wartung für alle Versionen von Momentum 4 am 1. März 2026, und der Support für alle Versionen endet am 1. März 2027. Wartungsende heißt keine Fehlerbehebungen mehr; Supportende heißt niemand, den man anruft, wenn etwas schiefgeht. Für ein Stück Software in einer Schublade wäre das eine Abstraktion. Für die Engine, die Ihre Versandreputation trägt, ist es eine reale und wachsende Exposition.

Was End-of-Life Sie tatsächlich kostet, sammelt sich still an. Eine nicht unterstützte MTA bricht nicht an dem Tag, an dem der Support endet; sie hört schlicht auf, Schritt zu halten. Die Zustellbarkeitsanforderungen bewegen sich weiter — neue Authentifizierungsdurchsetzung, neue Providererwartungen —, und eine Engine, die keine Updates mehr liefert, fällt stetig weiter hinter sie zurück. Sicherheitsbehebungen hören für Software auf zu kommen, die per Design dem Internet ausgesetzt ist. Und an dem Tag, an dem ein echtes Problem trifft, ist die Herstellerbeziehung, die es früher löste, weg. Nichts davon zwingt Sie diese Woche, was genau der Grund ist, warum es gefährlich ist: Das Fehlen einer unmittelbaren Krise macht es leicht, eine Engine weiterzubetreiben, deren Support-Fenster sich schließt, bis die Migration, die Sie ruhig hätten machen können, eine wird, die Sie unter Druck machen müssen.

Der Momentum-Bestand, den Sie verlassen

Es lohnt zu benennen, was eine Momentum-Bereitstellung tatsächlich ist, denn die Migration muss alles davon berücksichtigen. Ein typischer Bestand ist mehr als die Engine: Er ist ecelerity.conf und die Policy, auf die sie verweist, oft über viele eingebundene Dateien verteilt, über Jahre angesammelt; eine Manager-und-Node-Topologie, in der die Konfiguration auf mehrere MTAs ausgebracht wird; Spool-Verzeichnisse, die Mail in Bewegung halten; ein SNMP-Agent, der das Monitoring speist, das Sie um die MTA-MIB gebaut haben; und ein Korpus von Policy, geschrieben in Momentums eigenem Modell — Pathways, die das Inbound-Verhalten regieren, Hooks, die an Punkten des Nachrichtenlebenszyklus feuern, Drosseln, über Jahre des Betriebs pro Ziel gestimmt.

All das kodiert echtes Betriebswissen, und all das ist, was End-of-Life langsam strandet. Die Konfiguration funktioniert weiter, hört aber auf, sich zu entwickeln; die Plattform darunter — die Betriebssysteme, die Momentum unterstützt, die Abhängigkeiten, die es annimmt — altert unter ihr weg; und das institutionelle Wissen, wie man sie betreibt, dünnt aus, wenn die Menschen, die Momentum kannten, weiterziehen und keine neuen eine End-of-Life-Engine lernen. Eine Momentum-Migration trägt alles, was dieser Bestand repräsentiert, auf eine Plattform, die sich weiter vorwärtsbewegt; der Softwaretausch ist der kleinste Teil der Arbeit. Die erste Aufgabe ist, das Ganze zu lesen, einschließlich der Ecken von ecelerity.conf, in die seit Jahren niemand geschaut hat, die aber still prägen, wie Ihre Mail gesendet wird.

Ist KumoMTA wirklich der Nachfolger von Momentum?

KumoMTA ist nicht die Vermutung eines Dritten, wie ein Momentum-Ersatz aussehen sollte. Es wurde von Veteranen derselben Firma gegründet — Mike Hillyer, der zwölf Jahre Ecelerity und Momentum aus seinen OmniTI- und Message-Systems-Tagen verkaufte und unterstützte, Tom Mairs und Wez Furlong, der Ecelerity entwarf, die Engine, die zu Momentum wurde. Die Menschen, die das kommerzielle Produkt schufen, bauten das Open-Source-Produkt, mit zwei Jahrzehnten des Wissens, was genau funktionierte und was sie bei einem sauberen Start anders machen würden.

Diese Abstammung zählt für eine Migration auf konkrete Weise, über die Beruhigung hinaus. Die Konzepte, die ein Momentum-Betreiber kennt — Pathways, Policy-Hooks, Traffic Shaping, das ganze mentale Modell, Mailfluss als programmierbare Policy zu behandeln — wurden bewusst nach KumoMTA übernommen statt von Grund auf neu erfunden, weil dieselben Menschen sie schätzten. Das Ergebnis ist, dass ein Momentum-Administrator die Denkweise von KumoMTA vertraut findet, auch wo die Syntax gänzlich neu ist. Das Ziel wurde zum Teil so entworfen, dass es der Ort ist, an den Momentum-Betreiber schließlich gehen müssten.

Warum Momentum-Betreiber ohnehin schon gingen

End-of-Life formalisierte einen Abgang, der seit Jahren im Gange war, aus Gründen, die die früheren Mitarbeiter der Engine offen beschrieben haben. Die kommerziellen Bedingungen bewegten sich stetig gegen große Versender — von ewigen Lizenzen über eine einmalige Gebühr pro Volumenstufe zu jährlicher volumenbasierter Preisgestaltung —, sodass die Kosten, dieselbe Engine zu betreiben, weiter kletterten. Zugleich verlagerte sich der Fokus der Firma von On-Premise-Software zu einem Cloud-Dienst, SparkPost, den viele ihrer On-Prem-Kunden als direkten Wettbewerber sahen und der es schwerer machte, die Investition in das On-Prem-Produkt aufrechtzuerhalten, das sie tatsächlich betrieben. Beim Preis gedrückt und den Ertrag einer erzwungenen Investition schwinden sehend, begannen große Versender weit vor den EOL-Daten, die es offiziell machten, nach dem Ausgang zu suchen.

Die Apache-2.0-Lizenzierung von KumoMTA beantwortet genau diese Beschwerden, was nicht überrascht angesichts dessen, wer sie zuerst spürte. Es gibt keine jährliche Gebühr, die mit Ihrem Volumen steigt, keinen Hersteller, der untergehen oder die Preise erhöhen oder Ihr Lizenzgeld in einen Dienst umleiten kann, der mit Ihnen konkurriert, und kein Risiko, dass die Software aufhört zu funktionieren, wenn Sie aufhören zu zahlen. Sowohl Momentum als auch PowerMTA sitzen nun unter demselben Eigentümer, Bird, auf derselben stockenden Bahn — zwei kommerzielle Legacy-Engines, mehr gewartet als weiterentwickelt. Die offene Alternative beseitigt das strukturelle Problem, statt die Version des einen Herstellers gegen die eines anderen zu tauschen.

Was bringt Ihnen der Wechsel zu KumoMTA tatsächlich?

Eine End-of-Life-Engine zu verlassen, ist Grund genug zu migrieren, aber es verkauft das Ziel unter Wert, den Wechsel rein als Flucht zu rahmen. KumoMTA ist nicht bloß ein unterstütztes Momentum; es ist eine Generation neuer, und die Gewinne sind konkret. Es ist in Rust geschrieben, einer speichersicheren Sprache, die sowohl das US Office of the National Cyber Director als auch ein NSA-Bericht gegenüber dem C und C++ empfohlen haben, auf denen ältere MTAs gebaut sind — ein realer Sicherheitsvorteil für dem Internet zugewandte Infrastruktur. Seine Konfiguration lebt als Code in der Versionskontrolle, sodass Änderungen geprüft und getestet werden, statt mit einem Online-Befehl live gesetzt und überhofft.

Die betrieblichen Gewinne multiplizieren sich von dort. KumoMTA ist cloud-nativ, gebaut, um in Containern zu laufen und horizontal über Docker oder Kubernetes zu skalieren, wo Momentums Modell jener Welt vorausging. Seine Traffic Shaping Automation reagiert in Echtzeit auf Providerantworten und justiert Drosseln, wie die Mailbox-Provider ihr Verhalten ändern, statt an statischen Limits festzuhalten, die in dem Moment falsch sind, in dem ein Provider sich bewegt. Seine Telemetrie läuft über Prometheus und Grafana, reicher und standardmäßiger als SNMP. Und es integriert sich offen — Webhooks, Kafka, direkter Datenbankzugriff über Lua-Hooks —, sodass die MTA ein Teilnehmer Ihrer Datenpipeline wird statt einer Insel. Keines davon ist für sich ein Grund, eine funktionierende Engine aufzugeben; zusammen, und obendrauf auf die End-of-Life-Realität, machen sie den Wechsel zu einem Schritt nach vorn statt bloß zu einer seitlichen Flucht aus einer sich schließenden Tür. Sie migrieren nicht, um auf unterstützter Software stillzustehen; Sie migrieren auf eine Plattform, gebaut für das Jahrzehnt, in dem Sie tatsächlich senden.

Was ändert sich technisch, von ecelerity.conf nach Lua?

Das Herz einer Momentum-Migration ist die Übersetzung von ecelerity.conf und seiner Policy in das Lua von KumoMTA. Die beiden sind im Geist näher, als Momentum und eine statische Konfiguration es wären, weil beide das Versandverhalten als Logik behandeln statt als flache Liste von Einstellungen — Momentum über seine Policy-Hooks und Pathways, KumoMTA über Konfiguration als Code. Diese geteilte Philosophie ist es, was diese Übersetzung stellenweise sauberer macht als eine PowerMTA-Migration. Die meisten Momentum-Konstrukte haben ein direktes KumoMTA-Äquivalent.

// Momentum: ein Binding mit seinen Throttles (ecelerity.conf, C-Syntax)
binding "pool-a-1" 
  source_ip = "198.51.100.10"
  outbound_throttle_connections = "8/per_domain"
  outbound_throttle_messages = "120/min/per_domain"


# KumoMTA: dieselbe Absicht als Egress Source + Shaping (Lua + TOML)
egress_sources = {
  ['pool-a-1'] = { source_address = '198.51.100.10' },
}
# shaping.toml — Throttles werden Shaping pro Provider (GMX vorsichtiger)
['gmx.net'] connection_limit = 8 max_message_rate = '120/min'