DNSWL in Postfix konsequent einsetzen
Geschrieben in
Technik
Montag, 20. Oktober 2008
Jeder Mailserver-Betreiber kennt DNS-Blacklisten. In Echtzeit kann der eigene Mailserver so mit einer einfachen DNS-Anfrage schon bei der Einlieferung einer Mail nachsehen, ob der verbundene Client schon früher unangenehm aufgefallen ist. Der Mechanismus funktioniert, wenn man ihn mit etwas Hirn und Bedacht (lies: Scoring-Mechanismen, Ausnahmelisten, beobachten der Policy der betreffenden DNSBL etc. pp.) einsetzt auch wirklich gut.
Das farbliche und funktionale Gegenteil einer DNS-Blacklist ist eine DNS-Whitelist. Da stehen die Hosts drin, von denen selten oder gar nie Spam versandt wird. Die meinem Empfinden nach bekannteste dieser Listen ist dnswl.org. Benutzt wird diese Liste wie alle anderen DNS-Blacklists auch:
Das ist soweit mal eine gute Sache - denn wenn man in dieser Liste drinne steht, wird der Mailversand ein Stückchen einfacher. So vergibt zum Beispiel jede halbwegs aktuelle Version von SpamAsassin (und dank sa-update kann mann eigentlich jede Version halbwegs aktuelle halten
) Bonuspunkte, wenn der einliefernde Mailserver in dieser Liste steht. Schon mal nicht schlecht, aber eine Sache bleibt verbesserungswürdig: Zu wenige Installationen nutzen dnswl.org, um einliefernden Mailservern Prüfungen wie Greylisting oder den Lookup in anderen DNSBLs zu ersparen - obwohl man das eigentlich tun sollte. Das liegt zum einen daran, daß fast jeder Mailserver eine Funktion mitbringt, um einen Client nach einem DNSBL-Treffer abzuweisen, aber fast keiner kennt ein Kommando für das Gegenteil. Dabei wäre es so einfach. Unter Postfix z.B. hat man ja meistens irgendwie die folgende Struktur in den Zugriffsregelungen drin:
So, vor die RBL- und Greylisting checks kommt jetzt einfach ein
Und diese Datei lässt man einmal am Tag folgendermaßen erzeugen:
Einmal am Tag reicht wirklich, so oft ändern sich die Daten ja nicht. Neustarten muß man Postfix danach auch nicht, der kriegt Änderungen in Lookup-Tabellen von selber mit. Das ganze einzurichten dauert - vorausgesetzt man kennt die Struktur der eigenen Access-Regeln - ungefähr zwei Minuten, vielleicht drei, wenn man die rsync-Adresse nachsehen muß. Ich verstehe nicht, warum so viele Leute das nicht geregelt kriege. Besonders schlimm ist das, wenn die empfangenden Server selber in der Liste stehen - da reicht's dann bei mir nur noch zum Kopfschütteln.
So. Das war jetzt die Technik für heute. Aber es ist ja Montag, es ist kurz nach 04:00 Uhr, ich bin noch nicht lange wach und die Woche wird lang. Deswegen habe ich noch etwas für Euch - genauer gesagt "Romeo And Juliet" von den "Killers":
Wer sich das jetzt nicht in Ruhe, mit geschlossenen Augen anhört und auch, wer bei dem Lied nicht spontan an Kuscheln oder ein Konzert mit tausenden Feuerzeugen denken muß, bei dem stimmt irgendwas nicht.
Viel Spaß Euch da draußen, und eine schöne Woche!
Das farbliche und funktionale Gegenteil einer DNS-Blacklist ist eine DNS-Whitelist. Da stehen die Hosts drin, von denen selten oder gar nie Spam versandt wird. Die meinem Empfinden nach bekannteste dieser Listen ist dnswl.org. Benutzt wird diese Liste wie alle anderen DNS-Blacklists auch:
CODE:
# dig 53.107.214.85.list.dnswl.org +short
127.0.6.1
Das ist soweit mal eine gute Sache - denn wenn man in dieser Liste drinne steht, wird der Mailversand ein Stückchen einfacher. So vergibt zum Beispiel jede halbwegs aktuelle Version von SpamAsassin (und dank sa-update kann mann eigentlich jede Version halbwegs aktuelle halten
) Bonuspunkte, wenn der einliefernde Mailserver in dieser Liste steht. Schon mal nicht schlecht, aber eine Sache bleibt verbesserungswürdig: Zu wenige Installationen nutzen dnswl.org, um einliefernden Mailservern Prüfungen wie Greylisting oder den Lookup in anderen DNSBLs zu ersparen - obwohl man das eigentlich tun sollte. Das liegt zum einen daran, daß fast jeder Mailserver eine Funktion mitbringt, um einen Client nach einem DNSBL-Treffer abzuweisen, aber fast keiner kennt ein Kommando für das Gegenteil. Dabei wäre es so einfach. Unter Postfix z.B. hat man ja meistens irgendwie die folgende Struktur in den Zugriffsregelungen drin:CODE:
smtpd_recipient_restrictions =
...
...
permit_mynetworks
reject_unauth_destination
...
<Greylisting/RBL-Checks>
...
So, vor die RBL- und Greylisting checks kommt jetzt einfach ein
CODE:
check_client_access cidr:/etc/postfix/dnswl-permit.cidr
Und diese Datei lässt man einmal am Tag folgendermaßen erzeugen:
CODE:
# renew DNSWL data
/usr/bin/rsync --times rsync1.dnswl.org::dnswl/postfix-dnswl-permit /etc/postfix/dnswl-permit.cidr
Einmal am Tag reicht wirklich, so oft ändern sich die Daten ja nicht. Neustarten muß man Postfix danach auch nicht, der kriegt Änderungen in Lookup-Tabellen von selber mit. Das ganze einzurichten dauert - vorausgesetzt man kennt die Struktur der eigenen Access-Regeln - ungefähr zwei Minuten, vielleicht drei, wenn man die rsync-Adresse nachsehen muß. Ich verstehe nicht, warum so viele Leute das nicht geregelt kriege. Besonders schlimm ist das, wenn die empfangenden Server selber in der Liste stehen - da reicht's dann bei mir nur noch zum Kopfschütteln.
So. Das war jetzt die Technik für heute. Aber es ist ja Montag, es ist kurz nach 04:00 Uhr, ich bin noch nicht lange wach und die Woche wird lang. Deswegen habe ich noch etwas für Euch - genauer gesagt "Romeo And Juliet" von den "Killers":
Wer sich das jetzt nicht in Ruhe, mit geschlossenen Augen anhört und auch, wer bei dem Lied nicht spontan an Kuscheln oder ein Konzert mit tausenden Feuerzeugen denken muß, bei dem stimmt irgendwas nicht.
Viel Spaß Euch da draußen, und eine schöne Woche!
