Ein Catch-all-Postfach ist die einfachste denkbare Antwort auf ein Staging-Problem: Statt für jede Adresse, die eine Umgebung brauchen könnte, ein Konto anzulegen, weisen Sie die Domain an, alles an ein einziges Postfach zu geben. Jeder lokale Teil wird angenommen, nichts muss vorab eingerichtet werden, und ein Testdatensatz, der eine Adresse spontan erfindet, funktioniert weiterhin. Die Bequemlichkeit ist echt, und die Kosten sind es auch – sie zeigen sich meist ein paar Wochen nach dem Umlegen des Schalters.
Was ein Catch-all-Postfach tatsächlich tut
Jede Domain muss einen Eintrag veröffentlichen, der den Server benennt, der Mail für sie annimmt. Das gilt für alle Mail gleichermaßen. Was ein Catch-all hinzufügt, ist eine Regel am annehmenden Ende: Trifft eine Nachricht für einen lokalen Teil ein, zu dem es kein Postfach gibt, wird sie nicht zurückgewiesen, sondern an ein benanntes Postfach zugestellt.
Entscheidend ist der Unterschied zwischen einem Platzhalter und einem Standardfall. Manche empfangenden Systeme nehmen alles an und sortieren danach; andere nehmen alles nur dann an, wenn nichts Spezifischeres passte. Beide verhalten sich gleich, wenn ein Test eine neue Adresse erfindet, und sie verhalten sich sehr unterschiedlich, wenn eine Nachricht für eine Adresse eintrifft, die Sie absichtlich gesperrt haben.
Warum greifen Staging-Teams danach?
Das Motiv ist fast immer Reibung. Überlegen Sie, was ein Catch-all beseitigt:
- Kein Bereitstellungsschritt, bevor ein Test laufen kann, ein neuer Fall braucht also kein neu angelegtes Postfach.
- Keine Abstimmung zwischen Teams, weil jede Adresse der Domain für alle funktioniert.
- Keine Abhängigkeit von einem externen Mailanbieter, da die ganze Domain unter Ihrer Kontrolle steht.
- Keine verlorene Mail, wenn ein Test eine Adresse mit zufälliger Bezeichnung erzeugt – und genau das tun Tests.
Für ein Team, das seinen Tag damit verbringt, Fehler wegen fehlender Postfächer zu triagieren, sieht ein Catch-all wie ein Heilmittel gegen eine ganze Klasse von Rauschen aus. Die Frage, die sich lohnt, ist, gegen welches Rauschen es eingetauscht wird.
Was geht schief, wenn alles in einem Postfach landet?
Vor allem Menge und Vertraulichkeit, und beide verstärken einander.
| Risiko | Warum es entsteht | Was es kostet |
|---|---|---|
| Unbegrenzte Menge | Jede Adresse der Domain wird angenommen | Der Speicher füllt sich, das Postfach wird unlesbar |
| Vermischter fremder Verkehr | Tests und Dienste teilen ein Ziel | Fehler lassen sich kaum noch zuordnen |
| Versehentlicher Fang echter Mail | Eine Domain wird wiederverwendet oder vertippt | Die Nachricht einer echten Person liegt in einer Testablage |
| Aufbewahrung ohne Verantwortlichen | Niemand verantwortet ein geteiltes Postfach | Daten bleiben lange nach dem Lauf liegen |
Die dritte Zeile ist die, die ernst zu nehmen ist. Eine im Staging genutzte Domain ist eine Domain, die irgendwann in einer Konfiguration, in einem Screenshot, in einem Support-Ticket oder in einem Bounce auftaucht. Sobald eine echte Nachricht dieses Postfach erreichen kann, ist aus dem Catch-all keine Testbequemlichkeit mehr geworden, sondern ein herrenloses Postfach mit fremder Korrespondenz.
Es gibt einen vierten Fehler, der leiser ist als die übrigen: ein Catch-all, das in der falschen Zone konfiguriert wurde. Wird die Regel auf eine geteilte Domain statt auf eine reine Staging-Subdomain angewendet, können interne Benachrichtigungen und administrative Mail in einer Ablage landen, die niemand beobachtet – ein Vertraulichkeitsproblem und zugleich ein Verlässlichkeitsproblem, wenn die Nachricht eigentlich an eine echte Stelle gehen sollte.
Produktionsmail aus einem Staging-Postfach heraushalten
Die Regel, um die herum zu entwerfen ist, passt in einen Satz: Staging darf niemals Mail empfangen können, die an einen Produktionsnutzer adressiert ist. Alles andere ist Umsetzung.
Die praktische Form dieser Regel ist eine eigene Domain oder Subdomain, deren einziger Zweck Testverkehr ist, zusammen mit einer Prüfung, wo diese Domain überall referenziert wird. Insbesondere Alarmierung, Abrechnung und Benachrichtigungskonfiguration sollten auf Adressen dieser Domain nur in Staging-Umgebungen zeigen, und der Unterschied zwischen Umgebungen sollte aus der Konfiguration kommen und nicht aus einem manuellen Schritt, an den sich jemand erinnern muss.
Aufbewahrung und Aufräumen als Designentscheidung
Ein geteiltes Postfach ohne Aufbewahrungsregel wird zu einem wachsenden Haufen, den niemand lesen kann und den niemand zu löschen wagt. Entscheiden Sie zwei Dinge vorab: wie lange eine eingefangene Nachricht bleibt und was am Ende dieses Zeitraums geschieht.
Eine kurze Aufbewahrung ist für alle freundlicher. Eine Testablage, die sich selbst leert, hält die Menge begrenzt, lässt vertrauliche Inhalte nicht herumliegen und macht das Postfach nach einer lauten Woche wieder lesbar. Wie lang das Fenster auch ist, es sollte eine dokumentierte Eigenschaft der Staging-Umgebung sein und nicht der Zufall einer volllaufenden Festplatte. Wenn Sie nicht sagen können, wie lange eine Nachricht überlebt, haben Sie noch keine Regel.
Für Entwickler: Routing nach Präfix und Begrenzung des Schalters
Die günstigste Verbesserung an einem Catch-all ist, es nicht länger als undifferenzierten Eimer zu behandeln. Weil der lokale Teil des Empfängers mit der Nachricht erfasst wird, können Sie darauf routen: Geben Sie jedem Test oder jedem Dienst ein eigenes Präfix und lassen Sie den lesenden Code nach diesem Präfix filtern statt nach der Reihenfolge des Eintreffens.
Begrenzen Sie dann, wie weit der Platzhalter reicht. Bevorzugen Sie eine Regel, die eine bekannte Menge von Mustern annimmt und alles andere zurückweist, gegenüber einer Regel, die alles annimmt. Eine Positivliste kostet Sie eine Konfigurationszeile pro neuem Nutzer und entfernt die gesamte Klasse des versehentlichen Fangs, weil eine Adresse, die niemand registriert hat, abgelehnt statt aufgesogen wird.
Behandeln Sie das Catch-all schließlich als Umgebungseinstellung und nicht als dauerhafte Eigenschaft des Mailsystems. Wird dieselbe Konfiguration überall angewendet, weil das einfacher ist als sie zu variieren, greift die Staging-Anordnung irgendwann an einer Stelle, an der sie nicht greifen sollte. Der Artikel darüber, was eine Wegwerf-E-Mail-Adresse ist, behandelt dasselbe Prinzip für die Adressen, mit denen eine Umgebung arbeitet.
Wer dieses Muster nutzt, sollte den Zweck im Blick behalten. Ein Catch-all ist hier Technik für Testverkehr und keine Identität, und es darf niemals als Postfach einer echten Person behandelt werden.
Nächste Schritte
Öffnen Sie die Konfiguration, die Ihre Staging-Domain definiert, und beantworten Sie eine Frage: Was geschieht mit einer Nachricht an eine Adresse, die noch kein Test benutzt hat? Wenn die Antwort lautet, dass sie im geteilten Postfach landet, verengen Sie die Regel. Wenn Sie ein einzelnes Wegwerf-Postfach statt einer Domain brauchen, erzeugt die Seite für temporäre E-Mail eines auf Anforderung, und der Artikel über das Abfangen von Mail in der Pipeline erklärt die Variante, die die Build-Maschine überhaupt nicht verlässt.