Es ist geschafft, das neue Mail-System ist fertig und es war keine schnelle Angelegenheit. Insgesamt sind 12 Server daran beteiligt, dass Mails so empfangen und verschickt werden können, dass nur dass in die Postfächer kommt, was wir auch dort erlaubt haben.
Wie man unschwer an der Grafik erkennen kann, ist ein Mail-System eine recht komplexe Angelegenheit. Als Anwender eines Mail-Clients wie Outlook oder Thunderbird bemerken wir im Regelfall nicht von dieser Komplexität. Zugegebenermaßen machen wir uns auch keine Gedanken darum. Aber ein Blick hinter die Kulissen bietet dann doch ein anders Bild.
Ich will ein wenig erläutern, wie das Ganze funktioniert und was es so kompliziert macht. Fangen wir mit letzterem an. Warum kann man nicht einfach eine Mail an einen Rechner schicken und fertig?
Schauen wir uns erst einmal den „normalen“ Weg einer Mail an. Gehen wir also an den Anfang der Kette, den Anwender, der in seinem Thunderbird auf Senden klickt und erwartet, dass die Mail ihr Ziel schon finden wird. Als erstes wandert die Mail zu einem Postausgangsserver, einem MTA (Mail Transfer Agent). Der schaut vereinfacht gesagt nach, welche Domain die Empfängeradresse hat. So hätte die Mail-Adresse max.mustermann@shsbl.de die Domain shsbl.de. Nun wird per DNS (Domain Name Service) gefragt, welcher Server im Internet für den Empfang einer Mail mit dieser Domain zuständig ist. Für Technikfreunde: Hier wird mit Hilfe von DNS der MX Record in der Domain abgefragt. Nachdem nun klar ist, wer die Mail bekommen soll, nimmt der eigene MTA Kontakt mit dem MTA des Empfängers auf und übergibt die Mail. Von dort aus wird sie geprüft und dann weiter übergeben an einen MDA (Mail Delivery Agent). Dieser hat die eigentlichen Postfächer, nimmt die Mail auf und sortiert sie in das richtige Postfach. Fragt der Empfänger das nächste Mail sein Postfach, findet er dort die neue Mail.
Soweit ist das Ganze noch recht gut und einfach durchschaubar. Nun gibt es aber im Internet leider nicht nur all die Guten, die nichts weiter wollen, als eine Mail zum Empfänger schicken. Vielmehr tummeln sich jede Menge aufdringliche Mailversender, die denken, dass Mailwerbung den Umsatz deutlich steigern wird. Sie sammeln oder kaufen jede Menge Informationen, die wir im Netz hinterlassen auf, setzen daraus ein bestimmtes Bild von uns zusammen und schicken uns dann zielgerichtete Werbung. Schlimmer aber noch sind all die kriminellen Aktivitäten, die per Mail auf allerlei Gefahren hinweisen und unbedingt möchten, dass wir doch hier- oder dorthin klicken und unsere Bankdaten, Zugangsdaten zu Providern usw. eingeben. Nur um dies zu deren eigenem Vorteil zu nutzen und zum Beispiel unerlaubt Geld abzuheben. Ganz abgesehen von denen, die uns mit einer Mail auf eine Seite locken wollen, die dann Schadsoftware auf unserem Rechner installiert. Inzwischen sind gültige Mail-Adressen umso wertvoller, je mehr individuelle Daten dazu vorliegen. Aber auch einfach nur die Mail-Adresse wird gesammelt und in hohen Stückzahlen auf dem Schwarzmarkt verkauft.
Tja, klingt unschön und ist es auch. Betreibt man ein eigenes Mail-System, so wie wir, so muss man all dies im Hinterkopf haben und diverse Sicherheitsmechanismen einbauen. Ein Großteil der Komplexität eines Mails-System besteht letztlich nur aus Sicherheitsmechanismen, damit unerwünschte Post draußen bliebt und unser eigenes System nicht zu einem Verteiler von schädlichen Mails wird.
CIh werde nun ganz kurz das vorangegangene Schaubild erläutern und dabei auf die verschiedenen Funktionen der Beteiligten eingehen. Da eine ausführliche Darstellung den Rahmen hier sprengen würde, versuche ich mich mal kurz zu fassen, ganz gegen meine Gewohnheit.
Beginnen wir die Betrachtung auf der linken Seite oben mit dem Anwender. Dieser sitzt, wie in unserem Beispiel zuvor, vor seinem Thunderbird und schickt eine Mail ab. Da der Versender irgendwo sitzen kann, wird die Mail zunächst über das Internet an unseren MTA geschickt. Dieser wurde zuvor bei der Einrichtung des Postfachs als Postausgangsserver konfiguriert und heißt in unserem Fall smtp.shsbl.de. Auf dem Bild ist dies der grüne oder der lila Pfeil. Beim MTA angekommen, entscheidet dieser als erstes, ob der Versender überhaupt die Erlaubnis hat, Mails über ihn zu verschicken. Dazu schaut ganz rechts in den LDAP-Verzeichnisserver. Dort stehen alle unsere Angestellen, Lehrkräfte und Schülerinnen und Schüler drin. Finder er dort den Absender, geht es weiter. Nun muss entschieden werden, wo die Mail hinkommt. Der MTA schaut sich dazu die Domain des Empfängers an. Ist es eine Mail, für die wir selbst die Postfächer halten, so wird die Mail intern weiter geschickt. Dies ist der grüne Pfeil. natürlich könnten auch Schädlinge in diesen Mails sein, daher wandert die Mail zunächst zu einem weiteren Server, auch ein MTA, der die Mail sehr ausgiebig prüft. Mit aktuellen Listen werden die Mails auf alle Schädlinge überprüft und zusätzlich versucht zu erkennen, ob es sich um SPAM-Mails handelt, die aussortiert werden. Solche Mails werden nicht weitergeschickt. Ist alles in Ordnung geht es an den MDA, der dann die Mails in das richtige Postfach einordnet.
War es keine Mail an einen internen Empfänger, der lila Pfeil, schickt unser MTA die Mail weiter an einen MTA, den wir direkt bei unserem Provider haben. Dieser wiederum erledigt dann die Arbeit, die Mail an den MTA des Empfängers zu schicken. Warum aber machen wir einen solchen Umweg. Nun, ein Teil der Beurteilung von SPAM-Mails ist die sogenannte Reputation, die der versendende MTA hat. Ist dies ein in der weiten Welt recht unbekannter MTA, dann landet die Mail ganz schnell im SPAM Ordner des Empfängers. Unser Provider IONOS hingegen gehört zu den ganz großen Providern in der Welt und genießt überall eine gute Reputation. Das heißt, dass alle davon ausgehen, dass von diesem MTA keine oder nur ganz selten SPAM Mails verschickt werden. Die empfangenden MTA beurteilen die Mails von IONOS als wenig SPAM verdächtig und lassen diese durch.
Schauen wir uns die zweite Wolke an. nicht wir, sondern irgendjemand schickt uns eine Mail. Die ist irgendwann einmal im Internet und landet bei unserem MTA. Dies ist aber nicht der gleiche, den wir oben hatten, das war ja unser Postausgangsserver. Dieser MTA hier wird nicht gezielt von einem CLient angesprochen. Vielmehr ist er als Empfänger für Mails aus der ganzen Welt beim Provider hinterlegt (der MX Record, siehe oben). Wenn also irgendein MTA mit uns Kontakt aufnehmen will, damit eine an uns gerichtete Mail geben kann, dann macht er das über diesen Server. Der prüft als allererstes, ob die Mail irgendwelche Schadsoftware beinhaltet oder als SPAM beurteilt werden muss. In diesem Fall wird die Mail aussortiert. Er kann aber auch ganz gezielt Regeln abprüfen. So dürfen zum Beispiel unsere Elternpostfächer an der BNS zwar von anderen Elternpostfächern oder von der BNS angesprochen werden. Alle anderen Absender werden aber schon hier aussortiert. Ist alles in Ordnung, gibt er die Mail weiter an den MTA, den wir schon oben beschrieben hatten. Dies nur aus dem einen Grund, weil dieser in der Lage ist, mit Hilfe des LDAP Verzeichnisses Gruppennamen aufzulösen. Wenn also zum Beispiel an eine Klasse 9a geschrieben wird, sucht der obige MTA die entsprechend dazugehörigen Mailadressen der Mitglieder heraus. Dann geht alles den gewohnten Gang.
Dritter Fall: Jemand benutzt den Webmailer. Ein Webmailer ist quasi ein Mail-Client, den wir über einen Bowser bedienen können. Hierfür gibt es bei uns einen eigenen Server, da dies zum Anwender hin eine reine Browser-Applikation ist, die ganz anderen Regeln folgt, als der Mailverkehr. Der Weg wird mit dem braunen Pfeil gezeigt. Dieser Webmailer zeigt im Browser eine Anmeldemaske und bei geglückter Anmeldung bereit er die Sicht auf das Postfach so auf, wie es sonst die Mail-Client wie Thunderbird oder Outlook machen. Nur eben im Browser und nicht ganz so funktionsmächtig. Die Postfächer selbst, aus denen die Information geholt werden, liegen tief im Innern und in der Sicherheit unsere Infrastruktur. Es ist der weiter oben erwähnte MDA.
Bleibt noch der vierte Fall, mit dem graublauen Pfeil, der Abruf von Mails über einen Client wie Thunderbird oder Outlook. Hier wird wieder direkt mit den Protokollen des Mailverkehrs gearbeitet. Bei der Einrichtung des Postfaches wird er sogenannte Posteingangsserver festgelegt. Dies ist bei uns der imap.shsbl.de. Der Client fragt nur nach den Inhalten des Postfaches, landet aber zunächst auf einem sogenannten Proxy Server. Dieser überprüft zunächst die Abfrage, bevor er sie an den internen MDA weiterreicht. Von dort fließen dann die Informationen zu neuen Mails zurück an den Client.
Soweit in Kurzform die Darstellung der verschiedenen Wege. Noch ein paar technische Details zum Schluss. Die Server sind allesamt virtualisiert. Um eine Ausfallsicherheit zu garantieren, sind alle wichtigen Komponenten redundant ausgelegt, also doppelt. Dazu haben wir zwei physische Server in der DMZ (Demilitarisierte Zone), auf denen die identischen virtuellen Maschinen laufen. Diese kontrollieren sich gegenseitig. Fällt zum Beispiel einer der MTAs auf dem einen Server aus, springt automatisch das Pendant auf den anderen Server an und der Betrieb läuft ungestört weiter. Im Backend, wo sich der Verzeichnisserver und der MDA befinden, wird die Redundanz durch ein großes Cluster gewährleistet, wo jeder einzelne Node in der Lage ist, alle virtuellen Maschinen laufen zu lassen. Fällt ein Node aus, übernehmen die anderen die virtuellen Maschinen.
Die 12 beteiligten Server sind allersamt auf große Last eingestellt. Wie groß die Last wird, zeigen die folgenden Zahlen für den Endzustand, den wir erreichen wollen. Wir gehen von rund 500 Angestellten und Lehrkräften in unseren 5 hessischen Schulen aus. Dazu kommen noch einmal 4500 Schülerinnen und Schüler. Alle sollen am Ende ein Postfach auf unserem System haben, damit Mails mit sensiblen Inhalten nicht bei fremden Providern herumliegen. Schließlich kommen zu den 4.500 Schülerinnen und Schülern noch einmal die Eltern hinzu. Nicht immer sind es zwei, in der Mehrzahl der Fälle aber schon. Macht 9.000 weitere Nutzer. So kommen wir am Ende auf ca. 14.000 Postfächer, die das System bedienen muss. Wenn man bedenkt, dass jedes Handy, Tablet, Notebook oder auch der Desktoprechner alle paar Minuten eingerichtete Postfächer auf Neuigkeiten abfragt, so kommen wir schnell auf 20-50 Abfragen, die pro Sekunde hereinkommen werden und abgearbeitet werden müssen. Da muss alles sauber laufen und nichts im Wege stehen. Andernfalls ist das Chaos vorprogrammiert.
Ich werde mich freuen, wenn wir dieses Ziel mal erreicht haben und unsere Server richtig „unter Dampf“ sind. Dann muss die Konstruktion beweisen, dass sie auch unter Last funktionsfähig ist.
Bis dahin Peter