KumoMTA-Einrichtung und Konfiguration

Warum muss der ausgehende Port 25 zuerst geöffnet werden?

Eine Voraussetzung verdient es, zuerst geklärt zu werden, weil ohne sie nichts läuft: der ausgehende Port 25. Es ist der Port, über den die Mailserver miteinander reden — der Transport zwischen Servern —, während die Einlieferung von einem Client über 587 mit Authentifizierung läuft. Privatanschlüsse blockieren ihn üblicherweise, und die großen Clouds sind nicht großzügiger: AWS blockiert den ausgehenden Port 25 standardmäßig auf allen Instanzen und verlangt das Formular „Request to remove email sending limitations“, mit einem zugehörigen A-Record und Reverse-DNS, und einer Antwort, die meist bis zu ein paar Tagen dauert. Andere Clouds haben ähnliche Schranken. Die direkte Konsequenz für den, der eine MTA bereitstellt: KumoMTA muss in einem Rechenzentrum oder einer Cloud leben, wo der ausgehende Port 25 tatsächlich offen ist, und jede versendende IP trägt einen PTR-Record, den die Empfänger verifizieren können. Das zu bestätigen — und den Freigabeantrag früh zu stellen, damit seine Vorlaufzeit parallel zum Rest der Vorbereitung läuft — ist Schritt eins jeder Bereitstellung, die wir machen, denn eine Engine, die nicht über Port 25 hinauskommt, stellt schlicht nicht zu, so gut sie auch konfiguriert ist.

Bare Metal, Docker oder Kubernetes für KumoMTA?

KumoMTA ist ungewöhnlich flexibel, was sein Zuhause angeht. Der klassische Weg ist eine Repository-Installation auf einem unterstützten Linux — Rocky und Ubuntu darunter —, die Ihnen einen systemd-Dienst auf einer Maschine gibt, die Sie von Ende zu Ende kontrollieren. Das Projekt liefert auch einen offiziellen Docker-Container, und die Architektur der Engine passt gut zu Kubernetes für Teams, die ihre MTA wie den Rest ihrer Plattform bereitstellen, skalieren und ausrollen wollen. Das ehrliche Auswahlkriterium sind nicht Benchmark-Zahlen — ein einziger gut konfigurierter Knoten bewegt in allen dreien Millionen Nachrichten pro Stunde — sondern Ihre Betriebsrealität: was Ihr Team sicher patchen, überwachen und wiederherstellen kann. Zwei technische Hinweise prägen die Wahl doch. Der Spool will schnelle lokale Festplatte, weil KumoMTA Nachrichten zur Haltbarkeit persistiert, sodass speicherausgehungerte Container eine selbst zugefügte Wunde sind. Und die Quell-IP-Bindung muss bewusst entworfen werden: In containerisierten und Mehrknoten-Bereitstellungen ist das saubere Muster, die Egress-IPs auf einen Proxy zu legen, der das HAProxy-Protokoll spricht — oder KumoMTAs eigenen Proxy-Begleiter —, sodass die Adressen, und die an sie gebundene Reputation, unabhängig von einem einzelnen Knoten leben. Diese Architektur entscheiden wir vor der Installation, denn sie später umzubauen heißt, Reputation zu bewegen, und Reputation bewegt sich schlecht.

Wie wird KumoMTA konfiguriert: init.lua und der Helper-Stack?

Das prägende Merkmal von KumoMTA ist, dass seine Konfiguration ein Programm ist: Die Policy lebt in Lua, ausgeführt innerhalb der MTA, was der Engine Bedingungen, Abfragen gegen Live-Daten und Logik gibt, die Sie wie jeden anderen Code versionieren und prüfen können. Eine Produktions-Policy heißt nicht, alles von Hand zu schreiben. Das Projekt liefert einen Stack aus Policy-Helfern — vorgefertigte Module für Shaping, Queue-Management, Egress-Quellen, DKIM-Signatur und Listener-Domains —, die schlichte TOML-Dateien konsumieren, sodass die alltäglichen Stellschrauben in lesbaren Datendateien leben, während der Lua-Kleber klein und stabil bleibt. Unsere Bereitstellung nutzt diesen Helper-Stack bewusst: Er hält Ihre Policy nahe an dem, was das Projekt dokumentiert und testet, macht Updates vorhersehbar und bedeutet, dass die Person, die sie in einem Jahr pflegt, strukturiertes TOML liest statt Archäologie. Wir schreiben die Policy, kommentieren sie, versionieren sie in Ihrem Repository und validieren sie mit dem projekteigenen Werkzeug — es gibt einen Shaping-Validator auf der Kommandozeile, genau damit ein Tippfehler nie die Produktion erreicht. Konfiguration als Code ist das Merkmal, das KumoMTA mächtig macht; sie mit Software-Disziplin zu behandeln, ist es, was sie sicher macht.

