Ich habe gerade den nächsten Snapshot von Postfix 2.8 in mein Repository geworfen. An Neuerungen gibt es zum einen die access(5)-Direktive „reject_rhsbl_reverse_client”, bei der man auf den unverifizierten Hostnamen losgehen kann, sowie die Möglichkeit, Postfix zu sagen, ob es bei MX-Einträgen mit gleicher Priorität (oder bei einem MX-Eintrag, hinter dem mehrere IP-Adressen liegen) zuerst IPv6 oder IPv4 probieren soll („smtp_address_preference”).

Wie immer gilt: Alles auf eigene Gefahr.

Update: Da fehlt folgender Patch:



Ich reiche heute noch korrigierte Pakete nach - bis dahin sollte man auf den Einsatz des lmtp(8)-Clients verzichten (oder eben selber bauen).

Update 2: Ich habe die Pakete aktualisiert. Entschuldigung für etwaige Unannehmlichkeiten

Anmerkung: Eigentlich müsste der Titel dieses Eintrags folgendermaßen lauten: „SpamAssassin - warum automatische Updates toll sind, und wie man sich trotzdem in den Fuß schießen kann”.

Jedes Open Source-Projekt muß einmal einen kapitalen Bock schießen. Bei Debian z.B. hatten wir 2008 das OpenSSL-Desaster. Damals habe ich auch vier Zertifikate neu anfordern dürfen - von externen CAs, natürlich. Davon, daß es meine private CA ebenso erwischt hat und ich in einem großen Rundumschlag auch gleich alle SSH-Keys (Host- und User!) ausgetauscht habe, davon wollen wir hier gar nicht anfangen. Eine ganz andere Mongose hat sich die SpamAssassin-Truppe geleistet. Für diejenigen, die SpamAssassin nicht kennen: Das dürfte der mit Abstand am weitesten verbreitete Spam-Scanner im Open Source-Bereich sein. Die in Perl geschriebene Applikation führt diverse Tests mit jeder Mail durch, die man ihm vorwirft, und berechnet daraus eine Punktzahl. In den Default-Einstellungen werden Mails ab einer Punktzahl von 6.31 als Spam markiert (kann sein, daß die 6.31 jetzt von amavisd-new kommt, ich habe SA schon seit Ewigkeiten nicht mehr „solo” eingesetzt).

Nun gibt es im Regelwerk eine Regel mit dem schönen Namen „FH_DATE_PAST_20XX”. Deren ursprünglicher Sinn war es eigentlich zu schauen, ob der „Date:”-Header einer Mail zu weit in der Zukunft liegt (Spammer machen das ganz gerne, weil die Mail dann bei vielen MUAs an prominenter Stelle im Posteingang landet). Ist das der Fall, werden 3.41 Punkte extra vergeben - das ist also schon „mehr als die halbe Miete”. Anfang 2008 ist dann jemandem aufgefallen, daß diese Regel (und eine ähnliche) uns im Jahr 2010 Probleme bereiten werden. Die Regel wurde also korrigiert und in die Versionskontroll-Software eingepflegt, und damit war das Thema eigentlich auch schon wieder abgeschlossen. Denn SpamAssassin, so muß man wissen, verfügt über ein kleines Tool mit Namen sa-update, mit welchem sich die Regeln auch zwischen verschiedenen Releases des kompletten Programms aktuell halten lassen - ähnlich wie bei einem Virenscanner. Die Regeln, die das Projekt über seine Update-Kanäle bereit stellt, kommen vereinfacht gesagt aus der vorhin erwähnten Software zur Versionskontrolle. Regeln, die dort von den Entwicklern z.B. als passend für das Release 3.2 markiert werden, stehen kurze Zeit später auch für Updates bereit.

Dummerweise hat man nun genau diese Markierung (dieses „Tag”) vergessen, und so flog pünktlich zum Jahreswechel eine größere Zahl von Kufhladen in den Ventilator. Das Problem haben die Entwickler relativ schnell in den Griff bekommen, und jede Installation, die seit damals auch nur einmal „sa-update” aufgerufen hat, ist frei von diesem Fehler.

