Übungsaufgaben zu E-Mail-Diensten

Je erläutertem Vorteil 2 Punkte, z. B.:

• Die Mails bleiben auf dem Server und werden mit allen Geräten synchronisiert. Was Bastian Ludwig am Werkstatt-Tablet liest oder in einen Ordner verschiebt, sieht er genauso am Büro-PC; bei POP3 liegen die Mails nach dem Abholen nur auf einem Gerät.

• Ordner, Markierungen und Suche werden auf dem Server verwaltet, das Postfach wird mit dem Server zentral gesichert. Geht ein Tablet verloren oder kaputt, sind keine Mails verloren.

• Auf Geräten mit wenig Speicher oder langsamer Verbindung werden zunächst nur die Kopfzeilen geladen, Anhänge erst bei Bedarf.

Je vollständig richtiger Zeile 1 Punkt. Port 25 wird nur für die Annahme von Mails anderer Server freigegeben, nicht für die Mailprogramme der Beschäftigten.

• Protokoll: IMAP – die Begrüßung * OK [CAPABILITY IMAP4rev1 …] ist eine IMAP-Antwort (1 Punkt).

• Port: 993 (1 Punkt).

• Verbindungssicherheit: SSL/TLS – die Verbindung wurde mit openssl s_client von Anfang an verschlüsselt aufgebaut, das Zertifikat für mail.csb-rad.example wurde geprüft (verify return:1) (1 Punkt).

• Authentifizierungsmethode: Passwort, normal (2 Punkte). Begründung: Der Server bietet AUTH=PLAIN und AUTH=GSSAPI an. GSSAPI steht für Kerberos und setzt eine Anmeldung in einer Domäne voraus, die es in der Buchhaltung nicht gibt. PLAIN überträgt das Passwort nur Base64-codiert, ist aber durch den TLS-Tunnel geschützt. „Verschlüsseltes Passwort“ (z. B. CRAM-MD5) wird nicht angeboten und würde scheitern; CRAM-MD5 gilt ohnehin als veraltet, über TLS ist „Passwort, normal“ vorzuziehen.

Ursache (2 Punkte): Der Mailserver nimmt Mails an fremde Domains nur von angemeldeten Nutzenden an, damit er nicht als offenes Relay missbraucht wird. Im Mailprogramm ist für den Postausgangsserver keine Anmeldung (SMTP-AUTH) eingestellt; der Code 530 (dauerhafter Fehler, Klasse 5.7 = Sicherheit/Richtlinie) bedeutet „Anmeldung erforderlich“.

Lösung (1 Punkt): Im Mailprogramm für den Postausgangsserver die Anmeldung mit Benutzername und Passwort aktivieren (Authentifizierungsmethode „Passwort, normal“), ggf. „gleiche Anmeldedaten wie Posteingangsserver“.

Der MX-Eintrag verweist auf mx.csb-rad.example, zu diesem Namen gibt es aber keinen A-Eintrag. Der Mailserver heißt mail.csb-rad.example. Fremde Mailserver finden über den MX-Eintrag keine IP-Adresse und können nicht zustellen (2 Punkte).

Korrektur (1 Punkt): MX-Eintrag auf 10 mail.csb-rad.example. ändern oder einen A-Eintrag mx.csb-rad.example. A 203.0.113.150 anlegen. Ein CNAME als MX-Ziel ist nicht erlaubt.

fa) SPF legt per TXT-Eintrag im DNS fest, welche Server Mails mit dieser Domain im Umschlag-Absender (MAIL FROM) versenden dürfen. Der empfangende Server vergleicht die IP-Adresse des einliefernden Servers mit dieser Liste und kann Mails von nicht berechtigten Servern ablehnen oder als verdächtig markieren. So wird das Fälschen der Absenderdomain erschwert (2 Punkte).

fb) Der SPF-Eintrag erlaubt nur die MX-Server (mail.csb-rad.example, 203.0.113.150) und die Server des Newsletter-Dienstleisters. Der Shop-Server 203.0.113.140 ist nicht aufgeführt; wegen -all gilt er als nicht berechtigt (SPF fail). Der empfangende Server lehnt die Mail deshalb ab; eine DKIM-Signatur, die Vertrauen schaffen könnte, erzeugt der Shop-Server auch nicht (2 Punkte).