# Shaping-Regeln offline validieren \u2014 ein Tippfehler erreicht nie eine Live-Queue
$ kumo-tsa-daemon --validate-shaping /opt/kumomta/etc/policy/shaping.toml
shaping.toml: 142 Regeln geparst · 0 Fehler · 0 Warnungen
resolve gmail.com → connection_limit=8 max_message_rate=180/min (Community + lokal)

# Was macht jeder Provider gerade? (D=zugestellt T=Transit C=Verb Q=Queue)
$ kcli queue-summary
SITE                         D      T   C       Q
gmail.com                 4821    132   8       0
gmx.net                   3110     74   6       9
t-online.de               1980     38   4       0

# Einen vergifteten Stream auf eine gesündere Queue verschieben, Regeln neu bewertet
$ kcli rebind --domain gmx.net --reason "Reputations-Reset"
9 Nachrichten umgebunden · TSA-Regeln neu angewandt

Egress-Quellen und Pools: Identität per Design

Was PowerMTA-Betreiber als VirtualMTAs kennen, lebt in KumoMTA als Egress-Quellen und Pools: Jede Quelle ist eine Versandidentität — eine IP mit ihrem EHLO-Namen und ihrem Verhalten —, und Pools gruppieren Quellen, sodass Trafficklassen getrennt geroutet, gedrosselt und reputiert werden. Diesen Entwurf am Anfang gut zu treffen, ist der größte Teil dessen, was „sauber skalieren“ später bedeutet. Die Transaktionsmail, die der Empfänger erwartet und öffnet, darf keine IPs mit dem Massen-Marketing teilen, dessen Beschwerdeprofil anders ist; eine wichtige Marke oder ein wichtiger Kunde kann einen isolierten Pool verdienen; ein neuer oder riskanter Strom bleibt unter Quarantäne, damit ein Zwischenfall den Rest nicht mitreißt. Der Quellen-Helfer bildet Nachrichtenattribute — Kampagne, Mandant, Mailklasse — auf den richtigen Pool ab, sodass die Segmentierung von der Policy durchgesetzt wird und nicht von der Gewohnheit. Und weil Quellen über einen Proxy binden können, trägt derselbe Entwurf von einem Knoten zu einem Cluster, ohne etwas umzunummerieren. Wir dimensionieren die IP-Zahl gegen Ihr reales Volumen — genug Adressen, dass keine IP aggressiv wirkt, wenige genug, dass jede erkennbare Reputation aufbaut — und dokumentieren, welcher Strom wo lebt und warum.

Shaping pro Provider: die Regeln jeder Tür

Jeder große Mailbox-Provider hat seine eigenen Toleranzen — wie viele gleichzeitige Verbindungen, wie viele Nachrichten pro Verbindung, welches Stundentempo, wann TLS sich querstellt —, und an alle mit einer generischen Policy zu senden, lässt Zustellung liegen. KumoMTA drückt diese Regeln in Shaping-Dateien aus: vernünftige globale Defaults, dann Einträge pro Domain, die Verbindungslimits, Zustellraten und Timeouts auf das stimmen, was jeder Empfänger tatsächlich toleriert. Zwei Dinge machen diese Schicht stärker als handgestricktes Throttling. Das Projekt pflegt von der Community beigesteuerte Shaping-Regeln für die großen Provider, destilliert von Betreibern mit realem Volumen, die wir als Boden nutzen und dann auf Ihre Reputation und Mischung justieren. Und die Engine löst Regeln pro Ziel auf, mit Werkzeug, das zeigt, welche Policy genau auf eine gegebene Domain greift, sodass „was machen wir gerade mit diesem Provider“ eine prüfbare Antwort hat statt einer Vermutung. Shaping ist keine Stellen-und-vergessen-Tabelle — die Limits atmen mit Ihrer Reputation —, aber eine Bereitstellung, die vom Community-Baseline ausgeht, pro Provider gestimmt, beginnt höflich. Höflich ist, was neue Infrastruktur sein muss. Im DACH-Raum lohnt zudem die Erinnerung, dass neben den großen globalen Providern lokale wie GMX, Web.de und T-Online mit eigener Nutzerbasis und eigenen Akzeptanzregeln existieren, und sie mit eigenen Shaping-Einträgen statt einer generischen Richtlinie zu behandeln, ist es, was einen für das deutschsprachige Publikum gestimmten Versand auszeichnet.

