Sehr schönes Paper, das letzte Woche auf der CEAS-Konferenz vorgestellt wurde: Exploring the Spam Arms Race to Characterize Spam Evolution.

Schöne Woche Euch allen!

In den letzten zwei Jahren hat es der IMAP/POP3-Server Dovecot geschafft, eine mehr als nur ernstzunehmende Alternative zu den Platzhirschen Cyrus und Courier zu werden. Schnell, pflegeleicht, sicher meistens stabil (obwohl der Autor hier schon ein paar Versionen rausgegeben hat, die als Reinfall gelten dürfen) und vor allem hochgradig flexibel und damit sehr leicht in bestehende Infrastrukturen einzubinden. Und so ist es auch nicht weiter verwunderlich, daß ich, wenn ich mal um Hilfe bei Mailservern gebeten werde, in letzter Zeit fast nur noch Dovecot-Server sehe.

Was die Authentifizierung angeht, so verwendet Dovecot ein Konzept, welches man so z.B. auch von PAM/NSS kennt. Es gibt zum einen eine Paßwort-Datenbank, die lediglich Benutzernamen und Paßwörter kennt. Die wird natürlich bei einem normalen Login benötigt, wenn sich also ein Client z.B. via IMAP verbinden will, aber auch, wenn Dovecot z.B. als SASL-Server für einen MTA dient, der Benutzer also Mails verschicken will und sich dazu beim Mailserver authentifizieren muß. Die zweite Datenbank liefert zu einem Benutzer Daten wie z.B. dessen Home-Directory, seine UID/GID, Quotas etc. (dabei kann es sich natürlich um "echte" Unix-User handeln oder um irgendwas Virtuelles). Und weil es so einfach ist, dafür Webappliaktionen zum Management zu schreiben, findet man im SOHO-Bereich eben oft die Konstellation, daß Dovecot die virtuellen Benutzer aus einer SQL-Datenbank zieht.

Und da kommt jetzt die Sache, die bei mir jedes Mal wieder Unverständnis auslöst: Viele Leute benutzen den Dovecot-LDA, besser bekannt als „deliver”. Das hat viele Vorteile, z.B. daß die Index-Files automatisch angepasst werden. Oder einfach die Tatsache, daß das Ding Sieve kann. Der LDA erwartet eine Adresse, an die er die Mail zustellen soll. In der Konfiguration muß also bei obigem Setup ein Query hinterlegt sein (und noch ein paar andere Einträge), so daß „user@example.com” irgendwie zu einem Pfad wie „/srv/vmail/u/user/Maildir” wird. Das ist trivial zu bewerkstelligen. Aber es gibt natürlich noch den zweiten Anwendungsfall: Ein Benutzer loggt sich via IMAP ein und will seine Mails abrufen. Wenn man jetzt davon ausgeht, daß der Benutzername nicht gleich der Mailadresse ist sondern z.B. nur „user” (wie es ja eigentlich best practice ist), dann müsste hierfür eigentlich ein ganz anderes Query hinterlegt sein. Und genau das ist es, was mir in der freien Wildbahn so gut wie nie begegnet. Im Gegenteil - hier mal eines meiner Highlights:



Interessant ist hier natürlich genau der OR-Teil, denn er beschreibt ja genau obiges Dilemma. Dabei könnte mit den entsprechenden Views und zwei Konfigurationsdateien alles so einfach sein:



Und deswegen an dieser Stelle zwei Anmerkungen:

1. „deliver” kann man mit dem Parameter „-c” eine eigene Konfigurationsdatei mitgeben.
2. Wenn ihr schon Datenbanken benutzt, dann macht es gescheit.

Schönes Wochenende noch!

Keiner mehr im Büro. Endanwender mit Problem. Eigentlich noch anderweitig beschäftigt, aber man will ja helfen. „Dauert ca. 20 Minuten, dann sollte es wieder tun.” - „Was, so lange brauchst Du?”