fc) z. B. (2 Punkte):

csb-rad.example.  TXT  "v=spf1 mx a:shop.csb-rad.example include:mail.versand.example -all"

Gleichwertig ist ip4:203.0.113.140 statt a:shop.csb-rad.example. Es darf nur einen SPF-Eintrag geben; ein zweiter TXT-Eintrag mit v=spf1 würde SPF ungültig machen. Alternativ kann der Shop seine Mails über den Mailserver (Submission mit Anmeldung) verschicken; dann genügt der bisherige Eintrag.

ga) Die Signatur steht im Header-Feld DKIM-Signature der Mail (1 Punkt). Dort sind die Domain (d=csb-rad.example) und der Selektor (s=s2026) angegeben; der Empfänger fragt per DNS den TXT-Eintrag s2026._domainkey.csb-rad.example ab, der den öffentlichen Schlüssel enthält (1 Punkt).

gb) Der Mailserver hat den Hashwert über den Inhalt (bh=) gebildet und signiert, bevor das Gateway den Haftungshinweis angehängt hat. Beim Empfänger passt der neu berechnete Hash des veränderten Inhalts nicht mehr zum signierten Wert; die Integrität gilt als verletzt (2 Punkte). Lösung (1 Punkt): Den Haftungshinweis anhängen, bevor signiert wird, bzw. die DKIM-Signatur erst auf dem Gateway als letzter Station vor dem Internet erzeugen.

Eintrag für die Einführungsphase (2 Punkte):

_dmarc.csb-rad.example.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-berichte@csb-rad.example"

Mit p=none werden Mails, die die Prüfung nicht bestehen, weiterhin zugestellt; die Empfänger schicken aber Sammelberichte an die Adresse in rua. Daraus ist erkennbar, welche Server im Namen von csb-rad.example senden und ob sie SPF oder DKIM passend zur Absenderdomain bestehen.

Schrittweise Verschärfung (2 Punkte): Fehlende Absender (z. B. Shop, Newsletter-Dienst, Buchhaltungssoftware) in SPF aufnehmen bzw. mit DKIM signieren lassen, bis die Berichte keine berechtigten Fehlschläge mehr zeigen. Dann auf p=quarantine (verdächtige Mails in den Spamordner) und schließlich auf p=reject (ablehnen) umstellen.

Die Formulare enthalten personenbezogene Daten Minderjähriger und eingescannte Unterschriften. Ohne Ende-zu-Ende-Verschlüsselung liegen die Mails auf allen beteiligten Mailservern (Anbieter der Eltern, Mailserver der Schule) im Klartext und können dort oder bei einer unverschlüsselten Teilstrecke mitgelesen, kopiert oder verändert werden. Eine kopierte Unterschrift lässt sich missbrauchen, die Daten könnten für Identitätsdiebstahl genutzt werden. Die Schule muss nach der DSGVO angemessene technische Maßnahmen ergreifen; ein Datenleck kann Meldepflichten, Bußgelder und Vertrauensverlust nach sich ziehen (je Aspekt 1 Punkt, höchstens 3).

Eine wörtliche Übersetzung ist nicht nötig.

Verfahren: S/MIME und OpenPGP (1 Punkt).

Je richtig belegter Zeile 1 Punkt (4 Punkte).

Empfehlung (2 Punkte), z. B.: S/MIME für das Funktionspostfach der Schule, weil ein Zertifikat einer anerkannten CA den Eltern zeigt, dass der Schlüssel wirklich zur Schule gehört, und die Schul-IT Zertifikate zentral verwalten und erneuern kann. Zu bedenken ist: Eltern haben selten eigene Zertifikate oder Schlüssel. Verschlüsseln können sie mit dem öffentlichen Schlüssel der Schule auch ohne eigenes Zertifikat, viele werden es aber nicht schaffen. Eine Upload-Seite mit TLS in der App oder auf der Schulwebsite wäre deshalb eine einfachere Alternative. Andere begründete Empfehlungen sind ebenfalls richtig.

