Einen All-inclusive-Mailserver versprechen die Macher von Mail in a Box. Damit auch unbedarfte User damit elektronische Post verschicken, soll er auch einfach aufzusetzen sein. Das macht neugierig: E-Mail-Kenner Patrick Koetter wirft für das Linux-Magazin einen ausführlichen Blick in den Briefkasten.
Mail in a Box[1] ist ein All-in-one-Mailserver mit Support für SMTP, POP, IMAP, dazu Antispam, Kalender- und Adressbuchfunktion sowie ein Webmail-Client. Dienste sichert er über eigene oder Let’s-Encrypt-Zertifikate [2] und sogar DANE/DNSSEC [3] ab.
Joshua Tauberer rief das Projekt 2013 gemeinsam mit Mitstreitern ins Leben. Es richtet sich ausdrücklich an Laien, die dennoch “einen guten Mailserver” betreiben wollen. Mail in a Box will dezentralisieren, zugleich innovativ sein und die Privatsphäre verbessern. Konsequenterweise erscheint die Software unter Public-Domain-Lizenz (CC0 1.0) – alle Rechte gehen an die Öffentlichkeit.
Unboxing
Mail in a Box verspricht eine einfache Konfiguration und setzt diese in einer umfassenden Setup-Routine um. Der User lädt dazu ein Skript über die Website des Projekts herunter und übergibt dieses per Pipe an »sudo« und die Bash eines Ubuntu Servers.
Wer die Installation so ausführt, beobachtet als Erstes, wie Mail in a Box »git« installiert. Anschließend holt das Skript das Who is Who der Mailserver-Software auf die Maschine (Abbildung 1): Postfix für SMTP, Dovecot für POP und IMAP, Spam Assassin gegen zu viele Aluleitern und Generika sowie Open DKIM (Domain Keys Identified Mail, [4]) und Open DMARC (Domain-based Message Authentication, Reporting & Conformance, [5]) für Identitätsschutz und gegen Phishing. Damit steht das Grundgerüst.

