Der niederländische internet.nl Mailserver-Test hat die Anforderungen verschärft. Die neuen Guidelines orientieren sich an den aktuellen niederländischen IT-Sicherheitsrichtlinien und ziehen die Messlatte deutlich an.
Was sich geändert hat
TLS 1.0 und 1.1 geben jetzt Abzug. Vorher wurden sie toleriert, jetzt gibt es eine explizite Warnung. Schwache Diffie-Hellman-Parameter und weitere veraltete Cipher sind herausgefallen. Alles um TLS 1.3 den Weg zu ebnen.
Die Hall of Fame hat eine neue Sektion für Champions bekommen: Domains die sowohl beim Webserver als auch beim Mailserver 100 Prozent erreichen.
Warum das relevant ist
internet.nl ist kein akademisches Testtool. Die Ergebnisse fließen in die Bewertung niederländischer Behörden und Dienstleister ein. Wenn dort die Standards steigen, zieht das langfristig auch die Anforderungen an internationale Kommunikationspartner nach oben. Wer mit niederländischen Behörden oder Unternehmen per E-Mail kommuniziert, sollte seinen Score im Auge behalten.
Zufällig habe ich gesehen, dass die Suchmaschine Shodan bereits die security.txt auswertet und als Security Contact auflistet. Genau so habe ich mir das vorgestellt. https://www.shodan.io/host/148.251.40.23
IMAP-Postfächer wachsen mit der Zeit. Irgendwann hat man tausende Mails im Posteingang und in Sent, die Suche wird langsam und die Übersicht geht verloren. cleanup-maildir ist ein Python-Script das Mails nach Alter automatisch in Archiv-Ordner sortiert. Es läuft als Cronjob und arbeitet direkt auf dem Maildir-Verzeichnis.
--age=365 fasst nur Mails an die älter als ein Jahr sind. --archive-folder gibt den Zielordner im IMAP-Postfach an. archive ist der Modus (alternativ delete). Der leere String '' steht für die Inbox, 'Sent/' für die gesendeten Mails.
Das Script legt automatisch Unterordner nach Jahr und Monat an. Die Struktur im Postfach sieht dann so aus:
Bei mehreren Postfächern will man nicht für jeden Benutzer einen eigenen Cronjob-Eintrag pflegen. Ein Wrapper-Script kann die Benutzer, Maildir-Pfade und die Option ob archiviert werden soll aus dem LDAP holen. Das LDAP-Attribut (z.B. autoarchive=1) steuert pro Benutzer ob die Archivierung aktiv ist. So lässt sich die Archivierung zentral verwalten ohne auf jedem Mailserver Cronjobs anzupassen.
Python 3.11+ und kaputte Header
Ab Python 3.11 nutzt cleanup-maildir den strikten RFC-Header-Parser aus email.policy.default. Das führt zu einem Problem: Mails mit fehlerhaften Headern (z.B. Microsoft Exchange Message-IDs wie <[b378dfc5...]@microsoft.com>) lassen das Script mit einem IndexError abstürzen. Alle Mails nach der fehlerhaften werden nicht mehr verarbeitet.
Den Fix dafür habe ich als Pull Request eingereicht. Ein _safe_header()-Wrapper fängt Parse-Fehler ab und überspringt kaputte Header, statt das ganze Script abzubrechen. Bei mir hat das Script vorher bei Mail #8 aufgehört, danach liefen alle 2.986 Mails sauber durch.
Die Zeit ging weiter, die Entwicklung bei BIND und DNS ebenfalls. Daher gibt es nun einen neuen Beitrag, der das aktuelle Setup mit BIND 9.20 auf FreeBSD 15 beschreibt – inklusive sauberer Trennung von authoritative DNS (Port 53) und öffentlichem Resolver (DoT/DoH) sowie reproduzierbaren CLI-Tests für IPv4 und IPv6. Bitte dort weiterlesen.
Meine Tests mit DoT (DNS over TLS) habe ich bereits vor einiger Zeit gestartet. DoT DNS over TLS mit Bind, stunnel und Android 9 Dieses arbeitet noch immer ganz fein auf meinem Smartphone. DoT gefällt mir noch immer um einiges besser als DoH aber auch hier wollte ich nun einmal einen Versuch starten. Zusammen mit nginx und einem etwas angepassten doh-proxy läuft dieses nun auf dem gleichen System.
Im Firefox ist es schnell aktiviert https://ns1.kernel-error.de/dns-query…
Es funktioniert auch, so richtig glücklich macht es mich aber nicht! Natürlich ist die Umsetzung nur etwas für einen kleinen privaten Test. „Schnell“ genug ist es ebenfalls! Zumindest zum Surfen im Internet, dennoch wäre mir eine saubere Implementierung von DoT im resolver vom OS viel lieber. So wie bereits ab Android 9 zu sehen. Vielleicht ändert sich mein Gefühl ja etwas zusammen mit QUIC (HTTP/3)?!?
Vor einigen Jahren habe ich bereits etwas zu Microsoft Office Outlook Autodiscover geschrieben. Ich setze es noch immer in ähnlicher Form ein. Hier der aktuelle Stand.
Nginx-Konfiguration
Hinter autodiscover.kernel-error.de steht ein Nginx, der unter /Autodiscover/Autodiscover.xml die Konfiguration für verschiedene Maildomains ausliefert. Die Location ist überschaubar:
Jede Anfrage nach /autodiscover/autodiscover.xml wird an autodiscover.php weitergeleitet. Das Script liest die im POST übermittelte E-Mail-Adresse, prüft sie und liefert die XML-Antwort mit IMAP- und SMTP-Einstellungen zurück:
Ohne diese Einträge muss man im Outlook manuell den Haken setzen bei „Gleiche Einstellungen wie für den Posteingangsserver verwenden“. Das überfordert erstaunlich viele Anwender.
Mehrere Domains per SRV-Record
Damit Autodiscover nicht nur für kernel-error.de funktioniert, gibt es in den anderen DNS-Zonen SRV-Records, die auf die zentrale Autodiscover-Domain verweisen:
$ dig _autodiscover._tcp.kernel-error.com IN SRV +short
0 0 443 autodiscover.kernel-error.de.
Outlook zeigt beim ersten Mal eine Warnmeldung, ob man dem Verweis folgen möchte:
Einmal bestätigt, ist die Konfiguration abgeschlossen. Man könnte die Meldung auch per Registry-Key unterdrücken, aber für die meisten Benutzer reicht ein Klick.
Update März 2026: Aufgeräumt und abgesichert
Das Grundprinzip funktioniert seit 2019 unverändert. Outlook bekommt per POST seine Konfiguration, der Benutzer muss nur E-Mail-Adresse und Passwort eingeben. Ein paar Dinge habe ich aber überarbeitet.
PHP-Script: GET-Requests und fehlende Eingaben abfangen
Das alte Script hat bei GET-Requests oder einem leeren POST-Body mit HTTP 500 geantwortet. Es versuchte auf eine Variable zuzugreifen, die bei fehlendem XML-Body nicht existiert. Monitoring-Tools und neugierige Browser liefen damit gegen die Wand.
Die korrigierte Version prüft jetzt sauber:
<?php
// Nur POST erlauben
if ($_SERVER["REQUEST_METHOD"] !== "POST") {
header("HTTP/1.1 405 Method Not Allowed");
header("Allow: POST");
exit;
}
$request = file_get_contents("php://input");
preg_match("/\<EMailAddress\>(.*?)\<\/EMailAddress\>/", $request, $email);
if (empty($email[1]) || filter_var($email[1], FILTER_VALIDATE_EMAIL) === false) {
header("HTTP/1.1 400 Bad Request");
exit;
}
// XSS-Schutz: E-Mail fuer XML-Ausgabe escapen
$loginName = htmlspecialchars($email[1], ENT_XML1, "UTF-8");
GET liefert jetzt 405, ein POST ohne gültigen Body gibt 400. Die E-Mail-Adresse wird zusätzlich mit htmlspecialchars() escaped, bevor sie in die XML-Antwort geschrieben wird.
Nginx: Kein Cache für dynamische Antworten
In der ursprünglichen Konfiguration steckt fastcgi_cache MYAPP mit 60 Minuten Gültigkeit. Das ist für Autodiscover falsch. Die Antwort enthält die E-Mail-Adresse des anfragenden Benutzers als <LoginName>. Mit Cache bekommt der zweite Benutzer die Adresse des ersten. Ohne Cache:
Das ~* macht den Match case-insensitive, kürzer als die alte Regex mit (?:a|A).
Thunderbird Autoconfig auf dem gleichen Host
Inzwischen bedient autodiscover.kernel-error.de nicht mehr nur Outlook, sondern auch Thunderbird per Autoconfig. Dazu reicht eine zusätzliche Location im gleichen Server-Block:
location /mail/ {
alias /usr/local/www/autoconfig-mail/mail/;
}
Thunderbird fragt https://autoconfig.<domain>/mail/config-v1.1.xml. Für jede Maildomain gibt es einen autoconfig.* CNAME und einen eigenen HTTPS-Server-Block. Outlook nutzt weiterhin den POST-Endpoint, Thunderbird die statische XML.
Wie man bei allen ausgehenden E-Mails dafür sorgt, dass die Client IP Adresse sowie der eingesetzte Mailclient vom Postfix verschleiert wird… Ja dieses habe ich bereits geschrieben. Postfix soll verschleiern…
Nun kann es dennoch Sinn ergeben dieses nicht für jede E-Mail zu tun, welche den Mailserver verlässt. Wenn man dieses nur auf E-Mails anwenden möchte, welche von angemeldeten Benutzern versendet werden, funktioniert es wie folgt.
Man erstellt in der master.cf vom Postfix einen neuen Service:
anonym unix n - - - 0 cleanup
-o header_checks=pcre:/usr/local/etc/postfix/header_cleanup
Nun sorgt man in der gleichen Konfigurationsdatei noch dafür, dass am Ende vom Submission und smtps Service in diesen neuen Service gesprungen wird:
submission inet n - n - - smtpd
[...]
-o cleanup_service_name=anonym
[...]
smtps inet n - n - - smtpd
[...]
-o cleanup_service_name=anonym
Der Inhalt unserer /usr/local/etc/postfix/header_cleanup ist dabei weiterhin gleich:
Die Zeit ging weiter, die Entwicklung bei BIND und DNS ebenfalls. Daher gibt es nun einen neuen Beitrag, der das aktuelle Setup mit BIND 9.20 auf FreeBSD 15 beschreibt – inklusive sauberer Trennung von authoritative DNS (Port 53) und öffentlichem Resolver (DoT/DoH) sowie reproduzierbaren CLI-Tests für IPv4 und IPv6. Bitte dort weiterlesen.
Die eigenen DNS Anfragen über eine Verschlüsselte Verbindung an einen DNS Server zu schicken welchem man vertraut, dieses liest sich schon gut oder? Keiner verfolgt mein Surfverhalten und zusammen mit DNSSEC schiebt mir so schnell keiner falsche Records unter.
Am ehesten vertraue ich meinem eigenen DNS Server (ns1.kernel-error.de). Auf diesem arbeitet ein Bind und vor diesen habe ich für DoT stunnel gestellt. Die Konfiguration vom stunnel sieht dabei grob wie folgt aus:
Auf einem Android 9 Gerät kann ich also nun unter den Einstellungen ==> Netzwerk & Internet ==> Erweitert ==> Privates DNS meinen Nameserver eintragen.
Jetzt sieht mir keiner mehr beim meinen DNS Abfragen zu.
SMTP überträgt E-Mails standardmäßig im Klartext. Mit STARTTLS lässt sich die Verbindung verschlüsseln, aber kein sendender Server ist gezwungen das auch zu tun. Schlimmer noch: Ein Angreifer im Netzwerk kann die STARTTLS-Antwort einfach unterdrücken und die Verbindung bleibt unverschlüsselt. MTA-STS (RFC 8461) löst dieses Problem: Der Empfänger veröffentlicht eine Policy, die sendenden Servern sagt „hier wird nur verschlüsselt zugestellt, mit gültigem Zertifikat, an genau diesen MX“.
MTA-STS vs. DANE
Es gibt zwei Wege, Transportverschlüsselung für E-Mail zu erzwingen: DANE und MTA-STS. DANE nutzt DNSSEC und TLSA-Records im DNS. Das ist technisch sauberer, setzt aber DNSSEC auf der Empfängerseite voraus. Viele große Provider (Google, Microsoft) haben kein DNSSEC. MTA-STS funktioniert ohne DNSSEC: Die Policy liegt als Textdatei auf einem Webserver, abgesichert durch ein normales TLS-Zertifikat. Wer beides kann, sollte beides einsetzen. DANE für die Server die DNSSEC können, MTA-STS für den Rest.
Die drei Komponenten
MTA-STS besteht aus drei Teilen: einem DNS-Record, einer Policy-Datei auf einem Webserver und optional TLS Reporting.
1. DNS TXT-Record
Ein TXT-Record unter _mta-sts.domain.de signalisiert, dass eine Policy existiert:
_mta-sts.kernel-error.de. IN TXT "v=STSv1;id=20260115130000Z;"
Die id ist ein beliebiger String. Sendende Server cachen die Policy und prüfen über die ID ob sich etwas geändert hat. Bei jeder Policy-Änderung muss die ID aktualisiert werden. Ich verwende dafür einen Zeitstempel, das macht es nachvollziehbar.
2. Policy-Datei
Die eigentliche Policy liegt unter https://mta-sts.domain.de/.well-known/mta-sts.txt. Wichtig: Der Webserver muss ein gültiges TLS-Zertifikat haben und unter genau diesem Hostnamen erreichbar sein.
enforce = nur verschlüsselt zustellen. testing = wie enforce, aber bei Fehlern trotzdem zustellen (gut zum Einstieg). none = Policy deaktiviert.
mx
An welche MX-Server zugestellt werden darf. Mehrere Einträge möglich (je eine Zeile). Wildcards gehen: *.kernel-error.de
max_age
Wie lange die Policy gecacht wird, in Sekunden. 2419200 = 28 Tage.
Der empfohlene Weg: Mit mode: testing anfangen und die TLS-Reports auswerten. Wenn alles sauber ist, auf enforce umstellen.
3. TLS Reporting
Wie bei DMARC gibt es auch für MTA-STS ein Reporting-System: SMTP TLS Reporting (RFC 8460). Ein weiterer DNS TXT-Record teilt Absendern mit, wohin sie Berichte über TLS-Verbindungsprobleme schicken sollen:
_smtp._tls.kernel-error.de. IN TXT "v=TLSRPTv1;rua=mailto:postmaster@kernel-error.de"
Die Reports kommen als JSON per Mail und enthalten Informationen über fehlgeschlagene TLS-Verbindungen, ungültige Zertifikate oder MX-Mismatches. Google und Microsoft schicken diese Reports zuverlässig.
Postfix und MTA-STS
Postfix prüft von Haus aus keine MTA-STS-Policies. Für die ausgehende Seite braucht es postfix-mta-sts-resolver, ein Policy-Daemon der sich als smtp_tls_policy_maps in Postfix einhängt. Der Daemon cached die Policies und liefert Postfix die passende TLS-Konfiguration pro Zieldomain.
Die eingehende Seite braucht keine Software. Die drei DNS-Records und die Policy-Datei auf dem Webserver reichen aus. Sendende Server wie Gmail, Outlook oder Yahoo werten die Policy selbständig aus.
Zusammen mit SPF, DKIM, DMARC und DANE ergibt MTA-STS eine lückenlose Absicherung: Authentifizierung (wer darf senden), Integrität (DKIM-Signatur) und Transportverschlüsselung (DANE/MTA-STS). Fragen? Einfach melden.
Etwas über ein Jahr betreibe ich nun bereits meinen eigenen Matrix Homeserver. Als Client dazu nutze ich Riot. Diesen Client gibt es für alle gängigen Geräte, egal ob Smartphone, Laptop oder Browser. Nun ist er in der Version 1.0 veröffentlicht worden.
Nachdem Frankreich nun die Idee verfolgt Matrix zu nutzen. Bin ich sehr gespannt welche Auswirkungen dieses auf Matrix und natürlich Riot haben wird. Wir setzten diese Konstellation schon länger als alternative zu anderen Messangern für Familie, Freunde und Bekannte ein. Der neue Client gefällt allen wirklich gut und er ist sogar noch etwas einfacher und angenehmer zu bedienen als sein Vorgänger. Schaut euch Matrix / Riot doch einfach mal an, ich bin erreichbar über: @kernel-error:kernel-error.com