Kategorie: Kernel-Error-Blog (Seite 30 von 49)

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
• 550 5.7.1 Access denied – Policy-Block, manchmal blind
• 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)
• gefährlich als harte Wahrheit (Reject ohne Kontext)

Wenn du so eine Liste nutzt: Logging, Exceptions, Monitoring. Keine Religion.

C) Tests müssen sauber sein

Ein einfacher, reproduzierbarer Ansatz:

domain=example.org
dig +short MX "$domain" | sort -n
mx=$(dig +short MX "$domain" | sort -n | head -1 | awk '{print $2}' | sed 's/\.$//')

# SMTP-Handshake – minimal
openssl s_client -starttls smtp -crlf -connect "$mx:25" <<EOF
EHLO test.invalid
MAIL FROM:<probe@test.invalid>
RCPT TO:<postmaster@$domain>
RCPT TO:<abuse@$domain>
QUIT
EOF

Interpretation:

• 250 bei RCPT = existiert/akzeptiert
• 550 5.1.1 = typischer „existiert nicht“
• 451/421 = temporär – retesten, Rate-Limits beachten
• „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 – 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.