Schluss mit verlorenen TYPO3-Mails, wenn der Mailserver ausfällt

Meistens ist mit deinem Mailserver alles gut. Ab und zu zickt er aber: ein vorübergehender SMTP-Fehler wie Googles 421 4.7.0 Try again later (die Antwort des Servers für „gerade beschäftigt, versuch es später noch mal“), ein kurzes Wartungsfenster oder ein Rate-Limit (eine Obergrenze, wie viele Mails ein Server in einer bestimmten Zeit annimmt) mitten im Newsletter-Versand.

Schlägt die Zustellung fehl, schickt ein Standard-TYPO3 die Mail ab und vergisst sie. Es gibt keinen zweiten Versuch, keinen Eintrag und keine Warnung — du merkst es erst, wenn jemand fragt, wo die Mail geblieben ist.

Genau das ist bei der Technischen Akademie Esslingen (TAE) passiert, einem Weiterbildungsanbieter mit 800 bis 1.000 Veranstaltungen pro Jahr auf TYPO3. Ein externer Mailserver fiel immer wieder aus, und zuerst hat es niemand gemerkt:

Nur auf halber Strecke. Ein Dienstleister (ein E-Mail-Versanddienst wie Postmark oder SendGrid) wiederholt die zweite Hälfte — von sich zum Empfänger, nachdem er deine Mail angenommen hat.

Erreicht deine Instanz (deine TYPO3-Installation) ihn gar nicht erst, wurde die Mail nie angenommen und existiert nirgends. Das passiert zum Beispiel bei einem Netzwerkfehler, einem API-Timeout (die Programmierschnittstelle des Dienstleisters hat nicht rechtzeitig geantwortet), einem HTTP-429-Fehler („zu viele Anfragen“) oder einer Störung beim Dienstleister. Mail Queue ist deshalb kein Ersatz für deinen Dienstleister, sondern die fehlende Hälfte davor.

Teams behelfen sich meist mit einer von drei Notlösungen, und jede hat ihren Haken:

• Der eingebaute Spool von TYPO3 (ein Zwischenspeicher für ausgehende Mails) tut nicht das, was die meisten annehmen. Die Voreinstellung wiederholt einen gescheiterten Versand dreimal im selben Request (im selben Seitenaufruf oder Formularversand) und verwirft ihn dann. Es gibt keinen Versuchszähler und keine Unterscheidung zwischen vorübergehendem und dauerhaftem Fehler. Am Ende bleibt nur eine Logzeile — ohne Empfänger, ohne Inhalt und ohne Möglichkeit, die Mail erneut zu verschicken.
• Zusätzliche Infrastruktur wie ein eigenes Mail-Relay (ein Server, der Mails nur weiterleitet) oder ein Mailcatcher-Container (ein separat betriebenes Tool, das Mails auffängt, statt sie zu verschicken) auf dem Staging (der Testkopie der Live-Website) heißt mehr bewegliche Teile, die du betreiben, absichern und dem Kunden erklären musst.
• Sich selbst ins BCC setzen ist der Klassiker unter Entwicklern. Wenn eine Registrierungsstrecke kaputt aussieht und du beweisen willst, dass die Mail das System verlassen hat, setzt du deine eigene Adresse ins BCC (Blindkopie: eine unsichtbare Kopie an eine weitere Adresse) und wartest. Einmal funktioniert das, als Gewohnheit macht es aber Probleme: Du änderst Versandcode nur zum Debuggen (Fehlersuchen), fremde Mails landen in irgendeinem Postfach (schon für sich ein Problem nach der DSGVO, der Datenschutz-Grundverordnung), auf dem Live-Server vergisst du leicht, es wieder abzuschalten, und über die Mails, die gescheitert sind, lernst du trotzdem nichts.

Die eigentliche Lücke ist einfacher: TYPO3 bietet keine eingebaute Möglichkeit zu sehen, ob eine Mail rausging und was drinstand.

Was wir stattdessen wollten: Mails im Normalfall sofort zustellen, nie eine einfach so verlieren und den ganzen Ablauf sichtbar machen — ohne neue Infrastruktur und ohne Eingriffe in den Code.

Alle. Mail Queue setzt am Mailtransport von TYPO3 an (dem Teil von TYPO3, der Mails an den Mailserver übergibt) und nicht am Anwendungscode — core-nah, so wie wir gerne arbeiten. Dadurch deckt es jede Mail der Instanz ab: deine eigenen Extensions, das Form Framework (das eingebaute Formular-Tool von TYPO3) und die Passwort-Mails aus felogin (dem Frontend-Login von TYPO3).

Am aufrufenden Code musst du nichts ändern. Prüfen musst du nur, ob eine Extension tatsächlich den TYPO3-Mailer nutzt — fast jede gepflegte Extension tut das.