Wie kann ich nur auf sowas noch reinfallen? Natürlich habe ich es dann in unter zwei Minuten gefixed. Nach einem Blick auf die Hierarchieebene, in der sich besagter Endanwender befand, wurde mir dann einiges klar. Irgendwie verdient, muß ich sagen. So auf den Leim bin ich schon lange niemandem mehr gegangen. Guter Instinkt, genau an der richtigen Stelle gepackt. Word, Dirk!

Ich habe gerade Postfix 2.7.1 in mein Archiv geworfen. Die wichtigste Änderung laut Announcement ist sicher ein Bugfix im XFORWARD-Code des SMTP-Clients.

Wie immer gilt: Benutzung auf eigene Gefahr, die Pakete sind nicht identisch mit denen aus Debian/unstable (siehe changelog.Debian.gz).

Als jemand, der sein Geld im IT-Bereich verdient, bin ich ich gerade ein kleines bisschen gestorben:



Acht Prozent. Und plötzlich wundert mich gar nichts mehr.

Der Titel sagt es schon: OpenWRT Backfire unterstützt jetzt auch auf brcm47xx-Devices wie z.B. meinem Asus WL500gP Kernel 2.6. Sehr nice! Das Upgrade verlief mehr oder weniger Problemlos. Die Dateien „luci_hosts” und „luci_ethers” werden bei ersten Neustart in die Datei „dhcp” integriert (alles zu finden in /etc/config). Bei mir hat ein opkg install 6scripts radvd interssanterweise weder „ip” noch „kmod-sit” nachgezogen, aber das war schnell behoben. Ich sage einfach mal:

Hallo IPSEC in gut!

Beim Lesen der Überschrift werden sich viele Leute nur „WTF?” denken - dürften die meisten doch davon ausgehen, daß ihre Installation von amavisd-new, wenn sie denn einen Virenscanner benutzen, selbigen auch nur einmal auf jede ankommende Mail loslässt. Normalerweise ist das auch so. Jetzt gibt es aber Situationen, in denen man die ganze Mail braucht, um sie dem Scanner vorzuwerfen, z.B. die Sanesecurity-Signaturen, was man folgendermaßen erreichen kann:



Leider führt das dazu, daß einige Funktionen nicht mehr vernünftig arbeiten, unter anderem das Blocken von Attachments nach Typ oder der Bounce Killer. Also gehen viele den Weg, oben genannten Wert doch auf seinem Default zu belassen und fügen statt dessen in die Map @keep_decoded_original_maps folgende Zeile ein:



Damit hebt amavisd-new die komplette Mail auf - man hat also einen funktionierenden Bounce Killer, funktionierendes Attachment-Blocking und Sanesecurity-Signaturen. Dummerweise scannt der Virenscanner die Mail aber jetzt effektiv zweimal: Einmal die im Original erhaltene Mail und einmal deren einzelne Teile. Um das zu umgehen kann man ganz einfach die Definition des Virenscanners verändern:



Gerade in hochvolumigen Setups dürfte das nochmal einiges an Performance-Zugewinn bringen.

Die Sonne scheint, ich habe zwei tolle CDs mit Chopin-Nocturnes gerade auf meinen MP3-Player kopiert und werde das tolle Wetter jetzt ausnutzen, um Skaten zu gehen

Kurze Durchsage: Mich regt diese dem neudeutschen entlehnte Grußformel auf:



Das klingt wirklich dämlich. Und, was schlimmer ist, es wirkt anbiedernd.

Ich mag Filme von David Lynch: Man versteht die ersten zwanzig mal nur die Hälfte des Films und hat auch beim vierzigsten Mal noch das Gefühl, daß einem etwas Wichtiges entgeht, aber ich finde sie trotzdem toll. Auch und vor allem, weil sie so surreal anmuten. Was ich dagegen überhaupt nicht schätze, ist wenn sich in meinem Berufsleben Anspruch und Realität zueinander surreal verhalten - und glücklicherweise ist die Firma, in der ich derzeit arbeite, weit davon entfernt, mit solchen Problemen kämpfen zu müssen, egal ob in der IT oder in anderen Bereichen des Unternehmens. Umso amüsanter ist es, wenn ich dann von anderen Firmen mitbekomme, wie die Dinge dort manchmal gehandhabt werden.

