Ein Registrierungsablauf gilt erst dann als getestet, wenn die Bestätigungsnachricht zugestellt wurde und der enthaltene Link funktioniert. Ein Mock des Mailversands prüft lediglich, ob die Anwendung eine Nachricht versenden wollte, nicht jedoch deren Zustellung. Öffentliche Wegwerfdienste eignen sich ebenfalls nur bedingt. Registrierungsformulare können deren Domains ablehnen, die Dienste können die Anfragerate begrenzen, und die Testdaten verlassen die eigene Infrastruktur.
Ansatz
Der hier beschriebene Dienst stellt eine Mail-Domain mit einer REST-API bereit.
Ein Test legt per POST ein Postfach an und erhält eine zufällig erzeugte,
eindeutige Adresse wie 3f9a1c2e@example.com. Mit dieser Adresse durchläuft
der Test die Registrierung und ruft die Nachricht anschließend über die API ab. Nach 24 Stunden läuft das Postfach ab.
Architektur
Postfix nimmt Nachrichten ausschließlich für die konfigurierte Domain an und leitet sie per LMTP an die Anwendung weiter. Ausgehender Versand ist deaktiviert.
relay_domains = example.com
relay_transport = lmtp:inet:app:10024
default_transport = error:outbound disabled
LMTP ist das Protokoll für die Übergabe von einem Mailserver an ein Postfachsystem (RFC 2033 ). Es entspricht weitgehend SMTP, verzichtet jedoch auf eine Warteschlange beim Empfänger. Warteschlange, TLS und Wiederholungen verbleiben bei Postfix. Die Anwendung entscheidet lediglich über Annahme und Speicherung.
Der LMTP-Empfänger basiert auf aiosmtpd und läuft im selben Prozess wie die FastAPI-Anwendung. Beide greifen auf dieselbe SQLite-Datenbank zu.
Annahme und Ablehnung
Postfix verfügt über keine Kenntnis der Postfächer. Die Entscheidung trifft die
Anwendung bereits bei RCPT TO, also vor der Übertragung des Inhalts.
Unbekannte und abgelaufene Adressen werden mit 550 No such user here abgelehnt
(RFC 5321 ).
Zwischen RCPT TO und DATA kann die Bereinigung das Postfach löschen. Das
Speichern scheitert in diesem Fall am Fremdschlüssel, und die Anwendung
antwortet mit 451 Try again later:
except aiosqlite.IntegrityError:
return REPLY_TRY_LATER
Postfix wiederholt die Zustellung, und beim erneuten Versuch lehnt RCPT TO
endgültig ab. Die Fehlerbehandlung erfolgt damit über die Antwortcodes des
Protokolls, eine eigene Wiederholungslogik ist in der Anwendung nicht
erforderlich.
Lebensdauer der Postfächer
Ein abgelaufenes Postfach ist für API und Empfänger unmittelbar nicht mehr
erreichbar, auch wenn es noch in der Datenbank vorhanden ist. Eine periodische
Bereinigung entfernt abgelaufene Postfächer, die zugehörigen Nachrichten werden
per ON DELETE CASCADE mitgelöscht.
DNS-Konfiguration
Für die Domain sind folgende Einträge gesetzt.
| Eintrag | Zweck |
|---|---|
| MX | Ziel der Zustellung für die Domain |
SPF -all | kein Server ist zum Versand im Namen der Domain berechtigt |
DMARC p=reject | Nachrichten mit gefälschtem Absender werden abgewiesen |
| MTA-STS, TLS-RPT | Zustellung per TLS, Berichte bei Fehlern |
Die Einträge folgen den Spezifikationen für SPF (RFC 7208 ), DMARC (RFC 9989 ), MTA-STS (RFC 8461 ) und TLS-RPT (RFC 8460 ). SPF und DMARC dienen hier dem Schutz vor Missbrauch der Domain. Da der Server keine Nachrichten versendet, ist jede Nachricht mit dieser Absenderdomain gefälscht.
Verwendung im Test
Ein Test benötigt drei Aufrufe. Er legt das Postfach an, fragt es ab, bis eine Nachricht vorliegt, und ruft diese anschließend ab.
API=https://tempmail.example.com/v1
curl -X POST $API/emails \
-H "X-API-Key: $API_KEY"
curl $API/emails/3f9a1c2e@example.com/messages \
-H "X-API-Key: $API_KEY"
curl $API/messages/f47ac10b-58cc-4372-a567-0e02b2c3d479 \
-H "X-API-Key: $API_KEY"
Die letzte Antwort enthält Text- und HTML-Teil getrennt, aus denen der Test den Link oder Code entnimmt.
Einschränkungen
Der Dienst ist ausschließlich für Tests vorgesehen. Er empfängt nur und speichert keine Nachricht über den Ablauf des Postfachs hinaus. Die API bietet keinen Aufruf, der auf eine Nachricht wartet, der Test fragt daher in Abständen ab. Für Bestätigungsnachrichten, die innerhalb weniger Sekunden zugestellt werden, ist dieses Vorgehen ausreichend.
Fazit
Der Dienst schließt die Lücke zwischen gemocktem Versand und tatsächlicher Zustellung. Tests prüfen damit die Nachricht, die ein Nutzer erhalten würde.