Wenn du mehrere Sites aus einer TYPO3-Instanz betreibst, kann jede über ihren eigenen Mailserver senden. Mail Queue merkt sich, zu welchem Konto eine Mail gehört, und verschickt sie immer über genau dieses Konto. Eine wartende Mail geht also nie unter dem falschen Absender raus. Bei einer Installation mit nur einer Site gibt es nichts extra einzurichten, weil die Extension dort deinen normalen Transport nutzt.

Die Einrichtung hat drei Schritte:

1. Composer-Paket installieren (Composer ist das Standard-Werkzeug, um PHP-Software zu installieren).
2. Eine Zeile Konfiguration ergänzen.
3. Zwei wiederkehrende Jobs einrichten, entweder im TYPO3-Scheduler oder als Cronjob (eine zeitgesteuerte Aufgabe auf dem Server).

Solange diese Konfigurationszeile fehlt, wird nichts abgefangen und nichts in die Warteschlange gelegt. Du kannst die Extension also jetzt installieren und einschalten, wenn du so weit bist. Sie läuft auf TYPO3 v13.4.23 oder neuer und auf v14.

Ja, und genau das ist für Agenturen nützlich. Das Modul bleibt unsichtbar, bis du es freigibst, und die Rechte sind fein abgestuft. Ein Redakteur, dem du vertraust und der eine Site betreut, darf:

• die Warteschlange beobachten,
• eine steckengebliebene Mail erneut verschicken und
• eine Mail mit Tippfehler in der Empfängeradresse an die korrigierte Adresse schicken.

Bei der TAE ist der letzte Punkt der wichtigste. Teilnehmer buchen ohne Kundenkonto, also sagt ihnen niemand, wenn sie sich bei der Adresse vertippen:

Fürs Monitoring in der Produktion empfehlen wir dringend einen Webhook (eine automatische Nachricht, die ein System übers Web an ein anderes schickt). Ist die Warteschlange rot, ist meist genau SMTP der kaputte Teil — eine Warnung per Mail käme also womöglich nie an.

Ein Webhook über HTTPS (eine verschlüsselte Web-Verbindung) ist die Warnung, die dich trotzdem erreicht. Er meldet sich bei Slack oder Teams einmal, wenn es rot wird, und einmal, wenn es sich wieder erholt hat, nicht jede Minute.

Für lokale, Staging- und Testumgebungen gibt es eine verlässlichere Absicherung. Ein von Hand gesetztes Anhalten liegt in der Datenbank, was in der Produktion in Ordnung ist. Der Haken: Das Staging importiert regelmäßig die Produktionsdatenbank, und dieser Import bringt den Zustand „weiter senden“ aus der Produktion mit. Ein von Hand gesetztes Anhalten auf dem Staging wird vom nächsten Dump (einer Kopie der Datenbank) überschrieben, und die Mails fließen wieder.

Die Einstellung forceHold liegt stattdessen in der Deployment-Konfiguration (den Konfigurationsdateien, die mit jeder Umgebung ausgeliefert werden), sodass ein Datenbank-Import sie nicht aufheben kann. Ist sie an, verschickt die Umgebung schlicht nie etwas, und auch kein Administrator hebt das aus Versehen auf.

Ein praktischer Hinweis: Angehaltene Mails stapeln sich. Setz auf dem Staging deshalb eine Aufbewahrungsfrist, damit die tägliche Bereinigung Tabelle und Speicher im Griff behält. Ein einzelner Befehl leert die Warteschlange vor einer Demo oder nach einem Lasttest (einem Test, der viel Traffic simuliert).

Dasselbe Anhalten ist auch in der Produktion nützlich. Du kannst zum Beispiel eine Charge während einer geplanten Mailserver-Migration pausieren, danach fortsetzen, und alles geht mit dem nächsten Lauf raus.

Der Archivmodus schließt die letzte Lücke. Er behält jede verschickte Mail samt Inhalt, bis die Aufbewahrungsfrist abläuft, die du festlegst — mit einem Modul, das du auf die Leute beschränkst, die es sehen sollen.

Damit hast du eine echte Antwort auf den BCC-Trick: den Beleg, dass die Lizenzmail, die Rechnung oder die Passwort-Mail rausging, und genau, was drinstand. Das gilt für jede Mail, ohne Codeänderung, und jede davon kannst du per Klick aus dem Modul erneut verschicken.

In unseren Projekten ist Mail eins der Dinge, die erst Aufmerksamkeit bekommen, wenn sie ausfallen. Mail Queue macht die Zustellung zu etwas, dem du vertrauen und das du im Zweifel belegen kannst. Du bekommst weniger „Wo ist meine Mail?“-Tickets, eine klare Spur, wenn jemand fragt, und die Möglichkeit, den separaten Mailcatcher auf dem Staging zu streichen. Redakteure können das Tagesgeschäft in der Warteschlange übernehmen (auf Multisite beschränkt auf ihre eigene Site), Administratoren behalten die kritischen Schalter, und jede Site nutzt weiterhin ihren eigenen Mailserver.