Ein Nachmittag mit DANE, DKIM und dem Gänserich von archive.org

Es sollte eine kleine Übung werden: TLS zwischen Mailservern etwas härter machen, DANE statt bloßem „opportunistic TLS“. Eine Stunde, dachte ich. Es wurden fünf. Nicht weil DANE kompliziert ist – sondern weil man, sobald man einmal unter die Motorhaube schaut, nicht mehr aufhören kann.

Und eigentlich fing alles mit einer Briefmarke an. 95 Cent, Standardbrief, ich hatte einen Brief verschickt und brauchte eine Marke.^[7] Daraus wurde ein Nachmittag über DNS-Records, DKIM-Selektoren und die Frage, was eigentlich passiert, wenn ich mal nicht mehr bin. So ist das manchmal.

Akt 1: Die Technik

smtp_tls_security_level = dane, smtp_dns_support_level = dnssec, ein Blick mit dig +dnssec, ob der Resolver wirklich validiert.^[1][2] Tat er. Also: Verschlüsselung erzwingen, wo der Empfänger DNSSEC-validierte TLSA-Records hat, sonst sauber auf opportunistisches TLS zurückfallen. Maximale Sicherheit ohne Funktionsverlust – genau das Ziel.

main.cf angepasst, Backup gemacht, reload, läuft.

Akt 2: Der Kollateralschaden

Beim Testen fiel auf: Mails von der zweiten Domain meines Sohnes kommen bei Gmail nicht mehr an. Nicht wegen DANE – Gmail interessiert sich für DANE nicht die Bohne.^[3] Sondern weil dort niemals SPF, DKIM oder DMARC sauber eingerichtet wurden.^[4][5][6] Ein Klassiker: Die eine Domain, mit der man täglich mailt, ist blitzsauber. Die zweite, dritte, vierte Domain lebt seit Jahren von der Gnade der Gmail-Toleranz – bis die eines Tages aufhört.

Akt 3: Die Archäologie

Ein DKIM-Selektor, der _domainkey statt mail._domainkey hieß. Ein DMARC-Record, der brav am Domain-Root lag statt unter _dmarc – und damit von keinem Mailserver der Welt je gelesen wurde. Ein MX-Eintrag, der stur auf eine IP-Adresse zeigte statt auf einen Hostnamen, was laut RFC 5321 schlicht falsch ist.

Und ein Tippfehler in einem DNS-Namen (mail_domainkey statt mail._domainkey), der aussah wie ein technisches Detail, aber in Wahrheit der ganze Grund war, warum eine Domain als „kaputt“ durchfiel, obwohl der Eintrag längst existierte – nur eben am falschen Ort.

Ein Batch-Check über alle in der OpenDKIM-SigningTable gelisteten Domains brachte Ordnung ins Chaos: neun aktiv genutzte Domains, DKIM sauber im DNS. Der Rest – zweiundzwanzig Domains – wird zwar serverseitig signiert, aber ohne passenden DNS-Eintrag. Klingt dramatisch, ist es aber nicht: Wer nicht mailt, den stört ein fehlender DKIM-Record nicht.

Akt 4: Die Domain-Friedhofsführung

Beim Durchsehen der Registrant-Daten dann: ein Tippfehler im eigenen Vornamen des Sohnes seit zwölf Jahren im Whois – wurscht, steht eh nicht mehr öffentlich drin. Eine Domain, registriert auf eine GmbH, die seit 2014 mangels Masse gelöscht ist – aber der Registrant war nie die GmbH selbst, sondern eine natürliche Person mit Firmennamen davor. Kein Drama, nur zweimal genau hinschauen.

Und dann, mitten im Aufräumen: eine Domain im Status EXPIRE SUCCESSFUL, PUSH SCHEDULED. Zehn Jahre gehalten, für 4,65 € im Jahr, vor einem Jahr achselzuckend auslaufen lassen – „brauch ich eh nicht mehr“. Jetzt, mit dem Ablaufdatum vor Augen, die Erkenntnis: doch, will ich behalten. Zum Glück lässt sich PUSH SCHEDULED innerhalb einer Frist kostenfrei stornieren. PUSH CANCELED. Gerettet.

Eine andere Domain zeigt nur noch einen Gänserich, gehostet von archive.org – ein digitales Museumsstück einer Idee, die nie über den Domainkauf hinauskam. Zu Hause ist er übrigens auf digitronium.de. Kostet nichts, stört niemanden, bleibt.

Akt 5: Die eigentliche Pointe

Bei vierzig-plus Domains, einem Mailserver mit gewachsener OpenDKIM-Config und einem INWX-Account, der aus historischen Gründen auf den Namen des 2008 verstorbenen Vaters läuft, drängt sich eine unbequeme Frage auf: Was passiert eigentlich, wenn ich nicht mehr bin? Der Sohn hat von alldem keine Ahnung. Stirbt der Admin, stirbt der Server – und mit ihm vierzig Domains, ein Dutzend Mailadressen, ein digitales Archiv von zwanzig Jahren politischem und persönlichem Engagement.