Was ist Traffic Shaping Automation in KumoMTA?

Das Stück, das KumoMTA von den Engines der vorigen Generation trennt, ist Traffic Shaping Automation. Ein eigenständiger Daemon beobachtet die Antworten, die Ihr Traffic erhält, und justiert das Shaping automatisch gegen Regeln, die Sie definieren: Beginnt Gmail mit seiner Rate-Limit-Sprache bei einem Schwellenwert zu antworten, den Sie setzen, kann die Regel die Nachrichtenrate für jenen Pfad dreißig Minuten senken; gibt ein Provider eine Sperr-Signatur zurück, kann die Regel die Queue zwei Stunden aussetzen, statt gegen eine sich schließende Tür zu hämmern. Die Community-Regeln liefern Muster für genau diese bekannten Antworten, und Ihre eigenen Regeln erweitern sie. Das ist Backoff als erstklassiges, beobachtbares System: Die Automation läuft in ihrem eigenen Prozess, sodass sie nie mit der Zustellung konkurriert, sie wirkt über einen Cluster, und jede Justierung ist explizite Policy statt eines fest verdrahteten Reflexes. Wir konfigurieren TSA in jeder Bereitstellung — Daemon, Publish/Subscribe-Verdrahtung und Regeln —, denn es ist der Unterschied zwischen einer Engine, die auf das Stirnrunzeln eines Providers in Sekunden reagiert, und einer, die wartet, bis morgens ein Mensch die Logs liest. Der Deferral-Sturm um 3 Uhr nachts wird um 3 Uhr nachts gehandhabt; Sie lesen um 9 davon.

Welches DNS und welche Authentifizierung braucht KumoMTA vor dem Versand?

Bevor die erste Nachricht geht, müssen DNS und Authentifizierung fertig sein, denn hier wird 2026 die Zustellung gegen Gmail, Yahoo und Microsoft gewonnen oder verloren. Jede versendende IP braucht ihren PTR-Record, der zu einem Namen kohärent mit Ihrer Versanddomain auflöst — eine IP ohne Reverse-DNS ist eine sofortige rote Flagge. Die Domain veröffentlicht SPF, das die Versandquellen abdeckt, ohne das Zehn-Lookup-Limit zu sprengen, DKIM-Schlüssel, die der Signatur-Helfer von KumoMTA pro Domain auf jede Nachricht anwendet, und einen DMARC-Record, der über SPF oder DKIM ausrichtet. Das Alignment ist das Detail, das ansonsten korrekte Bereitstellungen zu Fall bringt: Es genügt nicht, dass SPF und DKIM bestehen — die bestehende Domain muss mit der übereinstimmen, die der Empfänger im Absender sieht. Wir schließen und verifizieren diese Schicht vor Beginn des Aufwärmens, einschließlich der langweiligen Bestätigungen, die man überspringt: dass Weiterleitung die Signaturen nicht bricht, wo Sie es verhindern können, dass die DMARC-Richtlinie einen Weg von der Beobachtung zur Durchsetzung hat und dass jeder Strom, den die Policy signiert, einer ist, den Sie tatsächlich senden. Eine perfekte Engine, die Mail versendet, die wegen halb aufgebauter Authentifizierung zurückkommt, ist das vermeidbarste Versagen dieser Branche.

Wie lange dauert das IP-Aufwärmen bei KumoMTA?

