Mailsystem V3

Elbphilharmonie

Es ist vollbracht. Knapp aber letztlich doch chancenlos haben wir das Rennen um das am schlimmsten aus dem Zeitplan gelaufene Projekt diesseits der Elbe gegen die Elbphilharmony verloren. Dort ist erst im Januar feierliche Eröffnung. Wir sind fertig:

Das Projekt Artfiles Mailsystem V3 ist abgeschlossen.

Die Idee für ein von Grund auf neu konzipiertes Mailsystem geht bereits zurück auf das Jahr 2007: Das von uns eingesetzte Qmail war zu diesem Zeitpunkt gerade zehn Jahre alt geworden und von halboffiziellen Patches und eigenen Anpassungen so überwuchert, dass eine Weiterentwicklung nicht mehr sinnvoll erschien.

So reifte der Entschluss, ein neues Mailsystem auf Basis von Exim zu entwickeln.

Mailsystem V2

Aber während einige Komponenten wie Mailein- und ausgangsserver leicht ausgetauscht werden konnten, erwiesen sich Mailzustellung und -abruf als erstaunlich hartnäckig.

Als größtes Problem zeigte sich wie erwartet unser Anspruch, die Umstellung praktisch ohne Beeinträchtigung der Benutzer durchzuführen. Bei schon damals mehr als einhunderttausend Mailboxen war es undenkbar, den Benutzern Änderungen aufzuzwingen.

Also haben wir viel experimentiert, implementiert und getestet, aber letztlich ließ sich keine zufriedenstellende Lösung finden. Und mangels größerer Probleme mit unserem alten Mailsystem gab es natürlich auch immer wieder Projekte, die das neue Mailsystem von der Spitze der Todo Liste verdrängt haben.

Zwischenzeitlich wurde dann mal das Webmail von Squirrelmail auf Roundcube aktualisiert und alte Storageserver durch neuere ersetzt. Auch für die Redundanz wurde viel investiert, aber der Kern des alten Mailsystems blieb bestehen.

Es muss etwas passieren

Das änderte sich erst im Frühjahr 2015: Vor allem die Courier IMAP Software begann uns ernsthafte Probleme zu machen. Viele neuere Mailprogramme unterstützten nun IMAP Erweiterungen, die Courier schlicht nicht beherrschte, und die auch nicht mehr nachzurüsten waren. Also musste gehandelt werden.

Als neue POP3 und IMAP Software wurde Dovecot auserkoren. Zusammen mit Amavis sollte Dovecot auch die Mailzustellung in die Postfächer übernehmen. Damit sollte dann gleich auch die Konfiguration der Mailboxen in die Datenbank verlegt werden. Bisher befand sie sich nur zum Teil dort und zum Teil in .qmail Dateien auf den Storage Servern.

Die Implementierung der geplanten Lösung erwies sich leider als etwas schwieriger als gedacht. Das lag vor allem an der etwas undurchsichtigen Struktur von Amavis und der mangelhaften Dokumentation. Letztlich konnte aber im Herbst 2015 eine funktionierende Plattform für Mailzustellung und Abruf in den Testbetrieb gehen.

Aus leidvoller Erfahrung mit defekten Raidcontrollern und “alle Jahre wieder” auftretenden Ausfällen von Storage Servern, entschieden wir uns für ein vollständig redundantes System für die Speicherung und den Abruf von Mails. Zunächst wurde es auf basis von Xen und Btrfs auf jeweils zwei per DRBD verbundenen Servern realisiert.

Leider zeigte sich jedoch relativ schnell, dass dieser doch recht komplexe Stack den harten Anforderungen des Livebetriebs nicht gewachsen war. Zudem erwies sich Btrfs als nicht ausgereift und sorgte mit vielen Problemen für reichlich graue Haare bei den Admins.

Also haben wir noch mal einen Gang zurück geschaltet und stattdessen auf Bewährtes gesetzt. Jetzt werden die Mails wieder in einem Ext4 Dateisystem gespeichert, das auf einem per LVM partitionierten DRBD aufsetzt. Es gibt keine Virtualisierung mehr, sondern “traditionelle” Hochverfügbarkeit.

