Wie sich die grafische Logfile Auswertung für, unter anderem, Postfix um Dinge wie SPF, DKIM und DMARC erweitern lässt, habe ich ja bereits vor kurzem hier gezeigt: mailgraph Graphen um SPF, DMARC und DKIM erweitern
Seit ein paar Monaten ist an meinem Mailserver DANE aktiviert, sprich es lassen sich die TLSA RECORDS für die Zertifikate am Postfix gegen einen DNSSEC gesicherten DNS Server abgleichen.
In diesem Zuge habe ich selbstverständlich die ausgehende Prüfung am Postfix aktiviert. Mein Postfix nutzt nun also auch DANE um die Verbindung zu anderen Mailserver zu prüfen. Dabei gibt es im Grunde nur vier mögliche Ergebnisse einer Prüfung der TLS Verbindung:
Verified
Der bisher seltenste aber beste Fall. Denn die ausgehende Verbindung zum anderen Server ist per DANE gesichert. Das Zertifikat ist also nicht nur gültig sondern konnte auch mit den TLSA-RECORDS abgeglichen werden.
Trusted
Der OK Fall… Das Zertifikat ist gültig.
Anonymous
Na ja… Es gibt ein Zertifikat und dieses ist passend zum Hostname, es konnte aber keine Vertrauenskette gebildet werden.
Untrusted
Schlecht! Es gibt zwar ein Zertifikat und somit auch eine verschlüsselte Verbindung, denn noch stimmt etwas mit dem Zertifikat nicht. Es ist abgelaufen, passt nicht zum Hostname oder ähnliches.
Im Logfile findet es sich wie folgt:
Aug 3 18:34:08 servername postfix/smtp[1234]: Verified TLS connection established to mx01.domain.tld[1.2.3.4]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Aug 9 12:07:28 servername postfix/smtp[1234]: Trusted TLS connection established to mx01.domain.tld[1.2.3.4]:25: TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Aug 8 22:15:34 servername postfix/smtp[1234]: Anonymous TLS connection established to mx01.domain.tld[1.2.3.4]:25: TLSv1 with cipher ADH-AES256-SHA (256/256 bits)
Aug 7 21:48:48 servername postfix/smtp[1234]: Untrusted TLS connection established to mx01.domain.tld[1.2.3.4]:25: TLSv1.2 with cipher DHE-RSA-AES256-SHA256 (256/256 bits)
Was mich nun interessiert, ist die Tendenz der einzelnen Prüfungen. Wie sicher ist die Kommunikation zu anderen Mailservern wirklich, rein bezogen auf die Vertrauenswürdigkeit der eingesetzten Zertifikate. Eine schnelle Übersicht soll mir hier wieder der mailgraph liefern.
Den Mailgraph habe ich also, wie mit SPF, DKIM und DMARC ebenfalls, erweitert. Das nötige Patchset gibt es natürlich wieder unten. Dieses Mal habe ich darauf geachtet für die TLS Auswertung ein eigenes File für die RRD-Daten anzulegen. So kann ein bestehender Mailgraph einfach erweitert werden, ohne die vorhandenen Daten zu verlieren.
Heraus kommt am Ende dieser Graph.
Für interessiere finden sich die beiden nötigen Patchfiles hier:
Google lehnt hin und wieder E-Mails ab, die per IPv6 eingeliefert werden. Der Mailserver ist korrekt konfiguriert, SPF, DKIM, DMARC und DANE sind vorhanden, kein Eintrag auf irgendeiner Blacklist. Per IPv4 geht die gleiche Mail problemlos durch.
Die Fehlermeldung
550-5.7.1 Our system has detected that this message is likely
550-5.7.1 unsolicited mail. To reduce the amount of spam sent
550-5.7.1 to Gmail, this message has been blocked.
Der verlinkte Support-Artikel hilft nicht weiter. Alle Vorgaben sind erfüllt. Googles Antwort auf Nachfrage: „Warum genau eine E-Mail abgewiesen wird, können wir Ihnen leider nicht mitteilen.“ Das betrifft gmail.com, googlemail.com und jede bei Google gehostete Domain gleichermaßen.
Workaround: IPv4-only für Google
Da Google per IPv4 keine Probleme macht, lässt sich Postfix so konfigurieren, dass E-Mails an Google-Domains nur über IPv4 zugestellt werden. Das ist unnötig, ärgerlich und widerspricht dem Gedanken hinter IPv6. Aber es funktioniert.
In /etc/postfix/master.cf einen eigenen SMTP-Service anlegen, der nur IPv4 spricht:
smtp4 unix - - - - - smtp -o inet_protocols=ipv4
In /etc/postfix/main.cf die Transport Map aktivieren:
transport_maps = hash:/etc/postfix/transport
Die betroffenen Domains in /etc/postfix/transport eintragen:
googlemail.com smtp4:
gmail.com smtp4:
Anwenden und Postfix neu laden:
postmap /etc/postfix/transport
service postfix reload
E-Mails an Google-Domains gehen ab sofort nur noch über IPv4 raus. Wer weitere Domains pro Ziel steuern will, findet in Postfix TLS Policy Maps einen ähnlichen Ansatz.
Habe ich ganz aktuell gesehen dass sich über die Webseite ssl-tools.net nun ebenfalls die DANE RECORDS testen lassen. Also einmal ob sie vorhanden sind und natürlich auch die Gültigkeit des RECORDS. Zu dem Thema bin ich ja bereits ein paar mal gefragt worden, da „einfache“ Test Tools noch rar waren. Was sich ja inzwischen endlich zu ändern scheint.
Es gibt inzwischen viele Webtools die TLSA-Records prüfen. Aber wer es einmal von Hand gemacht hat, versteht was dabei passiert. Der Ablauf ist immer gleich: Zertifikat vom Server holen, Hash berechnen, mit dem DNS-Record vergleichen.
Zertifikat holen
Verbindung zum Mailserver aufbauen und das Zertifikat per STARTTLS abholen:
Welchen Hash man berechnen muss, hängt vom TLSA-Record ab. Die drei Felder im Record bestimmen das:
Usage
0 = CA, 1 = End-Entity (Kette muss gültig sein), 2 = Trust Anchor, 3 = End-Entity (keine Kettenprüfung)
Selector
0 = ganzes Zertifikat, 1 = nur Public Key (SPKI)
Matching Type
0 = exakter Vergleich, 1 = SHA-256, 2 = SHA-512
Am häufigsten sieht man 3 1 1 (End-Entity, nur Public Key, SHA-256) oder 3 0 1 (End-Entity, ganzes Zertifikat, SHA-256). Zuerst den TLSA-Record aus dem DNS holen um zu sehen was erwartet wird:
dig _25._tcp.smtp.kernel-error.de TLSA +short
Dann den passenden Hash berechnen. Bei Selector 0 (ganzes Zertifikat) und Matching Type 1 (SHA-256):
In der Ausgabe steht am Ende entweder Verified TLS connection established (DANE-Prüfung bestanden) oder eine Fehlermeldung mit dem konkreten Problem. Das Tool löst die MX-Records auf, holt den TLSA-Record, baut die TLS-Verbindung auf und vergleicht alles automatisch.
Das gefällt mir … Nachdem nun Yahoo die Eier hatte einfach mal ihre DMARC Policy „scharf“ (reject) zu schalten und sich so viel Schimpfe von aller Welt dafür eingesammelt hat und beschuldigt wurde die Mailinglisten „kaputt“ zu machen…. Tja, da zieht AOL nun in gewisser Weise nach: https://web.archive.org/web/20151222062444/http://postmaster-blog.aol.com/2014/04/22/aol-mail-updates-dmarc-policy-to-reject/
AOL hat nämlich gerade ein tierisches Spam-Problem. Also jetzt nicht direkt, eher haben andere das Problem, es betrifft AOL nur in soweit das deren Absenderdomain dafür missbraucht wird. Die Spam E-Mails sehen also so aus als wenn sie von AOL kommen. AOL hat nun also ihre DMARC Policy scharf geschaltet um das Problem damit etwas eindämmen zu können. Ob nun wohl so langsam Google und Microsoft ebenfalls nachziehen? Inzwischen sollten die Admins der Mailinglisten ja schon mal „warm“ gelaufen sein
Mailgraph von David Schweikert ist ein simples Perl-Script, das Postfix-Logdateien parst und daraus RRDtool-Graphen erzeugt. Empfangene, gesendete, abgelehnte Mails auf einen Blick. Für kleinere Mailserver oder Testsysteme reicht das völlig.
Was mailgraph nicht kann: SPF-, DMARC– und DKIM-Ergebnisse darstellen. Wie viele Mails bestehen den SPF-Check? Wie oft schlägt DMARC fehl? Gibt es einen Trend? Ich habe zwar einen existierenden SPF-Patch für mailgraph gefunden, wollte aber alle drei Protokolle in einem Aufwasch.
Die folgenden Patches erweitern mailgraph 1.14 um drei zusätzliche Graphen: SPF (pass/none/fail), DMARC (pass/none/fail) und DKIM (pass/none/fail). Ausgelegt für Postfix mit postfix-policyd-spf, opendkim und opendmarc.
Installation
Auf einem Debian-System müssen zwei Dateien ersetzt werden: /usr/sbin/mailgraph (der Daemon) und /usr/lib/cgi-bin/mailgraph.cgi (die Weboberfläche). Vorher sichern.
Der Daemon-Patch fügt neun RRD-Datasources hinzu (spfnone, spffail, spfpass, dmarcnone, dmarcfail, dmarcpass, dkimnone, dkimfail, dkimpass) und parst die Logzeilen von policy-spf, opendmarc und opendkim:
Der CGI-Patch erzeugt die drei neuen Graphen (SPF, DMARC, DKIM) und bindet sie in die HTML-Ausgabe ein. Jeder Graph zeigt pass als Fläche, none als Stack und fail als Linie:
Der Daemon-Patch erweitert die RRD-Datenbank um neun Datasources und erkennt im Syslog die Ausgaben von drei Diensten:
Dienst
Log-Pattern
Ergebnis
policy-spf
Received-SPF: pass/none/*
spfpass, spfnone, spffail
opendmarc
pass/none/fail
dmarcpass, dmarcnone, dmarcfail
opendkim
DKIM verification successful / no signature data / bad signature data
dkimpass, dkimnone, dkimfail
Der CGI-Patch erzeugt drei neue Graphen unterhalb der bestehenden. Jeder zeigt pass als Fläche, none als Stack darüber und fail als rote Linie. Die Zeiträume (Tag, Woche, Monat, Jahr) werden wie bei den Standard-Graphen automatisch erzeugt.
Hinweise
Die Patches sind für mailgraph 1.14 geschrieben. Weil mailgraph die RRD-Datasources beim ersten Start festlegt, muss nach dem Patchen die bestehende mailgraph.rrd gelöscht werden. Die alten Daten gehen dabei verloren, die neuen Graphen fangen bei Null an.
Wer heute mit dem Monitoring anfängt: rspamd bringt eine eigene Weboberfläche mit und prüft SPF, DKIM und DMARC in einem Durchgang. Zusammen mit Prometheus und Grafana bekommt man deutlich flexiblere Dashboards als mit RRDtool. Mailgraph bleibt trotzdem nützlich wenn man schnell was Schlankes braucht, das ohne externe Abhängigkeiten läuft.
Eine DMARC-Policy zu veröffentlichen ist die eine Seite. Die andere ist, eingehende Mails gegen die DMARC-Policy des Absenders zu prüfen. Postfix kann das nicht selbst. Dafür gibt es zwei Wege: OpenDMARC als eigenständigen Milter oder rspamd, der DMARC als eines von vielen Modulen mitbringt.
Variante 1: OpenDMARC
OpenDMARC ist ein dedizierter DMARC-Milter. Er liest die Ergebnisse von SPF und DKIM aus den Mailheadern und prüft ob die DMARC-Policy des Absenders erfüllt ist.
RejectFailures false ist ein guter Startwert. Damit werden Mails die den DMARC-Check nicht bestehen nicht sofort abgelehnt, sondern nur markiert. So kann man erst beobachten bevor man scharf schaltet. AuthservID muss zum Hostnamen des Mailservers passen.
Wichtig: OpenDMARC verlässt sich darauf, dass SPF und DKIM bereits geprüft wurden und die Ergebnisse in den Authentication-Results-Headern stehen. Die Reihenfolge der Milter in Postfix ist daher entscheidend: SPF und DKIM müssen vor OpenDMARC laufen.
Postfix-Integration
In der main.cf den Milter registrieren. OpenDMARC muss nach dem DKIM-Milter stehen:
Port 8891 ist hier OpenDKIM, Port 8893 OpenDMARC. Nach einem postfix reload prüft OpenDMARC jede eingehende Mail und schreibt einen Authentication-Results-Header mit dem DMARC-Ergebnis.
Variante 2: rspamd
Wer rspamd als Spamfilter einsetzt, braucht keinen separaten DMARC-Milter. rspamd prüft SPF, DKIM und DMARC in einem Durchgang und verrechnet das Ergebnis mit dem Gesamtscore. Das DMARC-Modul ist standardmäßig aktiv und unterstützt auch DMARC-Reporting (rua/ruf).
Der Vorteil von rspamd: Statt einer harten Ablehnung bei DMARC-Fail fließt das Ergebnis in die Gesamtbewertung ein. Eine Mail die DMARC nicht besteht aber sonst sauber aussieht, wird nicht sofort abgelehnt. Umgekehrt kann eine Mail die DMARC besteht trotzdem als Spam markiert werden wenn andere Indikatoren dagegen sprechen.
Was passt besser?
OpenDMARC
rspamd
Aufwand
Eigener Dienst, eigene Config
Bereits als Milter integriert
Verhalten
Harte Entscheidung (reject/accept)
Score-basiert, flexibel
Reporting
Eigenes Reporting-Tool nötig
rua-Reports eingebaut
Abhängigkeiten
Braucht SPF/DKIM in den Headern
Prüft SPF/DKIM selbst
Für neue Setups ist rspamd meist die bessere Wahl, weil es SPF, DKIM, DMARC, ARC und Spam-Filterung in einem Paket liefert. OpenDMARC ist sinnvoll wenn man einen minimalen Stack ohne Content-Filter will oder bereits einen anderen Spamfilter einsetzt.
Übrigens: DMARC und Mailinglisten vertragen sich nicht ohne Weiteres. ARC löst das Problem. Fragen? Einfach melden.
LEUTE… am 13 August 1982 wurde von einem Herrn David H. Crocker das RFC 733 überarbeitet. Somit wurde das RFC 733 ersetzt durch das RFC 822.
In diesem nun knapp 32 Jahre alten Dokument wurden die Mailheader In-Reply-To und Message-ID definiert. Warum ich das schreibe? Ganz einfach… Weil es noch nicht bei allen angekommen zu sein scheint, was jetzt nicht böse zu verstehen ist!
Ich möchte es daher einmal kurz erklären. Sollte ich jemanden auf diesen Eintrag verweisen, also bitte lesen
Wenn ich eine E-Mail an Klaus schreibe, dann erhält meine E-Mail automatisch eine einmalige Message-ID. Diese landet dann, für den Anwender unsichtbar im Mailheader. Antwortet Klaus nun auf diese E-Mail, bekommt seine Antwort natürlich ebenfalls eine MessageID, zusätzlich wird noch das Feld In-Reply-To gefolgt von der MessageID der Nachricht auf welche er gerade geantwortet hat in die E-Mail Header geschrieben.
Was bringt dieses? Nun, viele E-Mail Clients (japp Outlook seit ein paar Jahren auch) können E-Mail Nachrichten in der Form eines Gesprächsverlaufes anzeigen. Selbst wenn sich Betreff oder E-Mail-Inhalt komplett ändern. Dieses macht einem nicht nur das nachträgliche Verfolgen der E-Mail Kommunikation einfacher, sondern erleichtert einem extrem die Übersicht zu behalten. Da die E-Mail ja an eine völlig falsche Stelle einsortiert wird.
Alles funktioniert perfekt bis zu dem Moment in welchem jemand in einem völlig anderem Zusammenhang auf eine E-Mail antwortet. Also irgendeine alte E-Mail heraussuchen, auf antworten klicken, Betreff und Hinhalt löschen und eine „neue“ E-Mail schreiben. Das verbrennt nicht nur die Übersicht, sondern sorgt dafür das E-Mails sehr spät oder überhaupt nicht gelesen/beantwortet werden.
Habe ich dich auf diesen Text verwiesen, dann möchte ich dich (aus dem genannten Grund) mit Nachdruck darum bitte, mit bei neuen Themen eine neue E-Mail zu schreiben. Alle anderen nehmen es bitte als Information auf!
Für Detail bitte im RFC 822 besonders den Punkt 4.6.2. IN-REPLY-TO lesen: https://datatracker.ietf.org/doc/html/rfc822 und natürlich RTFM beim eigenen MUA betreiben. Bei Fragen, einfach fragen
Na was lese ich denn da wieder bei golem.de? Yahoo soll Mailinglisten kaputt machen weil DMARC eingesetzt wird?
Über DMARC habe ich ja schon etwas geschrieben, auch dass man mit Mailinglisten Probleme bekommen kann, wenn man eine Policy veröffentlicht. Denn die meisten Mailinglisten arbeiten leider nicht DKIM konform. Denn DKIM signiert den Body und ebenfalls den Betreff einer E-Mail. Wenn die Mailingliste nun den Betreff ändert um ein [Mailinglistenname] in den Betreff zu schreiben (damit die Anwender darüber besser „filtern“ können und wegen Übersicht bla bla). Sowie einen kleinen Footer mit Infos zur Liste in den Body hängen, ja dann ist die DKIM Signatur ungültig. Soll ja so sein! Mailinglisten lassen sich prima über den Mail-Header: List-id Filtern, die Infos zur Mailingliste im Footer liest eh keiner und es produziert nur unnötig viele Daten, da sie an jede E-Mail gehangen werden. Übersicht? Filtert man seine E-Mail sauber und sortiert sie in die passenden Ordner, dann ist die Übersicht gegeben.
Wie auch immer… DKIM Signaturen werden durch Mailinglisten schon seit vielen Jahren gebrochen. Einige Mailinglisten werfen sogar die DKIM Signaturen aus den E-Mails bevor sie „weitergeleitet“ werden. Damit kann es zwar keine ungültige/gebrochene Signatur mehr geben, in Kombination mit einer DMARC Policy gibt es denn noch ein Problem. Denn wenn in der Policy steht: E-Mails sind immer DKIM und SPF signiert und wenn sie es nicht sind oder wenn die Signatur ungültig ist, dann weise die E-Mail zurück. Dann passiert das so!
All dieses ist schon seit längerem fest in ein RFC gegossen. Eingesetzt wird DMARC bereits von vielen der großen Anbieter… Bisher war nur noch keiner cool genug es „scharf“ zu schalten. Ist völlig legitim, denn auch die Mailinglisten Admins sollen eine gewisse „Übergangszeit“ haben. Wie so oft hat nur kaum einer reagiert. Ist ja nur mal wieder Security oder Features welche die User nicht direkt betreffen. Ja, es ist eine gewisse Art ~Vergewaltigung~!
Der DMARC-RECORD von yahoo.com gibt eine klare Policy vor:
Ein Lehrstück über Mail, Macht, und die merkwürdige Waffe namens DNS
Es begann nicht mit Explosionen. Es begann mit einem Bounce.
Ein einziger, stiller Bounce – so leise, dass er in der täglichen Flut aus Logzeilen untergehen wollte. Ein 550, trocken wie Kreide:
550 5.1.1 <abuse@domain.tld>: Recipient address rejected: User unknown
Der Absender war ein kleiner Provider, irgendein abgegriffenes Abuse-Postfach, das seit Tagen versucht hatte, jemanden zu erreichen. Die Mail selbst war banal: „Ihre Domain wird für Spam missbraucht, bitte prüfen Sie Ihre Systeme.“ Keine Drohung, kein Drama. Nur ein Handgriff im Maschinenraum: „Schraube locker – bitte nachziehen.“
Nur war da niemand, der die Schraube nachzog.
Und genau da, in diesem winzigen, fast lächerlichen 550, begann die Operation.
1) Der Mann im Schatten der RFCs
In den frühen 2000ern war das Netz gleichzeitig größer und kleiner. Größer, weil plötzlich jeder einen Mailserver betreiben konnte. Kleiner, weil die Leute, die es wirklich taten, sich kannten – über Mailinglisten, Konferenzen, und die ewigen Schlachten um Anti-Spam-Policy.
Unser Protagonist – nennen wir ihn M. – war keiner von den Lauten. Kein Held, kein Prediger. Er war ein Admin mit dem seltenen Talent, die Welt nicht moralisch zu deuten, sondern operativ.
Seine Welt bestand aus:
maillog bei 3 Uhr morgens
MRTG-Graphen, die wie EKGs von sterbenden Routern aussahen
dig, tcpdump, grep
und den RFCs – nicht als Religion, sondern als Werkzeugkiste
M. hatte diese eine fixe Idee: Wenn das Netz schon aus freiwilligen Regeln besteht, dann sind Kontaktadressen die Nieten im Stahl. Ohne Nieten fällt der Kran auseinander. Und „Kontaktadresse“ hieß in diesem Bereich: postmaster@ und abuse@.
postmaster@ – der Notausgang für SMTP-Probleme, traditionell Pflicht in der Mailwelt
abuse@ – die Stelle, an die man Missbrauch meldet, wenn’s brennt
Und jetzt kam der Haken: Du konntest die beste Abuse-Meldung der Welt schreiben – wenn die Gegenseite „User unknown“ sagt, bleibt der Brand ein Waldbrand.
M. nannte das nicht „Ignoranz“ aus Spaß. Er meinte es wörtlich: Wer nicht erreichbar ist, ist für den Betrieb nicht existent.
2) Die erste Liste – wie man Druck baut, ohne eine Waffe anzufassen
Eines Abends – der Kaffee war kalt, der Pager lauter als nötig – schrieb M. eine kleine Zone-Datei. Kein Kunstwerk. Ein schlichtes Stück Text, ein paar A-Records, eine Reihe von Domains, die auf eine IP zeigten.
So funktionieren DNSBLs: Du drehst die Frage um.
Statt „Ist diese Domain gut?“ fragst du:
„Wenn ich reversed-stuff.blacklist.example nachschlage – bekomme ich eine Antwort?“
Bekommst du eine Antwort, ist es ein Treffer. Kein Treffer, keine Antwort.
DNS als binärer Schalter. Brutal. Elegant. Gefährlich.
M. wusste, was er da baute: eine Art Signalfeuer für Mailadmins. Keine Zensurbehörde – eher ein „da stimmt was nicht“-Indicator, der automatisch verwertbar war.
Das Ziel war simpel formuliert:
Domain betreibt MX (oder nutzt Mail)
aber postmaster@domain und/oder abuse@domain sind nicht erreichbar
also: Eintrag in „IGNORANT“
wer die Liste nutzt, kann Mails von dort markieren oder härter behandeln
Nicht blocken war die „sanfte“ Variante. Viele taten’s trotzdem, weil Admins Admins sind: Wenn es eine Kante gibt, wird sie genutzt.
M. sagte dazu nur: „Ich liefere Daten. Policy ist euer Problem.“ Und damit hatte er recht – und auch wieder nicht. Daten sind nie nur Daten, wenn sie in SMTP-Pipelines landen.
3) Der erste Feldtest – RCPT TO als Lügendetektor
Die Methode war bestechend, weil sie so alt war wie SMTP selbst: Frag den Server direkt.
Ein Testlauf sah im Kern so aus:
MX der Domain ermitteln
SMTP-Session öffnen
RCPT TO:<postmaster@domain>
RCPT TO:<abuse@domain>
Ergebnis klassifizieren
Einige Server antworteten sauber:
250 2.1.5 Ok – Empfänger akzeptiert
Andere waren ehrlich brutal:
550 5.1.1 User unknown – Empfänger existiert nicht
Manche waren schlüpfrig:
451 4.7.1 Try again later – temporär, könnte Rate-Limit sein
oder sie akzeptierten alles und bouncten später (Backscatter-Paradise)
M. baute Regeln. Nicht perfekt, aber besser als Bauchgefühl.
Die ersten Einträge in der Liste waren nicht „die Bösen“. Es waren oft schlicht:
kleine Firmen, die Mail „irgendwie“ hatten
Domains mit kaputten Weiterleitungen
„wir nutzen einen Provider“-Setups ohne Rollenpostfächer
oder verlassene Domains, die noch MX hatten, aber niemand mehr betreute
Und dann: große Namen. Weil große Namen nicht automatisch gute Hygiene bedeuten. Das machte die Liste berühmt. Und brachte die ersten Feinde.
4) Die Gegenwehr – Agenten mögen keine Aufmerksamkeit, DNSBLs bekommen sie gratis
Sobald die Liste sichtbar war, passierten drei Dinge gleichzeitig:
Admins waren dankbar, weil es endlich ein automatisierbares Signal gab.
Betroffene waren wütend, weil sie plötzlich Konsequenzen spürten.
Spammer wurden neugierig, weil jede Liste auch ein Kartendienst ist.
M. bekam Mails – ironischerweise auf die eigenen Kontaktadressen, die natürlich existierten. Viele waren sachlich: „Wie komme ich runter?“ Andere waren… weniger sachlich.
In der Welt der DNSBLs ist „Runterkommen“ kein Yoga. Es ist Ops:
Alias abuse@ anlegen
Alias postmaster@ anlegen
Monitoring drauf
dann Retest / Delist
Aber hier lag der eigentliche Konflikt: Viele wollten nicht „fixen“, sie wollten „weg“. Und zwar sofort. Ohne Aufwand. Ohne Veränderung. Ohne Verantwortung.
In Agentensprache: Sie wollten den Wachmann bestechen, statt die Tür zu reparieren.
M. war nicht käuflich – schon weil das Projekt nicht so funktionierte. Du konntest nicht „zahlen“, damit SMTP plötzlich 250 sagt.
Das machte ihn gefährlich. Nicht durch Macht – durch Unbestechlichkeit. Eine seltene Sorte.
5) Der schmutzige Teil – wenn „Kontakt“ plötzlich selbst ein Angriffsziel ist
Je größer die Liste wurde, desto absurder wurden die Nebeneffekte.
Abuse-Postfächer sind Müllhalden, wenn du sie nicht verteidigst. Sobald klar war: „abuse@ existiert“, wurde es von manchen als Spamziel missbraucht.
Einige Betreiber reagierten vorhersehbar falsch: Sie löschten abuse@ wieder. „Problem gelöst.“ Und landeten damit wieder in IGNORANT. Kreislauf geschlossen.
Andere machten’s richtig:
abuse@ als Ticket-Queue
harte Inbound-Filter (aber kein „User unknown“)
Rate-Limits
klare Auto-Responder mit Case-ID
und vor allem: menschliche Bearbeitung, wenn’s ernst wird
Und dann war da die technische Front: Last.
DNSBLs werden nicht „ab und zu“ befragt. Sie werden in Mailpipelines eingebaut – und dann feuert jede eingehende Verbindung Queries ab. Das kann klein anfangen und schnell grotesk werden.
M. musste plötzlich Dinge tun, die in keinem idealistischen Konzeptpapier stehen:
Anycast? Schön wär’s.
mehrere NS? Klar, aber kostet Zeit und Geld
Query-Rate begrenzen, ohne legitime Nutzer zu töten
Monitoring, sonst bist du blind
DoS-Abwehr, weil irgendwer’s „witzig“ findet
Agenten leben von Logistik. Und Logistik kostet.
Das Projekt, das als mahnender Zeigefinger begann, wurde zu Infrastruktur. Und Infrastruktur frisst Menschen.
6) Die philosophische Krise – wenn ein binärer Schalter moralische Debatten auslöst
Irgendwann war IGNORANT nicht mehr nur „eine Liste“. Es war ein Argument.
Die Debatten drehten sich nicht mehr um SMTP-Codes, sondern um Macht:
Darf man Domains „bestrafen“, weil sie nicht erreichbar sind?
Ist abuse@ wirklich Pflicht oder nur Tradition?
Wer kontrolliert die Liste?
Was ist mit False Positives?
Was ist mit Domains, die absichtlich keine Mail annehmen?
Die Wahrheit: Alle hatten ein bisschen recht, und genau das ist der Fluch der Netzpolitik.
Technisch ist es simpel: Ein Server akzeptiert oder akzeptiert nicht.
Operativ ist es komplex: Manche Domains wollen gar kein SMTP, haben aber trotzdem MX wegen Legacy. Manche Provider verstecken Rollenpostfächer hinter Formularen oder Portalen. Manche blocken „fremde“ Tests, weil sie Abuse-Scanning für Angriff halten. Und manche sind schlicht kaputt.
Die Liste war ein Hammer. Viele Probleme sind Nägel. Aber einige sind Glas.
M. wusste: Eine DNSBL ist immer zu grob für die Realität. Sie ist trotzdem nützlich, solange man sie als Signal nutzt – nicht als absolutistische Wahrheit.
Nur: Menschen lieben Absolutismus. Der ist bequem. Und bequem ist gefährlich.
7) Der Zeitenwandel – wenn Mega-Provider die Spielregeln ändern
Dann kam die nächste Welle: Zentralisierung.
Die Mailwelt kippte von „tausend kleine Server“ zu „ein paar riesige“.
Große Provider hatten ihre eigenen Systeme:
interne Reputation
Feedback-Loops
Abuse-Teams
automatisierte Takedowns
und vor allem: genug Personal, um nicht von einem DNSBL-Projekt abhängig zu sein
Gleichzeitig verschwanden viele kleine Betreiber – oder wurden zu Resellern, die keinen Zugriff mehr auf die eigentlichen Systeme hatten. Du konntest ihnen noch so oft sagen „macht abuse@“ – sie konnten oft nicht.
IGNORANT traf zunehmend die, die am wenigsten Hebel hatten. Und verfehlte zunehmend die, die wirklich Einfluss hatten.
Das ist der Moment, in dem Agentenfilme normalerweise einen Twist haben: Der Held merkt, dass seine Waffe nicht mehr trifft, was sie treffen soll.
8) Der letzte Einsatz – Hardware stirbt, Menschen auch (nur anders)
Am Ende war es nicht der große Gegner, der IGNORANT beendete. Es war die klassische, schäbige Realität:
alte Hardware
Wartungsaufwand
sinkende Zeit
steigender Ärger
und das Gefühl, dass man gegen Windmühlen schraubt
Ein DNSBL-Projekt kann man nicht „halb“ betreiben. Wenn du’s tust, wirst du selbst zur Fehlerquelle. Stale Data ist Gift. Und wenn du eine Liste fütterst, die andere in Mailannahme-Policy einbauen, ist „ungepflegt“ ein Sicherheitsrisiko.
M. machte das einzig Verantwortliche: Er zog den Stecker.
Keine dramatische Abschiedsrede. Eher eine Notiz am Schaltschrank: „Diese Maschine wird nicht mehr gewartet. Benutzung auf eigenes Risiko.“
Die Seite blieb als Geschichte. Als Warnung. Als Artefakt.
Wie ein altes Agentenhandbuch in einem Safe, das keiner mehr benutzt, aber jeder mal lesen sollte.
Field Notes – Was man aus der Akte mitnimmt (ohne Mythos)
A) Rollenpostfächer sind keine Folklore – sie sind Incident-Response-Mechanik
Wenn du Mail betreibst (direkt oder indirekt), brauchst du:
postmaster@domain – für SMTP-/Delivery-Probleme, Fehlkonfig, Policy
abuse@domain – für Missbrauch, Compromise, Spam, Phishing, Beschwerden
Nicht weil’s „nett“ ist – weil es operativ ist. Ohne erreichbaren Kanal wird jedes Problem langsamer, teurer, größer.
B) DNSBLs sind Werkzeuge – keine Orakel
Gut als Signal (Score, Tag, zusätzliche Prüfung) — mehr dazu in RBL und Postfix
gefährlich als harte Wahrheit (Reject ohne Kontext)
Wenn du so eine Liste nutzt: Logging, Exceptions, Monitoring. Keine Religion.
„accept-all then bounce“ = Sonderfall – Backscatter-Risiko
D) Der richtige Fix ist banal – und genau deshalb wird er oft nicht gemacht
Aliases anlegen
auf ein Ticket-/Queue-System routen
Filtern/Rate-Limiting, aber kein „User unknown“
Monitoring + Eskalation
Das ist kein Hexenwerk. Es ist Hygiene. Genau das macht’s so unbequem.
Epilog – Warum diese Geschichte heute noch zählt
Die Mailwelt hat sich geändert. Die Grundprobleme nicht.
Wenn du heute eine Domain betreibst und irgendwo Mail berührst (warum abuse@ und postmaster@ Pflicht sind) – direkt, über SaaS, über Provider – dann gilt immer noch:
Wenn man dich nicht erreichen kann, existierst du für Incident Response nicht. Und das Netz ist voll von Leuten, die dir gerne helfen würden, bevor es eskaliert – aber nur, wenn ein Postfach am anderen Ende nicht „User unknown“ sagt.
RFC-Ignorant war keine perfekte Maschine. Aber es war ein klares Signal aus einer Zeit, in der das Netz noch stärker auf freiwillige Betriebskultur angewiesen war.
Eine Agentengeschichte, nur ohne Pistolen. Stattdessen: DNS, SMTP, und ein 550, der die Welt erklärt.