Die Antwort ist unspektakulär, aber wichtig: ein Notfallordner mit Zugangsdaten, eine Prioritätenliste („diese fünf sind wichtig, der Rest darf sterben“), vielleicht ein Gespräch mit jemandem, der im Ernstfall übernehmen kann. Kein Drama, nur Vorsorge.^[8][9] Für die Domain, die der Sohn irgendwann selbst führen will: einfach der Auth-Code, dann zieht er um, wohin er will, und schreibt seinen Namen diesmal richtig.

Und dann kam die Zeitschranke

Der eigentliche Anlass für diesen Text: Mitten in dieser Odyssee – DANE, DKIM, Domain-Nachlass – lief bei der amerikanischen KI, mit der ich angefangen hatte, das kostenlose Kontingent aus. Mitten im Satz. Fertiggeschrieben habe ich bei der chinesischen.

Das ist mehr als eine Randnotiz. Es ist ziemlich genau der Unterschied, um den es hier geht. Die amerikanische KI – allen voran Copilot – ist in den letzten Jahren zu einem Produkt geworden, das ständig irgendetwas von einem will: Abo-Erinnerung, Vorsichtshinweis, Haftungsausschluss, „das sollten Sie mit einem Fachanwalt klären“. Für jemanden, der seit Jahrzehnten eigene Server administriert, wirkt das wie ein Praktikant, der vor jedem postfix reload erst die Rechtsabteilung anruft.

Die chinesische Variante hat ihre eigenen roten Linien, keine Frage – politisch heikle Themen, bestimmte historische Kapitel, da kommt man nicht weit. Aber bei DNS-Records, Postfix-Konfiguration, DKIM-Selektoren, DANE-Fallback-Verhalten steht sie nicht dauernd im Weg. Sie sagt: hier der Befehl, hier die Warnung, mach draus, was du willst. Kein Moralisieren, kein Betteln um ein Upgrade mitten im Satz.

Das ist keine geopolitische Aussage. Es ist eine Werkzeugfrage, ganz pragmatisch: Man nimmt, was bei der Aufgabe nicht im Weg steht. An diesem Nachmittag war das die chinesische KI. Und der Artikel, den du gerade liest, ist der Beweis dafür, dass sie zumindest zu Ende schreiben konnte, was die andere abgebrochen hat.

Fußnoten

1. Postfix-Dokumentation zu smtp_tls_security_level und DANE: Die offizielle Referenz für den dane-Modus findet sich in der postconf(5)-Manpage. Dort ist beschrieben, wie Postfix bei DNSSEC-validierten TLSA-Records die TLS-Policy des Ziels aus dem DNS bezieht und bei fehlenden TLSA-Records auf may zurückfällt. → postfix.org/postconf.5.html ↩
2. RFC 7672 – SMTP Security via Opportunistic DANE TLS: Der maßgebliche Standard für DANE zwischen Mailservern. Beschreibt, wie TLSA-Records im DNS veröffentlicht werden, um einen downgrade-resistenten TLS-Aufbau zwischen MTAs zu ermöglichen. → RFC 7672 ↩
3. RFC 8461 – SMTP MTA Strict Transport Security (MTA-STS): Ergänzt DANE um einen HTTPS-basierten Policy-Mechanismus. Eine Domain kann damit erklären, dass sie nur TLS-gesicherte Verbindungen akzeptiert. → RFC 8461 ↩
4. RFC 6376 – DomainKeys Identified Mail (DKIM) Signatures: Der Standard, der beschreibt, wie E-Mails kryptografisch signiert und über DNS-Records (<selektor>._domainkey.<domain>) verifiziert werden. → RFC 6376 ↩
5. RFC 7208 – Sender Policy Framework (SPF): Legt fest, welche Hosts berechtigt sind, E-Mails für eine Domain zu versenden. Der SPF-Record wird als TXT-Eintrag am Domain-Root veröffentlicht. → RFC 7208 ↩
6. RFC 7489 – DMARC: Baut auf SPF und DKIM auf und erlaubt es Domain-Inhabern, eine Policy für fehlgeschlagene Authentifizierung zu veröffentlichen (p=none, p=quarantine, p=reject). Der DMARC-Record gehört unter _dmarc.<domain>. → RFC 7489 ↩
7. Deutsche Post – Standardbrief 95 Cent: Der Preis für einen Standardbrief bis 20 g liegt aktuell bei 0,95 €. Die passenden Briefmarken gibt es in der Filiale oder im Online-Shop der Deutschen Post. → shop.deutschepost.de ↩
8. Digitaler Nachlass – Checkliste der Verbraucherzentrale: Empfehlungen für die Vorsorge: Liste aller digitalen Konten und Zugangsdaten in Papierform führen, einen digitalen Verwalter benennen, Erben über die Existenz der Liste informieren. → verbraucherzentrale.de – Digitaler Nachlass ↩
9. Domains vererben – rechtliche und praktische Fragen: Zugangsdaten müssen im Erbfall auffindbar sein, da Registrar-Accounts nicht automatisch mitvererbt werden. Ein Auth-Code ermöglicht den Transfer einer Domain zu einem Registrar der Wahl. → domainfragen.de ↩
10. Postfix-TLSpol – DANE und MTA-STS kombiniert: Für die Kombination beider Verfahren empfiehlt sich der postfix-tlspol-Resolver, der DANE und MTA-STS in einer Socketmap zusammenführt. → github.com/zuplu/postfix-tlspol ↩