Der Kunde setzt seit einigen Jahren für interne Testzwecke MailHog ein um den Versand von Mails prüfen zu können ohne dass diese auf echte Postfächer zugestellt werden müssen. Hierfür bieten sich sogenannte Fake-SMTP Server an, welche einen SMTP Dienst bereitstellen, die Mails dann aber nicht weitervermitteln, sondern speichern und auf einer extra Oberfläche darstellen. Dabei ist es nicht wichtig welche Emailadresse verwendet wird, da sowohl Absender, als auch Empfänger in der Oberfläche sichtbar sind und damit überprüft werden kann, ob die Adressen wie im Test definiert auch in den Mails verwendet werden.

Als einer der Standard-Tools hat sich MailHog etabliert, da es recht einfach vom Aufbau ist und auch gut in Docker-Containern verwendet werden kann. Es gibt eine API-Schnittstelle, die von Tests angesprochen werden kann, um automatisiert die Mails zu überprüfen.

Schaut man sich aktuell die Stände auf Github an, fällt auf, dass MailHog seit einigen Jahren nicht mehr aktualisiert wurde. Das stößt natürlich bei Security-Meetings schlecht auf.

Zudem wächst in den besagten Tests die Menge der versandten Emails und MailHog kommt ohne Datenbank langsam aber sicher an seine Grenzen. Eine Datenbank wäre natürlich möglich, hat sich aber wegen der Infrastruktur des Kunden nicht wirklich angeboten. Durch die Speicherung im Arbeitsspeicher kommt es regelmäßig, gerade zu Test-Stoßzeiten zu Out-Of-Memory Fehlern und in Folge zu Abstürzen des Containers.

Gerade der letzte Punkt hatte uns als Entwickler-Team am meisten Sorgen bereitet, da nicht absehbar ist, dass die Menge der Mails wieder sinkt. Im Gegenteil wird in Zukunft noch mehr getestet in diese Richtung.

Mit dem Problem des verwaisten MailHogs sind wir nicht alleine. Es gibt zahlreiche Alternativen, die aktueller und häufig ein Fork vom MailHog sind.

Am Besten hat uns allerdings MailPit gefallen. Das ist kein direkter Fork von MailHog, hat aber viele Ähnlichkeiten und lässt sich sehr einfach von der Mail-Anzahl beschränken. Zudem werden Mails in einer Datei gespeichert und nicht wie im MailHog im Arbeitsspeicher.

Auf die Bewertung anderer Alternativen möchte ich hier nicht eingehen, da hier sehr viele Kriterien vom Kunden mit reingespielt haben und diese Entscheidung je nach Projekt durchaus sehr unterschiedlich ausfallen kann.

MailPit gibt es im Docker-Hub schon als fertigen Container. Also muss man sich darum schonmal nicht selber kümmern. Noch eine Konfiguration eingestellt, für die Anzahl der maximalen Mail-Menge und der Datei, die genutzt werden soll und fertig ist der MaiPit für den Einsatz im Projekt.

Es fiel aber auf, dass es sich eben nicht um einen Fork des MailHog Projektes handelte, sondern um eine mehr oder weniger eigenständige Entwicklung. Auch wenn die Oberfläche sehr ähnlich ist waren vor allem API Anpassung notwendig, da die Entitys sehr unterschiedlich waren.

Tatsächlich war dies auch der größte Aufwand und dank einer guten Dokumentation der MailPit Entwickler auch schnell angepasst.

Der Wechsel war insgesamt glatt über die Bühne. Der größte Aufwand war die API Anpassung an die neue Schnittstelle, welche allerdings auch ein paar neue Features mit sich brachte.

Die Oberfläche ist sehr ähnlich zu MailHog, lässt durch ein paar Features mehr aber auch Raum für weitere Entwicklung, zB durch die Analyse der HTML-Kompatibiltätsanalyse einzelner Browser.

Durch die regelmäßige Löschung von Mails über dem Maximum läuft unser Arbeitsspeicher nicht mehr voll und Abstürze des Containers sind selten geworden. Insgesamt trägt der Wechsel immens zur Stabilität der Tests bei und wird auch von anderen Teams schon in Betracht gezogen, die ähnliche Erfahrungen gemacht haben.