Zum Entschlüsseln wird der private Schlüssel gebraucht, der zum Zertifikat gehört, mit dessen öffentlichem Schlüssel verschlüsselt wurde. Er ist nur auf dem Büro-PC installiert, nicht auf dem Diensthandy (bzw. die Mail-App unterstützt S/MIME nicht). Lösung: Zertifikat mit privatem Schlüssel (z. B. als passwortgeschützte PKCS#12-Datei) über die Geräteverwaltung sicher auf das Handy übertragen und S/MIME in der App aktivieren (je Aspekt 1 Punkt).

1. Spam (2 Punkte): unerwünschte Werbung an viele Empfänger; lästig, aber ohne Täuschungsabsicht über die Identität des Absenders.

2. Phishing (2 Punkte): Die Mail gibt sich als Schul-IT aus, die Domain ist gefälscht (schul-it-0wl mit Null statt „o“), sie baut Zeitdruck auf und will über einen Link das Passwort erschleichen.

Je beschriebener Maßnahme 2 Punkte, z. B.:

Technisch:

• Eingehende Mails mit SPF, DKIM und DMARC prüfen; Mails, die sich als rrb.example oder schul-it-owl.example ausgeben, aber die Prüfung nicht bestehen, ablehnen oder in Quarantäne verschieben.

• Links in Mails umschreiben und beim Anklicken gegen Listen bekannter Phishing-Seiten prüfen; Anhänge in einer Sandbox prüfen und gefährliche Dateitypen sperren.

• Externe Mails im Betreff kennzeichnen („[EXTERN]“), damit gefälschte „interne“ Mails auffallen; Mails als Text statt HTML anzeigen.

• Mehr-Faktor-Anmeldung für die Postfächer, damit ein erbeutetes Passwort allein nicht reicht.

Organisatorisch:

• Regelmäßige Schulung der Beschäftigten im Sekretariat, z. B. mit Beispielmails, und eine klare Regel: Die Schul-IT fragt nie per Mail nach Passwörtern.

• Ein Meldeweg (Meldeknopf, Adresse der Schul-IT), über den verdächtige Mails schnell gemeldet und für alle gesperrt werden.

Ursache (1 Punkt): Der Mailserver der Schule prüft einliefernde Server gegen die Sperrliste dnsbl.example.org. Die IP-Adresse 198.51.100.77, über die die Mail des Vaters eingeliefert wurde (Server seines Mailanbieters), steht dort, z. B. weil von ihr Spam verschickt wurde. Der Code 554 5.7.1 bedeutet: dauerhaft abgelehnt aus Sicherheitsgründen.

Lösung (2 Punkte): Der Mailanbieter des Vaters muss die Ursache beseitigen und die Löschung von der Sperrliste beantragen. Kurzfristig kann der Vater eine andere Adresse nutzen oder das Formular im Sekretariat abgeben. Die Schul-IT kann die Adresse bzw. den Absender in ihrem Filter ausnahmsweise freigeben, sollte das aber nur nach Prüfung tun.

Je erläutertem Problem 2 Punkte, z. B.:

• Umlaute im lokalen Teil (vor dem @) setzen die SMTP-Erweiterung SMTPUTF8 voraus. Unterstützt ein Mailserver oder Mailprogramm unterwegs sie nicht, wird die Mail abgelehnt oder nicht zugestellt.

• Domainnamen mit Umlauten werden intern als Punycode übertragen (xn--ratz-und-rbe-…). Ältere Programme, Formulare und Filter zeigen diese Form an oder lehnen die Adresse als ungültig ab; SPF, DKIM und Zertifikate müssen für die Punycode-Form eingerichtet werden.

• Wer kein deutsches Tastaturlayout hat (z. B. Partnerschulen im Ausland), kann die Adresse nur umständlich eingeben; Schreibvarianten (ue statt ü) führen zu Fehlzustellungen.

Empfehlung: Adressen ohne Umlaute vergeben (guenther.schaefer@rrb.example), eine Umlaut-Domain höchstens zusätzlich als Weiterleitung.