---
title: Mail Queue für TYPO3 — keine Mail geht mehr verloren
url: "https://b13.com/de/produkte/mail-queue-fuer-typo3"
description: Gescheiterte Mails landen in einer Warteschlange und gehen raus, sobald es wieder geht. Ohne Codeänderung.
image: "https://b13.com/fileadmin/_processed_/e/f/csm_sharing-ext-mailqueue-M_a5f0575ce3.png"
date: 2026-09-30
modified: 2026-10-01
lastUpdated: 2026-10-01
---
# Mail Queue für TYPO3 — keine Mail geht mehr verloren
Mail Queue — keine Mail geht mehr verloren
============================================
**Wenn dein Mailserver kurz stolpert, verwirft TYPO3 die Mail stillschweigend. Eine Zeile im Log, keine zweite Chance.**
Mail Queue verschickt jede Mail sofort, genau wie bisher. Erst wenn eine Zustellung scheitert, greift sie ein: Die Mail kommt in eine Warteschlange und wird in wachsenden Abständen erneut verschickt, bis sie draußen ist. Weil das auf Transportebene passiert, ist **jede Mail erfasst, die TYPO3 über den konfigurierten Mailtransport verschickt**: deine Extensions, das Form Framework, die Mails zum Zurücksetzen des Passworts. Ohne dass du eine Zeile Code änderst.
Mail Queue kaufen [ zur Dokumentation ](https://b13.com/products/mail-queue-for-typo3/documentation)
Das Problem
-------------
Der eingebaute Spool von TYPO3 macht nicht das, was die meisten Teams von ihm erwarten.
**Mit** `MemorySpool`, der Voreinstellung, bekommt eine gescheiterte Mail drei weitere Versuche im Abstand von einer halben Sekunde. Danach ist sie weg. Das alles passiert im selben Request, im Destruktor eines Singletons. Ist dein Mailserver zwei Sekunden lang nicht erreichbar, gibt es die Mail nicht mehr. Übrig bleibt eine Logzeile mit der Exception: kein Empfänger, kein Betreff, kein Inhalt und keine Möglichkeit, die Mail noch einmal zu verschicken.
**Mit** `FileSpool` wird eine gescheiterte Mail in eine `.sending`-Datei umbenannt und bleibt liegen. Spätere Durchläufe fassen sie nicht mehr an. Sie wartet, bis jemand den Spool wiederherstellt, und von allein passiert das nicht. Die Exception bricht außerdem den laufenden Durchlauf ab, die übrigen Mails warten bis zum nächsten.
Beide zählen keine Versuche, beide unterscheiden nicht zwischen vorübergehenden und dauerhaften Fehlern, und keiner von beiden sagt dir, dass etwas schiefgegangen ist.
Davon merkt niemand etwas. Google antwortet mit `421 4.7.0 Try again later`, dein SMTP-Anbieter drosselt dich für 30 Sekunden, die API deines Mail-Dienstleisters antwortet nicht rechtzeitig — und die Registrierungsmail geht nie raus. Auf fällt das erst, wenn ein Kunde anruft.
### „Wir verschicken über Postmark, die kümmern sich um Wiederholungen.“
Die kümmern sich um die *zweite* Hälfte. Jeder Dienstleister wiederholt die Strecke **von sich zum Empfänger**, nachdem er deine Mail angenommen hat. Erreicht deine TYPO3-Instanz den Dienstleister gar nicht erst, wegen eines Netzwerkfehlers, eines API-Timeouts, eines HTTP 429 oder einer Störung bei ihm, hat er die Mail nie angenommen. Dann gibt es sie nirgendwo. Laut SMTP-Spezifikation muss bei einem vorübergehenden Fehler der sendende Client es erneut versuchen. In der PHP- und TYPO3-Welt macht das fast niemand.
Mail Queue ist keine Alternative zu deinem Dienstleister. Sie ist die fehlende Hälfte davor.
So funktioniert es
--------------------
Drei Zeilen Konfiguration, und im Alltag ändert sich nichts.
1. **Jede Mail geht sofort raus.** Kein Zwischenspeicher, keine Verzögerung, kein anderes Verhalten. Dein Code merkt nicht, dass es Mail Queue gibt.
2. **Scheitert eine Zustellung, landet die Mail in der Warteschlange**, statt zu verschwinden.
3. **Ein Cronjob verschickt sie in wachsenden Abständen erneut:** nach einer Minute, nach fünf, nach fünfzehn, nach einer Stunde, danach alle vier Stunden. Insgesamt bis zu 20 Versuche über rund 61 Stunden.
4. **Vorübergehende und dauerhafte Fehler werden unterschieden.** Bei einer 4xx-Antwort versucht Mail Queue es erneut. Eine 5xx-Antwort gilt sofort als gescheitert, denn eine abgelehnte Adresse noch einmal anzuschreiben, kostet nur Zeit.
5. **Im Backend siehst du das alles** und verschickst eine Mail mit einem Klick erneut.
Weil Mail Queue auf Transportebene arbeitet, erfasst sie alles, was über den Mailtransport von TYPO3 läuft: eigene Extensions, fremde Extensions, das Form Framework, die Passwort-Mails von felogin. Du musst keinen Code ändern und nichts pro Extension einrichten.
Fast jede gepflegte Extension nutzt den TYPO3-Mailer. Das ist seit Jahren der dokumentierte Weg. Was mit den wenigen Extensions ist, die selbst versenden, und mit Newsletter-Tools, steht in den FAQ.
Was du bekommst
-----------------
### Du siehst, was mit deiner Mail passiert ist — bevor der Kunde anruft
„Ist die Bestätigungsmail rausgegangen?“ Diese Supportfrage kann sonst niemand schnell beantworten. Mit Mail Queue öffnest du das Backend-Modul und siehst Betreff, Empfänger, Inhalt und Status. Du verschickst die Mail mit einem Klick erneut. War die Adresse vertippt, korrigierst du sie und schickst die Mail an die richtige Adresse, ohne dass etwas neu erzeugt werden muss.
### Eine Warnung, die nicht denselben Weg nimmt wie das Problem
Wird die Warteschlange rot, meldet sich ein Webhook, keine Warnmail. Denn eine Warnung, die denselben Weg nimmt wie der Fehler, ist keine Warnung: Ist SMTP kaputt, kommt auch die Warnmail nicht an. Der Webhook funktioniert mit Slack, Teams oder einem eigenen Endpunkt, und ein Ampel-Widget im TYPO3-Dashboard zeigt den Zustand auf einen Blick.
### Staging kann deine echten Kunden nicht anschreiben
Die Sperre „diese Umgebung verschickt niemals Mails“ steht in deiner Deployment-Konfiguration, nicht in der Datenbank. Der nächste Produktions-Dump auf Staging kann sie nicht heimlich aufheben.
Das ist wichtiger, als es klingt, denn die zwei üblichen Alternativen haben jeweils einen Haken. Ein Schalter im CMS, etwa `reroute_email` bei Drupal oder der Debug-Modus bei Magento, steht meist in der Datenbank. Ein Produktions-Dump bringt dann das Verhalten der Produktion direkt mit auf Staging. Ein Mailcatcher wie Mailpit ist dagegen sicher vor Dumps, weil du den Transport änderst und keine Datenbankzeile. Er braucht aber einen zusätzlichen Dienst neben deiner Anwendung, und die Mails liegen dann außerhalb von TYPO3. Wer wissen will, ob etwas verschickt wurde und was drinstand, muss woanders nachsehen.
`forceHold` ist genauso sicher vor Dumps wie ein geänderter Transport, braucht aber keinen zweiten Dienst. Alles bleibt in der Warteschlange, ist im Backend sichtbar und pro Mandant getrennt.
### Ein SMTP-Konto pro Mandant, auch beim erneuten Versuch
Laufen mehrere Mandanten auf einer Instanz, verschickt jeder über sein eigenes SMTP-Konto. Das gilt auch dann, wenn der erneute Versuch später per CLI läuft, ohne Request und ohne Site-Kontext. Die Zugangsdaten bleiben in deiner Deployment-Konfiguration und landen nie in der Warteschlange. Redakteure mit eingeschränkten Rechten sehen nur die Mails ihrer eigenen Site, und das prüft der Server.
### Deine Tester prüfen Mails in dem Backend, das sie schon kennen
Schalte `forceHold` auf Staging oder Integration ein, und keine Mail verlässt den Server. Trotzdem ist jede da. Projektleitung, QA und dein Kunde können Formulare ausfüllen, Registrierungen auslösen oder eine Buchung durchspielen und sich die echte Mail danach im selben TYPO3-Backend ansehen, in dem sie gerade gearbeitet haben: Betreff, Empfänger, vollständiger Inhalt, Header.
Kein Wechsel in ein anderes System, kein zusätzlicher Container, kein zweites Tool, das dokumentiert werden muss. Und niemand muss sich in ein Werkzeug einarbeiten, das er zweimal im Jahr braucht. Bei der Abnahme mit dem Kunden ist das der Unterschied zwischen „Ich besorge dir einen Zugang zu unserem Mailcatcher“ und „Schau in das Modul, das du gerade offen hast“.
Extra kostet das nichts: Staging, Test und lokale Installationen brauchen keine Lizenz.
### Deine Mail bleibt vollständig erhalten, samt Anhängen
Eine Mail in der Warteschlange bleibt komplett: Empfänger, Betreff, Header, Inhalt und jeder Anhang. Anhänge speichert Mail Queue auf der Festplatte statt in der Datenbank, damit ein 12 MB großes PDF deine Datenbank nicht aufbläht. Beim erneuten Versuch geht dieselbe Datei raus, keine neu erzeugte. Verschickst du die Mail Wochen später aus dem Backend noch einmal, bekommt der Kunde genau das, was du ihm beim ersten Mal geschickt hast.
### Ein Archiv, wenn du eins willst
Schalte den Archivmodus ein, und jede verschickte Mail bleibt samt Inhalt gespeichert, bis die Aufbewahrungsfrist abläuft. Damit kannst du jederzeit beantworten, ob eine Mail rausging und was drinstand, und sie aus dem Modul erneut verschicken. Die Fristen sind gestaffelt und einstellbar: 30 Tage für verschickte Mails, 90 für gescheiterte, 14 für Anhänge auf der Festplatte.
**Archivmodus und personenbezogene Daten.** Der Archivmodus speichert die Inhalte deiner Mails, und das sind fast immer personenbezogene Daten. Er ist standardmäßig aus, die Aufbewahrungsfrist legst du fest, und das Modul lässt sich auf vertrauenswürdige Benutzer beschränken. Wie auch immer du es einstellst: Nenn die Aufbewahrungsfrist in deiner Datenschutzerklärung.
Im Vergleich zum eingebauten Spool
------------------------------------
| | **TYPO3-Spool** | **Mail Queue** |
|---|---|---|
| Verschickt im Normalfall sofort | nein, puffert immer | **ja** |
| Zählt Versuche | nein | **ja** |
| Wachsende Abstände zwischen den Versuchen | no—`MemorySpool` tries 3× at 0.5s, in one request | **ja** |
| Unterscheidet 4xx und 5xx | nein | **ja** |
| Gibt nach n Versuchen auf | nein, unbegrenzt | **ja** |
| Setzt einen hängengebliebenen Versand fort | nur von Hand | **automatisch, nach Zeitplan** |
| Sichtbar im Backend | nein | **ja, delegierbar und mandantenfähig** |
| Erneut verschicken aus dem Backend | nein | **ja** |
| Warnung | nein | **Webhook und Dashboard-Widget** |
| Mehrere Transporte nebeneinander | nein | **ja** |
| Anhänge bleiben beim erneuten Versuch erhalten | nein | **ja** |
**Der Unterschied zeigt sich, wenn eine Zustellung scheitert.** Es gibt auch freie TYPO3-Extensions mit Warteschlange. Die, die Mail Queue am nächsten kommen, hängen sich ebenfalls an den Mailtransport und verschicken sofort. Bis dahin machen sie also dasselbe. Scheitert eine Zustellung, halten sie den Fehler fest und warten, bis ihn jemand bemerkt.
Mail Queue verschickt nach Zeitplan erneut, bis die Mail draußen ist. Sie unterscheidet vorübergehende von dauerhaften Fehlern, warnt dich über einen Kanal, der nicht vom Mailserver abhängt, hält jeden Mandanten auch beim erneuten Versuch auf seinem eigenen SMTP-Konto und lässt dich die Warteschlange an einen Redakteur übergeben, ohne ihm die ganze Instanz zu geben. Genau für diese Kombination ist Mail Queue gebaut.
**Falls dein Team überlegt, das selbst zu bauen:** Die Warteschlange steht an einem Wochenende. Der Rest nicht: die Abstandskurve, die Unterscheidung von 4xx und 5xx, Anhänge außerhalb des Docroots, die bei jedem Versuch wiederverwendet werden, ein Backend-Modul, das man bedienen kann und dessen Rechte der Server prüft, das richtige Absenderkonto in einem CLI-Durchlauf ohne Kontext und eine Warnung, die nicht über den kaputten Mailweg läuft. Das sind ein Dutzend Bausteine, die du einmal richtig bauen und dann mit jeder TYPO3-Hauptversion nachziehen musst.
Für wen Mail Queue gedacht ist
--------------------------------
**TYPO3-Agenturen mit Wartungsverträgen.** Jeder Vorfall mit Mails ist Supportzeit, die du entweder nicht abrechnen kannst oder erklären musst: Die Meldung kommt rein, jemand liest Logs, rekonstruiert, was passiert ist, verschickt die Mail von Hand und schreibt dem Kunden zurück. Mit Mail Queue ist derselbe Vorfall ein Blick ins Modul und ein Klick. Meistens meldet der Kunde ihn gar nicht erst, weil die Mail beim erneuten Versuch schon angekommen ist.
Der Webhook ist in der Regel schneller als dein Kunde: Du erfährst von der roten Warteschlange, bevor er die fehlende Mail bemerkt. Und das Modul kann unsichtbar bleiben. Vergib das Recht nicht, dann gehört es dir allein, und die Redakteure derselben Instanz sehen es gar nicht.
**Teams, deren Website Transaktionsmails verschickt.** Portale mit Login, Shops, Mitgliederbereiche, Bewerbungen, Kursbuchungen. Eine Passwort-Mail, die nicht ankommt, ist ein Supportfall. Eine Registrierungsbestätigung, die nicht ankommt, ist ein verlorener Nutzer. Eine Auftragsbestätigung, die nicht ankommt, ist eine Beschwerde.
**Betreiber mehrerer Mandanten auf einer Instanz.** Stadtwerke-Verbünde, Hochschulnetze, Franchisesysteme, Agenturen mit Multisite-Setups. Jeder Mandant behält sein eigenes Absenderkonto. Ein erneuter Versuch drei Stunden später geht also immer noch von der richtigen Adresse raus, und ein Redakteur der einen Site sieht nie die Mails der anderen.
**Konzern-IT und öffentliche Verwaltung.** Mails gehören zum Betrieb, und ein Ausfall ist ein Vorfall mit festem Meldeweg. Webhook-Anbindung an dein bestehendes Monitoring, abgestufte Rechte, getrennte Mandanten, festgelegte Aufbewahrungsfristen für personenbezogene Daten und eine klare Zusage für v13.4 LTS und v14. Das Backend-Modul gibt es auf Deutsch und Englisch, und jede Beschriftung lässt sich pro Installation überschreiben. Wer die Warteschlange bedient, liest sie also in seiner Sprache.
Im Einsatz
------------
Mail Queue läuft auf mehreren Kundenwebsites und auf unserer eigenen b13.com. Sie verschickt die Lizenzmails des b13 Marketplace: Wir setzen sie da ein, wo eine verlorene Mail einen bezahlten Kauf blockieren würde.
Systemvoraussetzungen
-----------------------
- TYPO3 v13.4.23 oder neuer, oder v14
- PHP 8.2 oder neuer
- Ein Cronjob im Minutentakt für erneute Versuche und die Webhook-Überwachung
- Ein täglicher Cronjob, der nach Ablauf der Aufbewahrungsfristen aufräumt
- Ein dauerhaftes, beschreibbares `var/`-Verzeichnis für Anhänge
- Optional: `typo3/cms-dashboard` für das Ampel-Widget und ein HTTP-Endpunkt für Webhook-Warnungen
Mail Queue funktioniert mit jedem Symfony-Mailer-Transport, den TYPO3 unterstützt, also SMTP, sendmail oder die API eines Dienstleisters, und bleibt kompatibel mit `mailer:spool:send`.
Installation
--------------
**Mit Composer über den b13 Marketplace, der empfohlene Weg.** Nach dem Kauf hast du in deinem Konto ein eigenes Composer-Repository. Zwei Befehle, Zugangsdaten in die `auth.json`, und Updates kommen wie bei jedem anderen Paket.
```
1
2
```
```
composer config repositories.b13 composer https:
composer require b13/mail-queue
```
**Oder als ZIP**, wenn dein Setup keinen Composer-Zugriff auf externe Repositories hat. Den Download findest du in deinem Konto, für ein Update ersetzt du den Ordner.
Danach folgen in beiden Fällen drei Zeilen Konfiguration, und `mailqueue:send-test` zeigt dir in unter einer Minute, dass alles funktioniert. Die Details stehen in der [Dokumentation](https://b13.com/products/mail-queue-for-typo3/documentation) (auf Englisch), auch zu den Cronjobs und den Einstellungen für Staging.
Updates und Pflege
--------------------
**Was wir zusagen.** Mail Queue unterstützt die aktuelle TYPO3-LTS spätestens acht Wochen nach ihrem Erscheinen und die vorherige LTS bis zu ihrem regulären Ende. Derzeit heißt das: v13.4 LTS und v14, beide aus demselben Paket. Du musst keinen Branch auswählen und nichts migrieren, wenn du TYPO3 aktualisierst. Endet unsere Unterstützung für eine Version, steht das vorher im Changelog, nicht hinterher.
**Warum wir dabei schnell sind: Wir sind selbst Kunde.** Mail Queue verschickt die Lizenzmails des b13 Marketplace, also die Mail mit deinen Composer-Zugangsdaten. Geht die verloren, hat jemand bezahlt und nichts bekommen. Außerdem kümmert sie sich um die Mails auf b13.com. Wir pflegen Mail Queue also nicht für einen Markt, den wir nur von außen kennen: Wir stoßen in derselben Woche auf dieselben Probleme wie du, auf denselben TYPO3-Versionen. Und ein Patchlevel, das etwas kaputt macht, macht es zuerst bei uns kaputt.
**Jedes Release steht mit Datum im öffentlichen** [**Changelog**](https://b13.com/products/mail-queue-for-typo3/changelog)**.** Lesen kannst du ihn auch ohne Lizenz.
Preis
-------
Ein Preis, alles enthalten.
Mail Queue wird pro Jahr und pro **Produktivinstanz** lizenziert. Eine Produktivinstanz ist eine TYPO3-Installation mit einer Codebasis und einer Datenbank. Wie viele Sites, Mandanten oder Absenderkonten darin laufen, ändert am Preis nichts. Staging, Test und lokale Installationen desselben Projekts sind abgedeckt.
### 1 Produktivinstanz
€490
netto , | jährlich
pro Instanz
Mail Queue kaufen
### 5 Produktivinstanzen
€1,750
netto , | jährlich
€350
netto , | jährlich
pro Instanz
### 10 Produktivinstanzen
€2,950
netto , | jährlich
€295
netto , | jährlich
pro Instanz
**Die Staffeln für 5 und 10 Instanzen richten wir direkt mit dir ein.** Sag uns, wie viele Produktivinstanzen du betreibst, und wir legen die Lizenz an. Alles auf dieser Seite ist in jeder Staffel enthalten.
**Was „alles enthalten“ heißt.** Sofortversand, wachsende Abstände zwischen den Versuchen, die Unterscheidung von 4xx und 5xx, das Backend-Modul, der Archivmodus, `forceHold`, Warnungen per Webhook. Dazu ein SMTP-Konto pro Mandant, auch beim erneuten Versuch per CLI, mit Sichtbarkeit pro Mandant und abgestuften Rechten. Beliebig viele Sites, beliebig viele Absenderkonten. Keine Funktion auf dieser Seite steckt hinter einer teureren Stufe.
**Eine Version, ein Preis.** Versand für mehrere Mandanten ist das Schwierigste, was Mail Queue macht, und jede Lizenz enthält ihn. Es gibt keine Edition, die ihn später freischaltet. Brauchst du mehr von uns, bekommst du das über eine Supportstufe, nicht über eine andere Version.
**Warum eine Jahreslizenz.** TYPO3-Patchlevel und Sicherheitsreleases kommen laufend, und Mail Queue muss mit ihnen Schritt halten, weil sie jeden Tag in deinem Mailversand steckt. Genau das deckt die Jahreslizenz ab.
**Für Einkaufsabteilungen**, die kein Jahresabo abwickeln können: eine mehrjährige Laufzeit, im Voraus bezahlt, mit kleinem Nachlass. Drei Jahre Mail Queue kosten 1.320 € statt 1.470 €. Eine Rechnung, festes Enddatum.
**30 Tage Geld zurück.** Lass Mail Queue einen Monat lang in Produktion laufen. Ist sie ihr Geld nicht wert, sag uns Bescheid, und wir erstatten den Preis. Ohne Bedingungen, ohne Formular.
### [ Florian „Flix“ Keitgen ](https://b13.com/de/team/florian-keitgen)
Product Development
### Questions?
Du brauchst mehr Instanzen oder hast eine andere Frage?
Sprich mit uns.
[ Kontakt aufnehmen ](https://b13.com/de/kontakt)
Support
---------
**In jeder Lizenz enthalten** sind Support per E-Mail, Fehlerbehebungen, Updates für neue TYPO3-Versionen und Sicherheitsfixes. Ein Postfach, eine Warteschlange. Anfragen, die deinen Betrieb aufhalten, ziehen wir vor. Du bekommst eine Vorgangsnummer und kannst jederzeit nach dem Stand fragen.
**Priority — 300 € pro Jahr und Lizenz.** Eine zugesicherte Antwort innerhalb eines Werktags und Fehlerbehebungen mit Vorrang.
**Enterprise — ab 990 € pro Jahr.** Reaktionszeiten nach Schweregrad, ein festes Servicefenster, ein Eskalationsweg und ein jährliches Abstimmungsgespräch. Individuell im Vertrag geregelt.
**Was der Support nicht abdeckt:** Installation und Konfiguration in deinem Projekt, Anpassungen an deinen speziellen Fall, Fehlersuche in deinem eigenen Code oder deiner Umgebung, Datenbereinigung und Schulungen. Pro Anfrage suchen wir bis zu eine Stunde nach der Ursache. Liegt sie außerhalb von Mail Queue, sagen wir dir, was wir gefunden haben und wo du weitersuchen kannst.
**Mail Queue läuft in deiner Instanz.** Eine Verfügbarkeit können wir dir deshalb nicht zusagen. Zusagen können wir, wann wir antworten.
Sicherheitslücken meldest du an [**security@b13.com**](mailto:security@b13.com). Wir lesen jede Meldung, antworten mit einer Einschätzung und stimmen mit dir einen Termin ab, bevor etwas veröffentlicht wird. Braucht dein eigener Prozess ein festes Datum, schreib das in die Meldung, dann vereinbaren wir eins.
FAQ
-----
### Verzögert Mail Queue meine Mails?
Nein. Im Normalfall verschickt sie sofort, genau wie vorher. In der Warteschlange landen nur Mails, deren Versand gescheitert ist.
### Wir nutzen schon Postmark, SendGrid oder Mailgun. Brauchen wir das trotzdem?
Ja, für einen anderen Teil der Strecke. Dein Dienstleister wiederholt die Zustellung an den Empfänger, *nachdem* er deine Mail angenommen hat. Erreicht deine Instanz ihn nicht, hat er die Mail nie angenommen, und niemand versucht es erneut. Genau diese Lücke schließt Mail Queue.
### Erfasst sie auch Mails aus Extensions, die wir nicht selbst geschrieben haben?
Ja, jede Mail, die über den Mailtransport von TYPO3 läuft. Auch die aus dem Form Framework und die Passwort-Mails von felogin, ohne dass du Code änderst. Das ist der dokumentierte Weg, in TYPO3 Mails zu verschicken, und fast jede gepflegte Extension nutzt ihn.
Nicht erfassen kann sie eine Extension, die am Mailer vorbeigeht: eine, die `mail()` direkt aufruft, eine eigene SMTP-Bibliothek mitbringt oder selbst mit der API eines Dienstleisters spricht. Das kann keine Lösung auf Transportebene auffangen, weil diese Mails den Transport nie erreichen. Außerdem bleiben zwei Dinge außen vor: Mails, die außerhalb von TYPO3 entstehen, etwa in einem Cron-Skript oder beim Mailserver deines Hosters, und ein fataler PHP-Fehler, bevor die Mail beim Transport ankommt.
### Wie finden wir heraus, ob eine Extension am Mailer vorbeigeht?
Durchsuche ihren Code nach `MailMessage` oder `MailerInterface`. Nutzt sie eins davon, ist sie erfasst. Findest du `mail(`, `PHPMailer` oder das SDK eines Dienstleisters, ist sie es nicht. Wir bauen gerade einen Befehl, der das für deine ganze Installation prüft. Bis es ihn gibt, frag uns, und wir sagen dir, wonach du suchen musst.
### Was ist mit Direct Mail und anderen Newsletter-Tools?
Das hängt von deinem Tool ab. Newsletter-Extensions verschicken unterschiedlich: Manche nutzen den TYPO3-Mailer, manche bringen einen eigenen Mechanismus mit, und das ändert sich auch zwischen Versionen.
Und selbst wenn ein Newsletter-Tool den Transport nutzt, willst du einen Newsletter-Versand wahrscheinlich nicht in der Warteschlange haben. Ein Versand an 50.000 Empfänger legt an einem schlechten Tag 50.000 Einträge samt Inhalt in die Warteschlange, und ein Newsletter, der zweieinhalb Tage zu spät kommt, ist weniger wert als einer, der gar nicht kommt. Mail Queue ist für Transaktionsmails gebaut: die Bestätigung, die Passwort-Mail, das Angebot. Dort zählt jede einzelne Mail, und ein Zeitfenster dieser Länge ist genau richtig. Sprich mit uns über dein Setup, bevor du dich festlegst.
### Gibt es das Backend-Modul auf Deutsch?
Ja, auf Deutsch und Englisch. Brauchst du eine weitere Sprache oder willst du eine Beschriftung für deine Redaktion ändern, überschreibst du sie pro Installation über `locallangXMLOverride`. Kein Fork, kein Patch.
### Werden die Inhalte unserer Mails gespeichert?
Nur, was für den erneuten Versuch nötig ist, und nur so lange wie nötig. Anhänge liegen auf der Festplatte statt in der Datenbank, damit eine große Datei die Warteschlange nicht aufbläht. Mit eingeschaltetem Archivmodus bleiben verschickte Mails samt Inhalt gespeichert, bis die Aufbewahrungsfrist abläuft. Das entscheidest du bewusst, und die Frist stellst du selbst ein.
### Was passiert, wenn die Lizenz ausläuft?
An deiner laufenden Installation ändert sich nichts. Der Code auf deinem Server funktioniert weiter, und nichts schaltet sich ab. Was endet, ist der Zugang zu neuen Releases: Unser Composer-Repository liefert dir keine Downloads mehr.
**Für deine Deployment-Pipeline heißt das:** Fährt sie bei jedem Build ein `composer install` gegen unser Repository, schlägt dieser Build nach Ablauf der Lizenz fehl. Deine Website läuft weiter, dein nächstes Deployment nicht. Der Code steht unter [GPL-2](https://b13.atlassian.net/browse/GPL-2?atlOrigin=eyJpIjoiYjM0MTA4MzUyYTYxNDVkY2IwMzVjOGQ3ZWQ3NzMwM2QiLCJwIjoianN3LWdpdGxhYlNNLWludCJ9 "Issue in Jira issues").0-or-later, die Kopien, die du schon hast, gehören also dir.
Deshalb gibt es eine Nachfrist: Schlägt eine Zahlung fehl, kannst du 13 Tage lang weiter Releases beziehen, während das geklärt wird. Eine Karte, die am Freitag abgelaufen ist, bricht dir also nicht am Montag das Deployment. Außerdem erinnern wir dich zweimal, bevor die Lizenz ausläuft.
### Ist das Open Source?
Der Code steht unter GPL-2.0-or-later, wie jede TYPO3-Extension. Du bezahlst für den Zugang zu den Releases, für Updates für neue TYPO3-Versionen, Sicherheitsfixes und Support. Lesen kannst du jede Zeile.
### Brauchen wir eine Lizenz für Staging- und Testsysteme?
Nein, die sind in deiner Produktivlizenz enthalten. Staging, Test, Integration und jede lokale Installation desselben Projekts sind abgedeckt. Gezählt werden nur Produktivinstanzen.
### Was zählt als eine Instanz?
Eine TYPO3-Installation mit einer Codebasis und einer Datenbank. Alles darin ist abgedeckt: beliebig viele Sites, Mandanten und Absenderkonten. Zehn Kundensites in einer Multisite-Installation sind eine Instanz. Zehn getrennte Installationen sind zehn. Dafür gibt es die Staffeln, sprich uns an.
### Können Redakteure alle Mails der Instanz sehen?
Nur, wenn du es erlaubst. Löschen und die Sperre für die ganze Instanz brauchen eigene Rechte. In Multisite-Setups sieht ein Redakteur mit eingeschränkten Rechten nur die Mails seiner eigenen Site, und das prüft der Server.
### Können wir Mail Queue erst ausprobieren?
Ja: Lass sie 30 Tage in Produktion laufen. Ist sie ihr Geld nicht wert, bekommst du es zurück. `mailqueue:send-test` zeigt dir direkt nach der Installation in unter einer Minute, dass alles funktioniert. Ab da testest du mit deinem echten Mailverkehr, und nur dieser Test sagt bei einer Warteschlange wirklich etwas aus.
### Was, wenn wir schon einen Spool nutzen?
Mail Queue bleibt kompatibel mit `mailer:spool:send`. Für den Umstieg änderst du die Konfiguration.
Schluss mit verlorenen Mails?
-------------------------------
Mail Queue ist an einem Nachmittag installiert und hat sich bezahlt gemacht, sobald sie die erste Mail auffängt, von der du nicht wusstest, dass sie gefährdet war.
Mail Queue kaufen [ Erst mit uns sprechen ](https://b13.com/de/kontakt)