Eine besonders, äh, „interessante” Geschichte habe ich gestern erlebt - und zwar mit einer richtig großen Bank. Einer wirklich großen. Einer, die jeder von Euch kennt - und deren Name, das sei hier dazu gesagt, weder mit „D”, „N” oder „S” anfängt. Zwischen besagter Bank und uns gibt es schon seit längerem eine Kooperation, die auch den Austausch kleiner Datenmengen beinhaltet. Damit man dort nicht auf Mails angewiesen ist, besteht zwischen uns und der zentralen IT dieser Bank, deren Netzwerk hier den Namen PrivateNet tragen soll, schon seit längerem eine VPN-Verbindung. Auf unserer Seite ist der PrivateNet-Tunnel ganz normal in einer dedizierten, hochverfügbaren DMZ auf zwei redundanten VPN-Routern terminiert, klassische Netztrennung, Zugriff aus dieser DMZ gibt es nur auf gesondert gesicherte weil eben für den Datenaustausch mit externen Partnern vorgesehene Server. Sowohl unsere VPN-Kisten als auch die Datenaustausch-Server stehen natürlich nicht bei uns im Keller (Büroraum in München ist viel zu teuer für solche Vorhaben), sondern in einem externen Rechenzentrum, komplett mit Sicherheitsmaßnahmen, die Panzer abwehren können sollen und mehrfach redundanten Anbindungen an Strom und „Internet”. Soweit ist nichts unüblich, aber bei der Beschreibung fällt vielleicht schon auf, daß ich mehrmals Worte wie „redundant” oder „hochverfügbar” verwendet habe - sprich, die Chancen, daß diese Anbindungen jemals ausfallen, sind recht gering (und daß unsere Konzepte nicht nur in der Theorie funktionieren wissen wir, weil wir mindestens einmal pro Jahr im RZ einfallen und dort nach Lust und Laune Kabel herausrupfen. Na ja, nicht ganz so, aber ihr ahnt, worauf ich hinauswill: Failover-Testing halt). Und so könnte eigentlich auch alles gut sein.

Ist es aber nicht. Seit kurzem besteht besagte Bank darauf, daß wir die Anbindung an sie nicht mehr über VPN-Tunnel vornehmen. Zum einen sei das zu unsicher und zum anderen könne man ja die Verfügbarkeit nicht gewährleisten. Deswegen werden wir nun mehr oder weniger dazu „ermuntert”, die Anbindung auf eine einzelne Business-SDSL-Strecke umzustellen. Wer jetzt „WTF?!?” denkt, dem geht es genauso wie mir, die IT unseres Partners jedoch versteht da wenig Spaß.

Gestern also hatte ich die Gelegenheit, ein Gespräch (zwar nur unsere Seite, aber das war vielsagend genug) zwischen dem bei uns für externe Verbindungen zuständigen Mitarbeiter und seinem Pendant bei PrivateNet mitzubekommen. Und plötzlich wundert mich nichts mehr: Die IT dieser wirklich, wirklich großen Bank hat anscheinend noch nie etwas von RFC 5737, ja, noch nicht mal was von RFC1918 gehört. Die Liste der IP-Adressen, die man uns als Transfernetze angeboten hat, liest sich wie das „Who is Who” der großen, vor dem Internet-Boom vergebenen Allokationen. Auf die vorsichtige Frage meines Kollegen hin, ob besagte Bank diese IP-Adressen denn auch alle besitze, wurde ihm versichert, das sei kein Problem, innerhalb des PrivateNet seien die meisten der angebotenen IP-Adressen routebar und eindeutig, man arbeite ja professionell.

Manchmal besteht zwischen Selbstwahrnehmung und Realität eben eine wirklich ausgeprägte Dichotomie. Ich glaube, der Kollege hat besagte Bank dazu bekommen, die Adressen für die Verbindung zu uns in den RFC1918-Space hinein zu NAten. Und das sollte man sich jetzt wirklich mal auf der Zunge zergehen lassen