Abbildung 1: Mail in a Box holt beim Installieren das Who is Who der Mailserver-Software auf den Rechner.
Mail in a Box zieht dann Pakete für den Webmail-Client Roundcube [6], die Kalender- und Adressbuchkomponenten des Owncloud-Projekts und last but not least Munin [7], das Web-gestützt die wesentlichen Systemparameter überwacht.
Aufsatteln
Im nächsten Schritt individualisiert Mail in a Box seine Auswahl. Im Terminal fragt es nach der gewünschten Mailadresse und dem Dienstnamen der eigenen Box (Abbildung 2) und taucht dann noch einmal ab, bis es sich nach abgeschlossener Konfiguration wieder meldet. Es teilt dem Nutzer die IP-Adresse des Webservers mit, unter der er sich nun anmelden kann. Außerdem kündigt es eine Warnmeldung an, die der Browser gleich von sich geben wird: Das Projekt betreibt den Webserver mit einem selbst signierten Zertifikat (Abbildung 3). Dies kann der Browser nicht verifizieren.
Bis auf Roundcube und Owncloud integriert die Software alle Komponenten über eine eigene Managementsoftware. Vor dieser sitzt eine Webapplikation, über die dann wiederum Mail-in-a-Box-Admins die Plattform verwalten und konfigurieren. Fortgeschrittene erhalten die Möglichkeit, Mail in a Box auch an der Webapplikation vorbei direkt über HTTP-Kommandos zu steuern.
Vom Aufruf der Setup-Routine bis zum ersten Login in die Webapplikation vergehen nur Minuten. Nach dem Anmelden warten aber weitere Arbeitsschritte. Mail in a Box listet in seinen System-Status-Checks auf, was der frischgebackene Mailserver-Admin noch erledigen müsste oder könnte. Passwort-gestützte SSH-Logins merkt es ebenso zur Änderung an wie die Delegation der Maildomain an einen externen DNS-Dienst.
DNS-Dienst
SMTP ohne DNS ist zwar möglich, in der Regel wollen Admins das aber nicht. Automatisiertes Routing von Nachrichten, die Abfrage von Blacklists und Methoden wie DKIM, DMARC und DANE nutzen das DNS-Protokoll intensiv. Zeitgemäßes SMTP ist daher ohne gut konfiguriertes DNS mit “den richtigen Einträgen” nicht denkbar. So gesehen wundert es nicht, dass Mail in a Box das DNS der Maildomain am liebsten selbst verwalten möchte. So hat es die maximale Kontrolle über den Maildienst und kann das Leben des Mail-in-a-Box-Betreibers ein weiteres Mal vereinfachen.
Dazu betreibt es auf der Box den DNS-Server NSD (Name Server Daemon) und konfiguriert ihn mit passenden Einträgen für DKIM und DMARC. Für Nutzer, die DNSSEC für ihre Domain aktivieren, um DANE over SMTP zu machen, setzt es sogar TLSA-Records. Für darüber hinausgehende Einträge bietet die Webapplikation die Möglichkeit, zusätzliche eigene DNS Resource Records zu setzen. Wer sein DNS lieber extern betreibt, dem zeigt Mail in a Box auf einer eigenen Seite, welche Einträge es im externen DNS für einen reibungslosen Betrieb erwartet.
Sicher unterwegs
Ist DNS wunschgemäß eingerichtet, steht das Thema TLS-Zertifikate an. Die Transportverschlüsselung setzt diese voraus, sie bildet die Grundlage für Privatsphäre und eine sichere Übertragung von Benutzernamen und Kennwörtern – besonders wichtig im Always-und-Everywhere-Zeitalter der mobilen Clients.
Nach der Installation verfügt Mail in a Box auch über selbst signierte Zertifikate, doch diese schmecken den Browsern nicht, weil sie nicht nachvollziehen können, wer sie ausgestellt hat und ob es sich um eine vertrauenswürdige Instanz handelt. Wer möchte, lässt sich in der Box eigene Schlüssel und Zertifikatsanträge generieren und ergänzt damit das vorhandene Zertifikat.
Mail in a Box integriert aber auch Let’s Encrypt in seine Managementoberfläche und vereinfacht das Verfahren, an öffentlich gültige Zertifikate zu gelangen, damit sehr. Nach nur drei Mausklicks – Beantragen, Bestätigen, Installieren – nutzt die Box kostenlose LE-Zertifikate.
Ebenso einfach gestaltet sich das Einrichten des Mailclients. Mail in a Box bietet eine Autokonfiguration für alle gängigen Desktop-Clients an. Dazu genügt es, einfach die E-Mail-Adresse und das Passwort im Client einzugeben (Abbildung 4). Die Box liefert auf Anfrage der Clients vordefinierte Konto-Einstellungen zurück und mit einem weiteren Mausklick richtet der Admin das neue Konto ein.
Die Welt wäre ein schönerer Ort, wenn es jetzt auch noch Mailclients für Mobilgeräte gäbe, die auch Autokonfiguration beherrschen. Leider sind diese ausgerechnet auf jener Gerätegattung, bei der jedes Zeichen mühsamst ertippt werden will, Mangelware. Die Hersteller interessiert Automatisierung nicht. Sie spezialisieren Clients für die eigene Plattform oder lassen Anbieter von Plattformen zahlen, um deren Profil auf dem Client vorzuinstallieren.
Wer privat E-Mail hosten und auf dem Mobilgerät nutzen will, muss selber ran. Gut dass Mail in a Box seine Dienste konsequent über verschlüsselnde Ports anbietet. So kommen auch diese Nutzer nicht in Versuchung, auf jene Sicherheit verzichten zu wollen, die sie in offenen Netzen vor der ungeschützten Übermittlung ihrer Anmeldedaten bewahrt.
Und jetzt? Allet schick?
Beim ersten Anmelden fordert der Installer schließlich dazu auf, eine IP-Adresse anzuklicken. Trotz Let’s Encrypt verschwinden dann aber die Warnungen im Browser nicht. Das ändert sich erst, wenn der Nutzer statt der IP den Hostnamen der Box angibt. Eigentlich logisch, aber wer denkt bei so viel “an die Hand nehmen” durch das Projekt selbstständig? Hier wäre ein Reload, der den Browser nach dem Installieren des Zertifikats zum Host leitet, eine hilfreiche Sache.
In dieselbe Falle geht die fehlende Anbindung des Roundcube-Clients an das Owncloud-Adressbuch. Sie würde die Integration zu einer runden Sache machen. Die Adressen im Smartphone sind dieselben wie im Owncloud-Adressbuch, sind dieselben wie im Webmail-Client und anders herum. Jammern auf hohem Niveau womöglich, aber genau diesen hohen Grad an Integration streben die Macher des Projekts an.
Auch der Verweis auf ein Howto für freie, Secondary-DNS-Server [8] hinterlässt einen faden Beigeschmack. Die dort empfohlenen Server befinden sich alle in den USA. Das massiv in die Privatsphäre eingreifende Verhalten der amerikanischen Behörden und der Ort für das Hosting von DNS passen nicht ganz zum Streben des Projekts nach Dezentralisierung, Privatsphäre und Sicherheit.
Sicher lassen sich diese Probleme einfach überwinden. Niemand ist gezwungen, sein DNSSEC unmittelbar vor den Toren der NSA aufzubauen, und Diskussionen darüber bewegen sich schnell zwischen Akademie und Glaubensbekenntnis. Dennoch muss sich Mail in a Box diesen Fragen stellen, denn die Box ist eben auch ein politisches Statement.
Schwieriger wird es – und das dürfte langfristig über den Erfolg des Projekts entscheiden –, Fragen zur Installation und des Betriebs von Mail in a Box in den Griff zu bekommen.
Die Software setzt ein frisch installiertes Ubuntu 14.04 LTS voraus, sonst scheitert die Installation. Überhaupt empfiehlt es sich, dem Setup-Guide sklavisch zu folgen. Wer – und das ist der Eindruck aus mehreren Versuchsreihen – nur ein Jota vom rechten Pfad abweicht, läuft Gefahr, viel Zeit in einer aufgehängten Installationsroutine zu verbringen.
Diese bringt keine Timer mit und bricht daher auch nicht ab, wenn die Installation nicht wie erwartet vorankommt. Praktisch wäre daher auch ein Log, das beschreibt, welche Aktionen der Installer bereits umgesetzt hat und was seine letzten Worte vor dem Abschied waren. Leider fehlt das. Mehr Fehlertoleranz und Skripte, die ein Fail-Verhalten antizipieren, wären hilfreich.
Immerhin ergab sich dabei die gute Gelegenheit, die Community zu testen und im Mail-in-a-Box-Forum [9] um Hilfe für Anfänger zu bitten. Nach fünf Tagen hatten zwar 18 Personen das Posting gelesen, aber niemand geantwortet. Gut also, wenn man selbst erfahrener Anwender ist und sich zu helfen weiß, nur sind erfahrene Anwender nicht unbedingt die Zielgruppe von Mail in a Box.
Vertrauenssache
Am Ende half es, die VM neu aufzusetzen, das »setup.sh« erneut per Curl von der Projektseite zu laden und per »sudo« an die Bash zu übergeben – ein weiterer Schwachpunkt. Gerade zu Beginn wäre maximale Transparenz nötig, weil der User die Software installiert und konfiguriert, der er später seine Daten anvertraut und die seine Privatsphäre schützen soll. Stattdessen soll er ein unbekanntes Skript mit Rootrechten auf dem eigenen Server ausführen. Warum soll er den Machern der Software mehr vertrauen als denen, gegen die sie ins Feld ziehen?
Eine signierte Installationsroutine, die den Herausgeber eindeutig identifiziert, Prüfsummen, die den unveränderten Zustand des Downloads dokumentieren und transparente Installationsvorgänge sind mindestens nötig. Auch wenn Mail in a Box eine gelungene Integration Mail-verarbeitender Komponenten gelingt, scheitert es so bereits zu Beginn.
Infos
- Mail in a Box: https://mailinabox.email
- Let’s Encrypt: https://letsencrypt.org
- Pattrick Koetter, “Sicherer Transport”: Linux-Magazin 02/15, S. 42ff.
- Open DKIM: http://www.opendkim.org
- Open DMARC: https://dmarc.org
- Roundcube: https://roundcube.net
- Munin: http://munin-monitoring.org
- Secondary DNS: https://mailinabox.email/guide.html#glue-records
- Forum von Mail in a Box: https://discourse.mailinabox.email









