Erstmal ein paar Sätze zu meinem beruflichen Hintergrund:

Seit Ende meines Studiums arbeite ich bei einem kleinen Unternehmen, welches IT-Forensik bzw. e-Discovery betreibt. Dort entwickle ich, zusammen mit meinen Kollegen, eine Pipeline zur Analyse von Kommunikationsdaten (Vorrangig in Python und Java). Ein wichtiges Merkmal unserer IT-Infrastruktur ist, dass unsere Server und Entwickler-PCs keinen Internetzugang besitzen. Zum Surfen und E-Mails schreiben haben alle Mitarbeiter einen zusätzlichen Laptop oder PC zur Verfügung. Jedes Programm muss also ohne Internetzugang funktionieren und darf auch keine externen Daten nachladen.

Was nach einer trivialen Anforderungen klingt, stellte sich z.B. beim Finden einer Alternative zu Jira als ein sehr großes Problem heraus. Wenn man rein auf OSS-Programme setzen will, kommt man irgendwann an einen Punkt an dem das Programm einen normalen Internetzugang verlangt (Weil z.B. Javascript-Bibliotheken von externen Servern nachgeladen werden). In der Welt von nahezu allen OSS-Entwicklern gibt es anscheinend die Einstellung, dass jeder Server einen Zugang zum Internet haben muss, egal wie sensibel die darauf abgelegten Daten auch sein mögen. Das ist aber ein anderes Thema.

Das Problem

Ich suchte eine einfache und unkomplizierte Möglichkeit die diversen Statusnachrichten unserer Server bzw. NAS an einer zentralen Stelle zu sammeln.

Einfach und unkompliziert heißt folgendes:

1. Kein SNMP, da dessen Einsatz den Kosten/Nutzenfaktor in unserem kleinen Netzwerk übersteigt. Unsere Infrastruktur ist aktuell noch recht überschaubar (Ca. ein Dutzend Server und NAS).
2. Kein interner Mail-Server, da er auch zu pflegen und er nur für den Versand und Empfang von Statusmeldungen vorhanden wäre. Dazu käme dann noch ein E-Mail-Client auf meinem Rechner, der nur für diese Meldungen da wäre und sonst nichts weiteres.
3. Die einzelnen Programme sollten einfach so ihre Statusmeldungen versenden können, ohne dass man den Quellcode verändern muss.

Die Lösung

Da wir zur internen Kommunikation RocketChat einsetzen, lag es nahe die Statusmeldungen direkt an diesen Server zu senden. Leider konnte ich keine Software finden, welches es ermöglicht auf einfache Weise eine E-Mail an einen RocketChat-Server zu senden. Es gibt zwar Tools, welche z.B. nach Nachrichten auf normalen E-Servern lauschen und diese dann an RocketChat weiterleiten. Aber das führt dann wieder zu Ausschlusskriterium #2 (Kein zusätzlicher E-Mail-Server).

Am Ende blieb mir nichts anderes übrig als das Gateway selbst zu programmieren. Ich wollte dies zuerst in Python erledigen, da es eine brauchbare API für RocketChat gibt. Leider hat Python immer noch Riesenprobleme, wenn es um die Handhabung von EML-Dateien (Sprich E-Mails) und UTF-8 geht (Die Kodierung eines HTML-formatierten E-Mail-Body löste reproduzierbar eine Exception aus, welche ich nicht ohne Weiteres beseitigen konnte).

Der einzig sinnvolle Weg war die Teile der RocketChat-API in Java zu implementieren, welche ich zwingend benötigte (Senden von Nachrichten und Anhängen an einzelne Benutzer oder Gruppen). Unter Java hatte ich nämlich noch nie Probleme beim Verarbeiten von E-Mails (Die Zahl der verarbeiteten E-Mails in unserer Pipeline dürfte sich langsam auf eine Milliarde zubewegen).

Zusätzlich gibt es in Java eine sehr gute Bibliothek namens SubEthaSMTP bzw. deren Fork zum Implementieren eines SMTP-Servers:

https://github.com/davidmoten/subethasmtp

Der Riesenvorteil an dieser Bibliothek ist, dass sie sehr einfach einzusetzen ist und sie auch die Möglichkeit anbietet eine Authentifizierung zu aktivieren (z.B. Benutzername und Passwort). Denn einige Programme oder Serverdienste (z.B. TrueNAS) verlangen einen Benutzernamen und ein Passwort beim Einrichten der SMTP-Verbindung. Auch SSL bzw. TLS stellen in Verbindung mit einer Zusatzbibliothek kein großes Problem dar.

Das Gateway macht am Ende nichts anderes als einen SMTP-Server bereitzustellen und die ankommenden E-Mails je nach Empfänger an den passenden RocketChat-Benutzer oder die passende Gruppe weiterzuleiten. Dabei werden HTML-Nachrichten in Textnachrichten konvertiert und die originale HTML-Nachricht als Datei versendet. Das wurde deshalb so implementiert, da RocketChat aus Sicherheitsgründen keine HTML-Nachrichten darstellen kann und der Markdownparser nicht alle benötigten Tags (z.B. Tabellen) unterstützt. Normale Dateianhänge werden ebenfalls als Datei versendet.

Zwei Voraussetzungen hat das Gateway:

1. Man muss einen Bot-Nutzer auf dem RocketChat-Server anlegen.
2. Dieser muss das Recht haben die E-Mail-Addressen aller Benutzer auszulesen. Am besten legt man dafür eine zusätzliche Bot-Gruppe an, welche nur vom Gateway-Bot benutzt wird.

Optional kann eine „spam“-Gruppe angelegt werden. Dort landen dann, wenn man möchte, alle E-Mails deren Empfänger nicht bekannt ist. So sieht man sehr schnell, bei welchen Diensten man noch nachbessern muss.

Jetzt reicht es in den jeweiligen Programmen bzw. Webdiensten den SMTP-Server des Gateways und eine passende Empfängeraddresse anzugeben um E-Mails als RocketChat-Nachrichten zu empfangen.

Download des Programms

Ich habe das Gateway auf meinem Github-Account gehostet:

https://github.com/glasen/rocketgateway