Nachdem diese Lösung im Frühjahr endlich betriebsbereit war, ging es an die Umstellung der Mailboxen vom alten in das neue System. Dies nahm nochmals einige Wochen in Anspruch und war im Mai dann endlich abgeschlossen.

Fast fertig

Damit war das neue Mailsystem im Grunde komplett soweit es die Mailboxen betraf.

Ein letzter Querulant aber hörte nicht auf, der Umstellung Widerstand zu leisten: Die Mailinglisten. Diese werden bei uns sozusagen seit Anbeginn der Zeit mit Ezmlm betrieben und sind dadurch praktisch untrennbar mit Qmail verzahnt.

Also wurde der Plan gefasst, eine saubere, auf die reine Mailinglistenfunktion reduzierte Qmailinstallation zu schaffen. Wie nicht anders zu erwarten steckte auch hier der Teufel im Detail. Aber schließlich konnte am 23. August der neue Mailinglistenserver online und der letzte “alte” Qmail Server nach über 15 Jahren endlich offline gehen.

Status Quo

Eine Übersicht über den Mailzustellungsprozess gibt es hier: Artfiles Mail V3

Im Unterschied zu den dort skizzierten Plänen hat unser Mailsystem noch mal deutlich an Sicherheit und Verfügbarkeit gewonnen: es gibt jetzt eine redundante Speicherung sämtlicher Mails auf zwei Storage Servern, die sich in verschiedenen Brandabschnitten des Rechenzentrums befinden. Von diesem Redundanten Datenbestand werden alle drei Stunden Snapshots gezogen, die eine möglichst zeitnahe Wiederherstellung ermöglichen.

Zusätzlich werden vom jeweils aktuellsten Snapshot täglich die Daten auf ein drittes, unabhängiges System gesichert. Diese Sicherungen werden mindestens 28 Tage aufbewahrt.

Ausblick

Auch wenn nun ein Meilenstein erreicht ist, arbeiten wir selbstverständlich kontinuierlich weiter an der Verbesserung des Mailsystems. Als nächstes wollen wir den Benutzern die Möglichkeit geben, selbst Mails aus den backups wieder herzustellen. Derzeit muss das noch ein Administrator “zu Fuß” tun.

Außerdem möchten wir den Benutzern mehr Konfigurationsmöglichkeiten für Ihre jeweiligen Accounts geben, ohne dass sie dafür das DCP bemühen müssen.

Beides ist bereits in Arbeit, die Realisierung wird aber noch einige Zeit in Anspruch nehmen – voraussichtlich aber nicht wieder fast zehn Jahre…

Let’s Encrypt im DCP

Um ein Let’s Encrypt Zertifikat im DCP zu aktivieren, muss zunächst die Teilnahme am Beta Programm aktiviert werden.

Dies geschieht im Menü unter “Einstellungen”.

 

Sobald die Beta Features freigeschaltet sind, findet sich nach wenigen Minuten im “Domain”-Menü ein Eintrag “SSL”:

Bildschirmfoto 2016-08-26 um 15.37.17

 

Ein Klick auf “Neu anlegen” öffnet die Konfigurationsansicht:

Bildschirmfoto 2016-08-26 um 15.38.51Hier können bis zu 5 Subdomains einer Domain mit einem SSL/TLS Zertifikat versehen werden.

Es können nur Subdomains konfiguriert werden, für die noch kein anderes Zertifikat eingerichtet ist.

 

Technischer Hintergrund:

Das DCP erstellt automatisch einen Certificate Signing Request und übermittelt diesen an Let’s Encrypt. Gleichzeitig wird der Webserver entsprechend konfiguriert, um den Validierungsrequest korrekt zu beantworten. Es handelt sich hier also um eine HTTP Validierung. Diese läuft völlig transparent zum normalen Betrieb des Webservers.

Der gesamte Validierungsprozess dauert etwa 15 Minuten, so dass nach spätestens 15 bis 20 Minuten die Zertifikate zur Verfügung stehen.

 

Beispielzertifikat:

Bildschirmfoto 2016-08-26 um 16.06.50Let’s Encrypt Zertifikate sind derzeit grundsätzlich 90 Tage gültig. Das DCP erneuert Zertifikate aber bereits nach 60 Tagen gemäß der Empfehlung von Let’s Encrypt. Auch dies läuft völlig transparent für Benutzer des Webservers ab.