Neue IPs haben keine Reputation, und die Provider misstrauen Fremden, die im Volumen auftauchen — also umfasst die Bereitstellung einen geschriebenen Aufwärmplan, nie einen Nachgedanken. Die Mechanik ist schmucklos und sie wirkt: mit bescheidenen Tageszahlen pro IP und pro Provider beginnen, in Stufen über vier bis acht Wochen vervielfachen, zuerst an die engagiertesten Empfänger senden, damit die frühen Signale sagen, diese Mail ist erwünscht, und das Tempo von den Antworten der Provider regieren lassen statt von einem starren Kalender. KumoMTA gibt dem Aufwärmen zwei strukturelle Vorteile. Das Shaping drückt die Rampe als explizite Limits pro Provider aus, statt als kampagnenseitige Disziplin, die jemand unter Druck vergisst. Und TSA wirkt als Sicherheitsschiene: Löst eine Stufe Deferrals oder einen Beschwerdeanstieg aus, verlangsamt die Automation jenen Pfad sofort, während der Plan anhält und sich erholt. Diese Phase zu überspringen oder zu erzwingen, bleibt der häufigste Grund, warum technisch perfekte Bereitstellungen ihre ersten Monate schlecht zustellen. Wir geben Ihnen lieber einen etwas langsameren Start und eine Reputation, die hält — und wir setzen diesen Tausch am ersten Tag schriftlich auf, damit niemand überrascht ist, dass Woche zwei nicht Vollvolumen ist.

Bounces, Feedback-Loops und Monitoring vom ersten Tag

Gesunder Versand zeigt sich darin, wie er das Zurückkommende verwaltet, und diese Mechanik wird vor der ersten Kampagne konfiguriert, nicht nach dem ersten Schreck. KumoMTA klassifiziert die Antworten mit einer reichen Bounce-Taxonomie; wir verdrahten sie so, dass Hard Bounces — nicht existierende Adressen — sofort unterdrückt und nie wiederholt werden, Soft Failures mit vernünftiger Geduld wiederholen und Richtliniensperren mit den langen Intervallen behandelt werden, die sie verdienen. Die Feedback-Loops der Provider, die sie anbieten, werden registriert, sodass Beschwerdeereignisse automatisch zurückfließen, und jeder, der sich beschwert, landet ohne Menschen in der Schleife auf der Suppression-Liste. Auf toten oder unwilligen Adressen zu beharren, gehört zu den schnellsten Arten, den Providern Nachlässigkeit beizubringen; eine Bereitstellung, die vom ersten Tag an gnadenlos unterdrückt, liest sich ab ihrer ersten Woche als ernsthafter Versender. Die Suppression-Liste ist auch der Ort, an dem Compliance konkret wird: Abmeldungen innerhalb der Fristen geehrt, die die Bulk-Sender-Regeln verlangen, und die Linie von 0,30 % Beschwerden — der Schwellenwert, ab dem Provider unabhängig von Ihrer Authentifizierung handeln — durch Listendisziplin auf respektvollem Abstand gehalten statt durch Glück.

Logs, Accounting und Out-of-Band-Webhooks

Alles, was die Engine tut, hinterlässt eine Spur, und das Logging von KumoMTA ist für die Volumen gebaut, in denen Spuren teuer werden: strukturierte Aufzeichnungen, geschrieben als komprimierte JSONL-Segmente, mit den Feldern, der Rotation und der Aufbewahrung unter Ihrer Kontrolle. Jüngere Releases fügten ein Modul hinzu, um diese Segmente direkt zu lesen und zu schreiben, was ein Bereitstellungsmuster freischaltet, das wir für ernsthafte Betriebe sehr mögen: Webhook- und Analyseverarbeitung, die out of band läuft, als getrennter, langlebiger Prozess mit eigenem Checkpointing, eigenen Retries und Fehlermodi, statt im Hot Path der MTA mitzureiten. Ihre Plattform erfährt nahezu in Echtzeit, was zugestellt, deferred und gebounct wurde — ohne dass der Log-Transport je die Zustellung verlangsamen könnte. Wir entwerfen diese Schicht in der Bereitstellung: welche Ereignisse in welchem Detail aufgezeichnet werden, wie lange Segmente aufbewahrt werden, bevor sie gelöscht oder anonymisiert werden, im Einklang mit dem Datenschutzrecht, das für Sie gilt, und wie die Daten Ihre Dashboards erreichen. Eine Engine ohne Sichtbarkeit überrascht früher oder später; diese ist gebaut, beobachtet zu werden, und wir hinterlassen sie beobachtbar.

Integration: SMTP, HTTP-API und Ihr Stack

