Ich habe gerade nasse Füße, weil ich in der Stadt war und mein Regenschirm wohl doch etwas zu klein für die Kombination aus Wind und Wetter war. Oder vielleicht bin ich auch zu blind, um den Pfützen ausuzweichen. Wie auch immer, das schlägt mir auf die Laune, auch, wenn ich gerade mit dicken Wollsocken hier sitze und langsam wieder warm werde. Was mich aber momentan vielmehr wurmt, ist daß mein Kumpel Jonas so ein verdammtes Superhirn ist - und mich nichtmal an seiner Weisheit teilhaben lässt.

Jonas und ich schicken uns in unregelmäßigen Abständen kleine Kryptographie-Rätsel hin und her. Nichts kompliziertes, weil man es ja noch lösen können soll. Unregelmäßig deshalb, weil immer der aktuelle Empfänger das gegenwärtige Rätsel lösen muß, bevor er dem jeweils anderen eine neue Herausforderung schicken darf. Nun war letztens ich an der Reihe und dachte mir, ich bin mal kreativ. Ich habe also den Klartext der Nachricht in Blockgruppen gleicher Länge aufgetaucht und dabei alle vier Blöcke einen Füllblock eingefügt, um die Statistik zu verrauschen. Nicht ganz, ein bißchen Bias sollte ja noch drin bleiben, sonst hätte Jonas ja keine Chance gehabt. Bei der Wahl des Schlüssels habe ich auf eine Mersenne-Primzahl zurückgegriffen. Die habe ich ebenfalls in Blöcke aufgeteilt, bin ein paar hundert Gruppen "in die Zahl rein gegangen" und habe das ganze dann ver-XOR-t.

So, was jetzt wenig überraschend war, ist die Tatsache, daß Jonas auf den Klartext gekommen ist. Was mich aber wirklich wurmt: Er hat mir auf den Kopf die Nummer der Primzahl und die Anzahl der Blöcke, die ich übersprungen hatte, zugesagt. Und der Arsch (ja, Jonas, Du bist gemeint!) hat mir nicht verraten wollen, wie er da draufgekommen ist.

Jemand von Euch eine Idee? ;-(

Weil ich gerade die Mail sehe: Am Sonntag kam auf meinen Debian/stable-Kisten ein Update für das Paket "tzdata" an. Das Paket sorgt dafür, daß Zeitzoneninformationen korrekt umgesetzt werden, indem es erstens das Mapping der internen Uhr auf die Systemzeit durchführt (wenn also z.B. die interne Uhr mit GMT läuft, man aber in Berlin wohnt) und zweitens für das automatische Umschalten zwischen Sommer- und Winterzeit durchführt. Ein wenig gewundert habe ich mich ja schon, daß so ein Update kommt, weil ich nicht groß was damit anfangen konnte (Sommer- und Winterzeit gibt es ja nun nicht erst seit gestern), aber hier stehen die Hintergründe (DST steht für "Daylight Saving Time", also Sommerzeit). Das muß man unbedingt gelesen haben. Am besten gefällt mir folgendes Zitat:



Da mußte ich dann echt lachen!

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!

Da ich die neue Generation von Servern mittlerweile alle mit den x86_64-Kerneln (genauer dem 2.6.24-amd6-etchnhalf) laufen lasse, habe ich momentan so gut wie keinen Bedarf an Backports für die x86-Architektur - vielleicht hin und wieder mal ein Pakte wie doxygen oder so, aber definitiv keine größeren Server-Sachen mehr. Bzw. wenn, dann nur auf x86_64 und als Source zum selberbauen.

Wer noch Bedarf an guten und aktuellen Backports hat, dem sei die Seite von Dirk Prösdorf empfohlen (Pinning via "Pin: release o=Dirk"). Ansonsten bleibt ja immer noch der Griff zu backports.org oder die Suche via apt-get.org.