Man hat mich einmal beschuldigt (das war glaube ich nach einer Party in der Erziehungswissenschaftlichen Fakultät. Junge Dinger, die Grundschullehramt studieren. Da kriegt man als Kerl den freien Eintritt und den Getränkegutschein. Verkehrte Welt und so. Nach dazu keine geschlossene Angelegenheit wie z.B. die Parties bei den Tiermedizinerinnen, wo man nur reinkommt, wenn man jemanden kennt!), daß für mich ein Tag nur dann gut anfängt, wenn ich mich schon direkt nach dem Aufwachen am Unglück anderer Leute erfreuen kann.Das ist natürlich Käse, denn die Qualität meines Tagesanfangs misst sich, wie ich bereits erwähnte, an der Menge von Speck und Eiern, die ich noch im Kühlschrank habe. Wenn obige Anschuldigung aber richtig gewesen wäre, dann wäre das Aufstehen in den letzten Tagen eine großartige Sache gewesen. Oder genauer: Seit dem 15. April. Denn der 15. April war der Tag, an dem das Entwickler-Team hinter dem OSS-Virenscanner ClamAV alle Versionen vor 0.95 lahmgelegt hat. Rein technisch geschah das durch ein einfaches Signaturupdate, wie sie mehrmals täglich stattfinden - nur diesmal eines, das die alten Versionen nicht vertragen haben:



Man muß an dieser Stelle übrigens die Eleganz des ganzen bewundern - ist doch obiges gleich das beste Beispiel dafür, warum sich die Entwickler zu diesem Schritt entschlossen haben. Aber weiter im Text: Die ClamAV-Entwickler halten es schon seit langem so, daß ihr Scanner immer dann überhaupt nicht mehr funktioniert, wenn seine Datenbank kaputt ist. Und da der Update-Prozess die Signaturen nicht selbst sondern über einen Reload des Scanners verifiziert, ist das Desaster perfekt: Die neuen, unverdaulichen Signaturen befinden sich auf der Platte, es gibt keine alte Kopie, auf die man einfach zurückspringen könnte (es sei denn, man macht selbst Backups) und ClamAV stellt die Arbeit ein. Aber nicht nur ClamAV selbst, sondern auch alle Produkte, die gegen die alten Libraries gelinkt sind.

Und dann knallt es natürlich. Und wie. Um mal zwei typische Szenarien zu nennen:

1. Wenn man amavisd-new benutzt und dort den dämonisierten Scanner des ClamAV-Projekts mit Namen „clamd”, dann wird amavisd-new nach dem finalen Signaturupdate jede einzelne Mail mit einem temporären Fehler abweisen. Erste Berichte sprechen von „deliverability rates”, die plötzlich um drei bis fünf Prozent gesunken sind - und das, obwohl mir auf Anhieb kein größerer ISP einfällt, der auf seinen Gateways clamav einsetzt.
2. Im Bereich der HTTP-Proxy-Filter gibt es ja z.B. HAVP oder DansGuardian. Beide kann bzw. muß man gegen die „libclamav” linken - und ist die zu alt, dann stellen auch diese beiden Programme ihren Dienst ein.

Der Donnerstag/Freitag (je nach Zeitzone) dürfte für einige Leute wirklich interessant geworden sein. Wollen wir nur hoffen, daß sie an diesen Tagen keine sonstigen Notfälle hatten Und man muß die Entwickler auch für ihr Timing bewundern: Die meisten Leute in Europa dürften erst am Freitag mitbekommen haben, daß ihre Mailserver stehen. Das heißt nicht nur, daß der mögliche geschäftliche Schaden minimiert wurde (betrifft ja nur einen WOchentag, und man hat das ganze Wochenende Zeit, das zu fixen), sondern auch, daß sie damit genau die Leute verärgert haben, die in letzter Instanz bestimmen, welche Virenscanner eine Organisation einsetzt (Reminder hin, Reminder her, wenigstens auf der Seite, die ein veralteter ClamAV immer zur Informationssuche empfiehlt, hätte man ja ganz oben in roter Farbe eine Warnung einfügen können, wenn man sich schon darauf beruft, seit sechs Monaten zu informieren!).