KumoMTA ist die Infrastrukturschicht und trifft Ihre Anwendung dort, wo sie schon ist. Der klassische Weg ist die SMTP-Einlieferung von Ihrer Kampagnen- oder Anwendungsschicht, angenommen auf einem Listener, den Sie kontrollieren, und nach Policy geroutet. Daneben gibt es eine native HTTP-Einlieferungs-API für Systeme, die lieber JSON an einen Endpunkt sprechen, als einen SMTP-Client zu pflegen, was die Engine auch aus serverlosen und queue-getriebenen Produzenten angenehm nutzbar macht. Ausgehend speist der Ereignisstrom Webhooks für den Zustellzustand, und die Engine verbindet sich mit dem Ökosystem, das eine moderne Plattform erwartet — Message Queues wie AMQP und Kafka für den Ereignistransport, Prometheus-Metriken mit Grafana-Dashboards für den Betrieb, Secrets in einem Vault statt in Konfigurationsdateien und direkte Datenabfragen aus der Policy, wenn Routing-Entscheidungen Live-Antworten brauchen. Wir entwerfen die Einlieferungs- und Ereigniswege explizit: was wohin eingeht, wie authentifiziert, und welche Ereignisse Ihre Systeme konsumieren. Richtig gemacht, hört die MTA auf, eine Blackbox am Rand des Diagramms zu sein, und wird ein gewöhnliches, beobachtbares Stück Ihrer Plattform.

Sicherheit: Zugangskontrolle, Relay-Disziplin und TLS

Eine Versand-Engine ist ein attraktives Ziel, und KumoMTA gibt einer Bereitstellung moderne Primitive, sie abzuriegeln — jüngere Releases fügten ein vollständiges Framework für Authentifizierung, Autorisierung und Accounting hinzu, mit granularer Kontrolle und einer Prüfspur über jede Interaktion mit den APIs der Engine. Wir nutzen es. Einlieferungs-Listener akzeptieren Mail nur von authentifizierten, aufgezählten Quellen, sodass die klassische Open-Relay-Katastrophe strukturell vom Tisch ist; die HTTP-API und die Metrik-Endpunkte antworten nur vertrauenswürdigen Netzen; TLS wird verlangt, wo Mail und Credentials sich bewegen; und die privaten DKIM-Schlüssel leben mit den Dateiberechtigungen und der Rotationsdisziplin jedes Produktions-Secrets. Rund um die Engine gilt die übliche Härtung — minimale Dienste, Firewalling, gepatchtes Betriebssystem —, und die Prüfspur bedeutet, dass „wer hat was angefasst“ eine Antwort hat. Eine kompromittierte oder zu freizügige MTA blamiert Sie nicht nur; sie gibt Ihre IP-Reputation für den Spam eines anderen aus und bringt Sie in Stunden auf Blocklisten. Diese Schicht taucht selten in der Demo auf, was genau der Grund ist, warum wir uns weigern, sie als optional zu behandeln.

Datenaufbewahrung und das Recht, das für Sie gilt

Zustell-Logs sind personenbezogene Daten mit einer Uhr darauf. Accounting-Aufzeichnungen tragen Empfängeradressen und Verhalten, was die Aufbewahrung zu einer rechtlichen Entwurfsentscheidung macht und nicht zu einer Frage des Festplattenplatzes: Im DACH-Raum heißt das die DSGVO und, in Deutschland, das BDSG — Sie bewahren, was Sie brauchen, so lange Sie es rechtfertigen können, und löschen oder anonymisieren dann nach Plan. Die Bereitstellung setzt das von Anfang an: welche Felder aufgezeichnet werden, wie Segmente rotieren, damit das Detail nie die Festplatte füllt, und eine geschriebene Aufbewahrungsrichtlinie, die die Rotation tatsächlich durchsetzt. Dieselbe Voraussicht umfasst die Einwilligung: Wir bauen Versandinfrastruktur ausschließlich für einwilligungsbasierte Programme, mit Suppression-Listen, die Abmeldungen halten, denn keine Engine-Konfiguration rettet einen Versender, der Menschen anschreibt, die nie gefragt haben. Im DACH-Raum kommt das UWG hinzu, das für werbliche E-Mail eine vorherige Einwilligung verlangt, die sich in der Praxis nur per Double-Opt-in belegen lässt; die Policy kodiert diese Regeln, statt darauf zu vertrauen, dass jemand sich erinnert. Eingebaute Compliance ist günstig; nachgerüstete Compliance unter Beschwerdedruck ist es nicht.

Compliance im DACH-Raum: UWG, DSGVO und CSA