Das alles ist Geschichte, und ihr fragt Euch zurecht, warum ich solche alten Kamellen (oder solche alten Mannheimer Tüten?) hier erwähne. Das ganze hat zwei einfache Gründe: Man muß - NATÜRLICH! - erstmal „sa-update” aufrufen, um überhaupt in den Genuß der Regelupdates zu kommen. Eigentlich sollte das so klar wie Kloßbrühe sein, aber die traurige Wahrheit ist, daß da draußen eine ganze Menge Leute Mailserver betreiben, denen man eigentlich gar keine Server vermieten (oder anderweitig zur Verfügung stellen) dürfte. Und solche Vollhonks sind dann natürlich wahnsinnig heiße Kandidaten für Probleme wie das oben geschilderte. Was tut man also, als halbwegs verantwortungsvoller Distributor (egal, ob man jetzt eine Linux-Distribution oder einen *BSD-Port bereitstellt)? Genau, man führt einen Automatismus ein, der das dem Luser abnimmt. Unter Debian z.B. macht das einmal am Tag das Skript „/etc/cron.daily/spamassassin”, zumindest, wenn man in der Datei „/etc/default/spamassassin” den Wert der Variable „CRON” von 0 auf irgendwas anderes geändert hat (letztere Datei ist übrigens auch ein geeigneter Ort für eine Anweisung à la „export http_proxy=http://proxy:3128/” o.Ä.). Ich weiß auch nicht, ob das im derzeitigen Paket noch drin ist, aber bei der Erstinstallation habe ich irgendwann sogar mal so eine schöne Dialogbox bekommen, in der ich das automatische Update aktivieren konnte. Damit hätten wir den ersten Punkt auf der Liste abgehakt.

Wie ich gerade von einem Bekannten im IRC erfahren durfte, gibt es aber anscheinend noch eine zweite Hürde beim automatischen Update der SA-Regeln: Man muß es richtig machen! In dem mir zugetragenen Fall hatte jemand tagaus, tagein brav „sa-update” aufgerufen. Die Person ist sogar so weit gegangen und hat verifiziert, daß die Regeln - die bei ihr unter „/var/lib/spamassassin” lagen - sich auch wirklich immer aktualisieren und daß ihr Spamfilter - sie hat die Spamassassin-Module via amavisd-new benutzt - auch wirklich diesen Regelsatz benutzt (liebe Kinder, das ist schon ungefähr das dreifache von dem, was die üblichen Verdächtigen so unternehmen). Jetzt könnt ihr Euch bestimmt ihre Überraschung vorstellen, als sie - vor zwei Wochen, soviel dann zu Gründlichkeit und Lesen von Logfiles - bemerkt hat, daß ankommende Mails nach wie vor nicht nur 3.4 Extrapunkte von der Datums-Regel bekamen, sondern auch noch ganz anderen Fallout (mit 2.4 Punkten) erlitten.

Mein Kumpel hat sich dann mal den Server angesehen und dabei festgestellt, daß das erwähnte Update-Skript von Debian nach einem Regel-Update den Dienst „spamassassin” (präziser: den spamd-Dämon) neu initialisiert - das jedoch juckt „amavisd-new” überhaupt nicht. Soviel dann zu „man muß es richtig machen”. Und darum gilt nach wie vor: Wer vorhat, Server zu betreiben und dort bestimmte Applikationen einzusetzen, dem bleibt es auch im Jahr 2010 nicht erspart, sich genauestens mit der Applikation selbst, aber auch mit dem von seiner Distribution bereitgestellten Rahmenwerk auseinander zu setzen.

Zur Entspannung: Die „White Stripes” mit „Seven Nation Army” - enjoy:

Dem gibt es nichts hinzuzufügen

Das wurde aber auch mal Zeit: RFC 5782 standardisiert DNS White- und Blacklisten. Shouts an J. Levine, das war nicht nur überfällig, sondern auch gute Arbeit

Am Samstag hat Wietse Venema die erste stabile Version von Postfix 2.7 freigegeben und den nächsten Entwicklungszyklus mit der Version 2.8-20100213 begonnen. Beide Pakete finden sich mittlerweile in meinem Repository, der 2.7-Zweig allerdings nicht in „cite-backports”, sondern in „postfix-lenny-backports”. Die Versionen unterscheiden sich bis auf das Vorhandensein von postscreen(8) im 2.8er-Tree nicht voneinander - derzeit.

Ich habe bei beiden Paketen die von Debian modifizierten Dateien „main.cf” und „master.cf” wieder durch die Originale aus dem Upstream-Tarball ausgetauscht. Das bedeutet zum Einen, daß der smtpd(8) nicht mehr in einer chroot-Umgebung ausgeführt wird und zum Anderen, daß die „main.cf” eine große Menge überflüssiger Einträge enthält - das sollte aber für ernsthafte Postfix-Admins kein Hinderniss sein.

Wenn „some_command” mir eine Liste von Usernamen und deren (virtuellen) Home-Verzeichnissen ausgibt:



Natürlich nicht ganz so, zuviel fork(2), aber ich will in's Bett. Sobald ich mir da was überlegt habe, update ich das hier einfach. Nifty!

Falsch:



Richtig:



Und warum? Weil die erste Lösung dreimal forkt und zwei Pipes aufmacht.

Wenn ihr denkt, das sowas schon verwirrend ist (sorry, mir sind die Fitness-Videos ohne Jungendschutz-Problem ausgegangen):



BTW, wer ist dafür, daß ich hier öffentlich ein Skript zerreiße, daß ich in der freien Wildbahn gesehen habe?

Nur zur Vorwarnung hier eine Mail, die gerade über die Mailingliste clamav-mirrors ging:



Soll heißen, daß es wahrscheinlich ist, daß hier am 15./16. Februar alles etwas langsamer gehen könnte - Bandbreite und so. Irgendwann leiste ich mir mal einen wirklich tollen, gehosteten Server mit GBit-Anbindung.

Es wird unglaublich spannend (oder, naja, vielleicht auch nicht) - Wietse Venema hat vor kurzem den ersten Release Candidate von Postfix 2.7.0 veröffentlicht. Die beiden letzten Programm-Bugfixes seit 20100117 betreffen die Art und Weise, wie langlebige Prozesse behandelt werden (unerfreuliche Sache, das, irgendwie) sowie eine verbesserte Erkennung von unberechtigtem PIPELINING. An der Doku gab es zwei kleine Änderungen - und eine ziemlich große. Patrick Ben Koetter, einer von zwei Autoren von The Book of Postfix und Postfix - Einrichtung, Betrieb und Wartung hat es nach langem Kampf endlich geschafft, eine aktuelle Version seines SASL-Readmes in die offizielle Dokumentation zu kriegen - herzlichen Glückwunsch, Patrick!

Zu finden ist das ganze als Debian-Paket für lenny/stable wie immer hier.

Update: Entweder hat Wietse postscreen(8) für 2.7.0-RC1 gedroppt oder ich bin gerade zu doof. Alles auf HALT!

Update 2: Tja, postscreen(8) schafft es wohl erst in 2.8. Ich habe die Pakete mal auf den Stand 2.7-20100117 zurück gerollt. Da ist mal echt schade - ich weiß noch gar nicht, wie ich das jetzt abhandeln soll