Eigentlich wollte ich in obigem Absatz jetzt noch „Man kann sich auch eine Handgranate nehmen, den Stift ziehen und sich das Ding in die Hose schieben. Hat die gleiche Auswirkung wie die Killersignatur: Man tritt mit eine Knall ab!” schreiben. Das wäre dann nicht nur ein für mich ganz und gar typischer Vergleich gewesen, sondern hätte auch die typischen Stimmen (äh, „Stimmung”) wiedergegeben, die ich im Laufe des Tages mitbekommen habe. Da meint z.B. Alexander Wirt, einer der fähigsten Linux-Menschen, die ich kenne:



Oder beispielsweise Marc Haber (der als exim4-Maintainer einen verdammt guten Job gemacht hat):



Viele andere haben dann auch - korrekt - argumentiert, daß auf vielen älteren Distributionen neuere ClamAV-Pakete nichtmal kompilieren (bzw. noch schlimmer, daß nichtmal ./configure durchläuft). Und im Prinzip haben sie damit auch recht. Aber so ein kleines bißchen muß man sich die Entwickler dann doch mal anhören. Da schreibt Edwin Török zum Beispiel:



Und man sagt eben immer wieder - und viele Leute stimmen da zu - daß man ja wirklich schon vor sechs Monaten informiert hat. Wer also keinen Ärger hätte haben wollen, der hätte einfach am 14. den freshclam-Dämon stoppen können. Ebenso ist es richtig, daß alle alten Versionen echte Bandbreitenschweine waren - auf der clamav-mirrors-Mailingliste gab es mehr als nur einmal echt ANGEPISSTE Mirror-Betreiber, die das Pech hatten, einmal ein Signatur-Update verpasst zu haben, und deren Mirror-Server dann stupide von alten freshclam-Versionen beharkt wurden.

Man kann aus der ganzen Geschichte Lehren ziehen: Wenn man OSS-Prjekte entwickelt, die für ihr korrektes Funktionieren darauf angeweisen sind, sich regelmäßg Code nachzuladen, dann sollte man sich schon bei der Entwicklung dieser Update-Mechanismen darüber Gedanken machen, wie man solche Szenarien abdeckt. Das kann man ganz einfach machen und eine MOTD in einen DNS-TXT-RR verpacken (damit habe ich jetzt wieder etliche Leser abgehängt, oder?), die dann bei Bedarf in den Logs erscheint, kombiniert mit einer Versionierung der Update-Schemata, so daß man auch alte Clients noch unterstützen kann (für die muß es ja dann keine neuen Signaturen mehr geben). Ebenso dürfen solche Schnitzer wie die fehlende Ankündigung der EOL auf der FAQ-Seite einfach nicht passieren. Aber auch Joe Sysadmin sollte sein Fett weg kriegen: Wenn man für ein System verantwortlich ist und weiß, daß es da Software gibt, die sich häufig ändert, dann muß man eben in den sauren Apfel beißen und die Ankündigungs-Mailinglisten dieser Projekte abonnieren.

Ich selbst habe zu dem Thema keine ausgeprägte Meinung - bei mir lief überall mindestens die 0.95.3, ich war also nicht betroffen, und ich kann beide Seiten verstehen. Gefreut habe ich mich aber über das ganze Chaos schon etwas. Da macht das Aufstehen doch gleich viel mehr Spaß (ich schätze, irgendwas ist schon dran gewesen an der Eingangs erwähnten Behauptung - oder?)!

Und das nächste Mal werde ich wohl am 5. Mai mit einem Grinsen erwachen. Nur wird es dann bei denen, die Probleme bekommen, ungleich schwieriger sein, selbige zu debuggen. In diesem Sinne - schönen Sonntag noch.