Eine für das deutschsprachige Publikum gedachte Bereitstellung berücksichtigt Regeln, die der englischsprachige Markt nicht kennt, und es lohnt, sie zusammenzufassen. In Deutschland verlangt das UWG für werbliche E-Mail eine vorherige ausdrückliche Einwilligung, die sich rechtssicher nur per Double-Opt-in belegen lässt: Der Empfänger trägt sich ein und bestätigt die Anmeldung über einen Link, bevor die erste Werbenachricht kommt. Die DSGVO regelt darüber hinaus die Verarbeitung der zugrunde liegenden Daten, mit Nachweispflichten und Auskunftsrechten, die eine Versandinfrastruktur von Anfang an bedienen können sollte, und das BDSG konkretisiert sie in Deutschland. Und es gibt eine Besonderheit, die im DACH-Raum zum Vorteil wird: die Certified Senders Alliance (CSA), eine in Deutschland verwurzelte Whitelist, deren Aufnahmekriterien — saubere Einwilligung, funktionierende Abmeldung, niedrige Beschwerderaten, korrekte Authentifizierung — anspruchsvoll sind, deren Zertifizierung aber die Annahme bei den beteiligten Providern spürbar erleichtert. Die Bereitstellung so zu konfigurieren, dass sie diese Anforderungen erfüllt — und nicht nur die technischen Header der globalen Provider —, gehört dazu, einen Versand aufzusetzen, der im DACH-Raum zustellt und sich hält. Diese Schicht von Anfang an mitzudenken, spart Nacharbeit und schützt die Reputation, die alles Übrige aufzubauen versucht.

Skalierung und Hochverfügbarkeit

Ein gut gebauter Knoten trägt eine enorme Last, doch Wachstum und Fehlertoleranz werden entworfen, nicht improvisiert. KumoMTA clustert sauber: Mehrere kumod-Knoten teilen den Traffic, der Shaping-Automation-Daemon kann als eigener kleiner Sub-Cluster laufen, sodass der Log-Traffic nicht über jeden Knoten vermascht, geteilter Zustand wie Drosseln kann in Redis leben, und Egress-IPs, die über einen Proxy binden, überleben den Ausfall eines einzelnen Knotens mit intakter Reputation statt eingefroren auf einer toten Maschine. Das Muster, das wir bereitstellen, hält die Konfiguration jedes Knotens identisch — dieselbe Policy, dasselbe Shaping, Quellenauswahl per Pool —, sodass Kapazität hinzuzufügen Provisionierung ist, keine Operation. Auch wenn Sie auf einem einzigen Server starten, hinterlassen wir diese Nähte: den Proxy vor den IPs, die Policy in der Versionskontrolle, die TSA-Verdrahtung cluster-bereit. Die teure Version der Skalierung ist die, in der Reputation umziehen muss; die billige ist die, in der die Architektur schon Platz hatte. Der erste Tag ist, wann diese Wahl am wenigsten kostet.

Bringt KumoMTA ein Kontrollpanel mit?

KumoMTA hat keine Web-Oberfläche, und das ist eine bewusste Entwurfsposition: Das Projekt behandelt Konfiguration als Code und Betrieb als APIs, Metriken und Werkzeug, nicht als Klicks. Für viele Engineering-Teams ist das genau richtig. Für Betriebe, die eine visuelle Schicht wollen — Queues auf einen Blick, Zustellzustand pro Provider, eine Oberfläche, die ein Nicht-Operator lesen kann —, bauen wir ein Kontrollpanel auf KumoMTA, ohne das code-first-Modell darunter zu kompromittieren: Das Panel beobachtet und instruiert über dieselben APIs, die Ihre Automation nutzt, sodass es nie eine zweite Quelle der Wahrheit gibt. Während der Bereitstellung setzen wir die Betriebsbasis ohnehin auf — Dashboards, Alarme über Deferrals, Ablehnungen und Spam-Trap-Signale, Queue-Sichtbarkeit —, denn ein Panel ist optional, Beobachtbarkeit nicht.

Sollte es überhaupt KumoMTA sein?

