Ich hatte schon seit langer Zeit für die TLS Transportverschlüsselung die Version TLS 1.3 als Mindeststandard aktiviert.

Da der MS Exchange Server (vermutlich 2019er Version) der Schule allerdings noch nicht die Version 1.3 unterstützt, (Details siehe Microsofts Exchange Server TLS configuration best practices) musste ich hier wieder den eigentlich nicht mehr empfohlenen TLS1.2 Standard von 2008 wieder aktivieren

Sende ich eine Mail von meinem Server an die Mailingliste, wird diese Nachricht über den Mailinglisten-Server an alle Teilnehmenden der Mailingliste verteilt. Bisher war ich es gewohnt, dass die Verteilung der Nachricht über die Identität der Mailingliste gelaufen ist. Bei der Konfiguration der Schule läuft es dagegen so, dass die Mailingliste meine Identität als Absender verwendet.

Da ich selbst Mitglied auf der Mailingliste bin, erhalte ich also meine eigene weitergeleitete Nachricht mit meiner Identität von dem „fremden“ Mailinglisten-Server.

Wie reagiert mein Mailserver darauf? Genau, er erkennt diese Nachricht zurecht als Spoof-Mail (=Nachricht mit fingiertem Absender, also Spam oder schlimmeres).

Wer kennt es nicht: Es kommt eine Mail von einem Bekannten an und enthält auf den zweiten Blick nur Spam und auf den dritten Blick entdeckt man im Quelltext der Mail („Mailheader“), dass diese Mail eigentlich über einen anderen Server gesendet wurde und nur als Absenderlabel die Adresse des Bekannten einsetzt.

Daher ist die Ablehnung („reject“) in diesem Fall das sichere und gewünschte Verhalten… außer man benötigt die Nachrichten der Schule und will keine unnötigen Fehlermeldungen generieren.

Da die Mailingliste der Schule also diese fingierte Identitätslogik verwendet, habe ich meinen SPF Record dementsprechend angepasst:

1. von FAIL auf SOFTFAIL reduziert
   • v=spf1 a mx ~all
   • zuvor war es -all
   • Softfail bedeutet, dass SPF Fehler markiert aber durchgewunken werden
2. die Maildomain der Schule inkludiert
   • v=spf1 a mx include:SCHULDOMAIN.com ~all
   • hiermit sage ich meinem Mailserver, dass es ok ist, wenn Mails bei mir mit meiner eigenen Identität ankommen, die in Wirklichkeit von diesem spezifischen Schulserver sind
   • durch die Einschränkung auf den Schulserver hält sich das Risiko in Grenzen. Im Prinzip rutschen damit allerdings auch möglicherweise böswillige Fakemails durch die Security, die die User:innen meines Servers dann erhalten und selbstständig als Spoofing erkennen müssen

Bisher war meine Einstellung, dass eine Mail nur dann den DMARC Test besteht, wenn SPF und DKIM erfolgreich überprüft wurden. Jetzt ist es zumindest temporär so angepasst, dass nur einer der beiden Tests ausreicht, um die Mail zuzulassen

• v=DMARC1; p=none; fo=1; rua=mailto:ADMINMAIL@BEISPIEL.XYZ; ruf=mailto:ADMINMAIL@BEISPIEL.XYZ
• fo=1 macht aus der UND eine ODER Bedingung, also ein Test reicht

Ein weiterer Punkt in den letzten Tagen war, dass immer nach Verwendung der Mailingliste und der erzeugten rejects für einige Minuten bis Stunden mein Mailserver und scheinbar auch der anderer Personen der Mailingliste auf der Spamhaus ZEN Liste gelandet ist.

Als Konsequenz hat mein Server die Mails dieser Leute hart abgelehnt. Um dies temporär zu fixen, habe ich die IP Blocklist Einbindung in Yunohost deaktiviert und damit mein Sicherheitslevel einen weiteren Schritt runtergeschraubt.

Es ist noch zu früh, um eine endgültige Aussage zu treffen, daher hier nur der Zwischenstand:

1. Ich habe die oben genannten 4 Reduktionen meiner Sicherheitsstandards zähneknirschend implementiert und hoffe, dass damit die Kommunikation ab jetzt stabil mit dem Schulserver läuft
2. Veraltete Standards von nicht quelloffenen Softwareprodukten wie Microsofts Exchange Server zwingen moderne FOSS Linux Settings zur Anpassung an den niedrigeren Standard, was natürlich der Sicherheit und der Weiterentwicklung insgesamt nicht guttut.
3. Die Yunohost Default Settings sind sehr gut und auf einen gesunden Kompromiss zwischen Sicherheit und Kompatibilität ausgelegt. Dieser eine Schulserver ist der einzige Grund für meine Security-Rückschritte. Ich hoffe, dass dieser bald auf einen modernen Stand gebracht wird und diese Tweaks nicht mehr nötig sein werden.
4. Es klafft weiterhin eine große Lücke zwischen FOSS (free and open source software) und den proprietären Blackboxsystemen von Microsoft. Persönlich und professionell würde ich immer zum FOSS Setting raten, kann aber verstehen, dass die Zwangsbindung an MS365 Konten, Active Directory und Co. zum Teil für die Schulen nicht frei wählbar bzw. auch im Nachgang nicht leicht korrigierbar sind.
5. Es gibt tolle Angebote für Schule wie LinuxMuster („Schulnetz. Komplett. Anpassbar. linuxmuster.net - mit allem, was man braucht. Und mehr.“), die den Einsatz der Microsoft Server Landschaft überflüssig machen und dazu der öffentlichen Hand sehr viel Geld an Lizenzkosten einsparen können. Anbei eine Liste der Schulen, die Linuxmuster bereits erfolgreich einsetzen