Einige Hintergrundinformationen zu Let’s Encrypt haben wir noch mal in einem eigenen Artikel zusammengefasst: Let’s Encrypt (beta)

Let’s Encrypt (beta)

letsencrypt_logo

Ab sofort bieten wir im Rahmen unseres Beta Programms allen Webhosting Kunden ab Private Medium die Möglichkeit, Let’s Encrypt® SSL Zertifikate über das DCP einzurichten. In der folgenden kurzen FAQ wollen wir versuchen, die wichtigsten Fragen zu Let’s Encrypt zu beantworten.

Was ist eigentlich Let’s Encrypt?

Let’s Encrypt ist eine kostenlose und vollautomatisierte sogenannte Certificate Authority, also eine Stelle, die kostenlose SSL Zertifikate ausstellt.

Wozu braucht man eine Certificate Authority?

Um eine verschlüsselte Verbindung (z.B. HTTPS) sicher nutzen zu können, ist es nicht nur wichtig, dass der Datenverkehr verschlüsselt wird, sondern es ist ebenso wichtig sicher zu stellen, dass man auch tatsächlich mit dem richtigen Server kommuniziert.

Ansonsten könnte ein Angreifer, der zwischen Server und Benutzer sitzt, einfach selbst die Verschlüsselung zu beiden Seiten durchführen und so doch wieder den Datenverkehr abhören, ohne dass die Kommunikationspartner das bemerken.

Um diese Angriffsmöglichkeit zu verhindern, gibt es SSL Zertifikate, die der Server präsentiert und die seinen Namen enthalten. Dadurch kann der Benutzer bzw. sein Browser erkennen, dass die Verbindung auch tatsächlich mit dem gewünschten Server und nicht mit einem Angreifer “In der Leitung” zustande gekommen ist.

Um nun wiederrum das Zertifikat überprüfen zu können, ist es durch ein weiteres Zertifikat beglaubigt. Dieses sogenannte Root Zertifikat wird von einer Certificate Authority ausgestellt und muss im Browser (oder auch z.B. im Mailclient) des Benutzers hinterlegt sein.

Was ist das Besondere an Let’s Encrypt?

Die Root Zertifikate von Let’s Encrypt sind wie die aller Certificate Authorities (z.B. Verisign, Geotrust, Thawte etc.) in praktisch allen aktuellen Browsern hinterlegt (bzw. derzeit noch “cross signed”). Nur so kann die Sicherheit einer SSL/TLS Verbindung garantiert werden und das berühmte Schloss im Browser schließt sich.

Im Gegensatz zu kommerziellen Certificate Authorities sind Let’s Encrypt Zertifikate kostenlos und können über einen automatisierten Prozess erzeugt werden.

Braucht man eigentlich noch “traditionelle” Certificate Authorities?

Das kommt darauf an. Let’s Encrypt Zertifikate sind bei der Benutzung genauso sicher wie kommerziell ausgestellte Zertifikate. Wenn man also nur seine Webseiten absichern möchte, reicht ein Let’s Encrypt sicher aus.

Möchte man allerdings seinen Benutzern und Kunden eine größtmögliche Sicherheit auch optisch präsentieren, geht es nicht ohne sogenannte “Extended Validation” Zertifikate. Nur mit diesen Zertifikaten färbt sich die Adressleiste grün bzw. erscheint der Firmenname neben der URL.

Extended Validation Zertifikate müssen manuell geprüft werden und können daher von Let’s Encrypt nicht angeboten werden. Hier ist man also weiterhin auf kommerzielle Anbieter angewiesen.

Und warum kostenlos?

Das Ziel von Let’s Encrypt ist es, eine möglichst große Anzahl von Webservern durch SSL/TLS abzusichern und so das Internet insgesamt sicherer zu machen. Hinter Let’s Encrypt stehen viele Größen des Internet wie zum Beispiel CISCO, Facebook und natürlich Mozilla, die Organisation hinter Firefox.

Links:

https://letsencrypt.org/

https://de.wikipedia.org/wiki/Digitales_Zertifikat

https://de.wikipedia.org/wiki/Transport_Layer_Security