Die ehrliche Frage vor der Bereitstellung ist, ob KumoMTA die passende Engine für Sie ist, und unsere Antwort darf nein lauten. Ihr idealer Bereich ist reales ausgehendes Volumen mit Bedarf an feiner Kontrolle pro Provider und pro IP, eigene Infrastruktur und ein Team — Ihres oder unseres —, das die MTA als Produktionssystem behandelt. Für bescheidene Volumen deckt eine gut gestimmte konventionelle MTA oder ein Cloud-Relay den Fall mit weniger Betriebsfläche ab. Betreiben Sie schon PowerMTA zufrieden unter Lizenz, ist der Wechsel eine Rechnung, kein Reflex — wir legen diese Mathematik auf der Migrationsseite dar und sind mit beiden Ausgängen gleich einverstanden. Und wenn das Feld wirklich offen ist — KumoMTA, PowerMTA, Halon, MailerQ —, behandeln wir es als MTA-Auswahl mit Ihrem Interesse vorn, denn wir verkaufen keine davon weiter. Die günstigste Bereitstellung ist die, die Sie nicht brauchten; die sagen wir Ihnen lieber, als sie zu bauen.

Wie „fertig“ aussieht

Eine Bereitstellung ist fertig, wenn sie sich allein trägt und ohne uns verstanden wird. Konkret: Die IPs wärmen nach einem geschriebenen Plan in gutem Tempo; DNS und Authentifizierung bestehen und richten für jeden Strom aus; Quellen und Pools trennen die Mail nach Natur, mit Shaping pro Provider, das vom Community-Baseline ausgeht und auf Ihres gestimmt ist; TSA reagiert automatisch und sichtbar auf den Gegendruck der Provider; Bounces werden verarbeitet, tote Adressen unterdrücken sich selbst, die Feedback-Loops sind verdrahtet; Logs fließen zu Ihren Dashboards mit durchgesetzter Aufbewahrung; Zugangskontrolle und TLS sind an, mit einer Prüfspur hinter den APIs. Und alles ist dokumentiert — wie es aufgebaut ist, warum jede Entscheidung fiel, was anzufassen ist, wenn sich etwas ändert — mit der Policy in der Versionskontrolle. Eine Bereitstellung, die nur funktioniert, solange ihr Erbauer erreichbar ist, ist nicht fertig; ihr steht eine Übergabe aus, die noch nicht stattgefunden hat. Wir betrachten das Projekt als geschlossen, wenn Ihr Team, oder unser gemanagter Service, sie ohne Folklore betreiben kann.

Wie läuft eine KumoMTA-Bereitstellung Schritt für Schritt ab?

Wir beginnen mit dem kostenlosen 25-Punkte-Audit, das die Eignung der Engine bestätigt und den Ausgangszustand von DNS, IPs und Authentifizierung fixiert. Von da folgt die Arbeit der Reihenfolge, die diese Seite beschreibt: den ausgehenden Port 25 bestätigen und die Cloud-Freigabe früh stellen; den Host — oder die Container-Plattform — vorbereiten und härten und die IP-Bindungsarchitektur entscheiden; DNS, Authentifizierung und Alignment schließen; aus Repo oder Container installieren und die Policy mit dem Helper-Stack legen; Quellen, Pools und Shaping pro Provider vom Community-Baseline entwerfen; Traffic Shaping Automation verdrahten und jede Shaping-Datei mit dem Projektwerkzeug validieren; Bounce-Verarbeitung, Feedback-Loops, Suppression und Monitoring anbinden; den Aufwärmplan schreiben; dann die Rampe unter täglicher Aufsicht starten. Vorbereitung und Konfiguration brauchen je nach Umgebung Tage bis ein paar Wochen, mit der Port-25-Vorlaufzeit parallel laufend; das Aufwärmen fügt dann vier bis acht Wochen bis zum Zielvolumen mit einer Reputation hinzu, die hält. Zum Abschluss erhalten Sie die Installation dokumentiert, damit Ihr Team sie betreibt — oder wir betreiben sie als gemanagtes KumoMTA weiter. Die Infrastruktur ist durchgehend Ihre, und die Beziehung wird nach Arbeit berechnet, ohne eine Engine, die über den Tisch zu verkaufen wäre.

Wenn Sie eine KumoMTA-Bereitstellung planen — erste MTA, neue Kapazität oder der Neubau von etwas, das nie ganz funktionierte —, kostet der Ausgangspunkt nichts: Das 25-Punkte-Audit bestätigt die Eignung und den Zustand Ihres DNS, Ihrer IPs und Ihrer Authentifizierung, bevor etwas gebaut wird. Von da stellen wir es so bereit, wie wir unser eigenes betreiben: geformt, aufgewärmt, bewacht und aufgeschrieben.