Althaus blogt!

Da ich es immer vergesse, hier als Eigennotiz:

> prompt off
> mdelete /path/to/files/*.ext
> prompt on

Löscht alle passende Dateien ohne Nachfrage.

Das neuste Gerichtsurteil, was meilenweit von der Realität entfernt ist:

Wie das Landgericht Hamburg bereits im Juli des letzten Jahres verkündete, sind per E-Mail verschickte Abmahnungen grundsätzlich legitim. Das Gericht ignoriert damit berechtigte Bedenken bezüglich der Sicherheit der Zustellung per E-Mail und wälzt diese auf den Empfänger ab.

Quelle: Computerbase.de

Bitte was? Dachschaden oder wie? Sehr schön ist ja die Passage

Diese Email schickte er gleichzeitig per “Bcc”-Adressierung an seinen Kanzlei-Kollegen Rechtsanwalt XXXX, der den Zugang der Email eidesstattlich versichert.

Eh… Kopf -> Tisch!

Da spielen so viele Faktoren eine Rolle, dass ich mir nur die Haare raufen kann. Wahrscheinlich verschickt der liebe Abmahnanwalt die Mail noch via Outlook, damit sie sich ja nicht an irgendwelche Standards hält und schon ist sie futsch, sobald der Mailserver etwas rigider konfiguriert ist.

Seit ein paar Wochen (?) hat sich in meinen selbstgehosteten Mailboxen das Spamaufkommen rapide gesteigert und zwar dummerweise durch meinen eigenen Mailserver. Abgesehen von den aktuellen Weihnachtsspammails bekomme ich eine Reihe von Mails mit meinen eigenen Adressen im Absender. Dämlicher geht’s eigentlich nicht, aber es hat den nachteiligen Effekt, dass die Mails erst gar nicht durchkommen, sondern vorher ungültig (BAD_HEADER etc) aussortiert werden. Da ich selbst der vermeintliche Absender bin, schickt mir mein Server aber eine Nachricht (“nondelivery report”), dass “meine” Email nicht zu gestellt werden konnte.

Da das tierisch nervt, habe ich meinen Server nun mittels der so genannten “Sender Policy Framework“-Technik (kurz SPF) erweitert. SPF wird zwar relativ kritisch betrachtet, aber in meinem Fall stellt die Kritik kein Problem dar, da ich ja mein eigener Anbieter bin. Zu beachte ist, dass SPF eigentlich nicht gegen Spam, sondern gegen Adressfälschung gedacht ist.

Die Idee bei SPF ist, dass der Server bei einer eingehenden Email wie mail@example.org den Mailserver example.org fragt, ob die IP des einliefernden Mailservers dazu überhaupt authorisiert ist. Dazu wird ein entsprechender DNS-Eintrag überprüft. Wenn die IP ok ist (oder keine SPF-Infos vorhanden sind), wird die Email normal weiter verarbeitet. Liegt ein Missbrauch vor, wird die Email abgewiesen. Auch diverse Emailanbieter wie z.B. GMX setzen auf SPF. Ob dein Mailanbieter auf SPF setzt, kannst du überprüfen, indem du den TXT-Record der Maildomain abfragst.

Den SPF-Eintrag für meine Domains hatte ich schon vor einer Weile angelegt, nun musste ich meinen eigenen Mailserver (Postfix) noch die Kontrolle beibringen. Praktischerweise gibt es da bereits ein passendes Debianpaket, was ich einfach mit ein paar Abhängigkeiten via

installieren konnte. Dann noch schnell Postfix passend konfigurieren. Eine fluxe Anleitung liefert HowtoForge. Zu beachten ist, dass man tunlichst auf den genauen Pfad für die policy in der master.cf achten sollte. Da ich keine Ahnung hatte, wo das Skript gelandet war, hab ich auch gleich apt-file zum Suchen installiert.

Bei meinem Debian sieht das nun so aus:

Nachdem ich mein Pfadproblem gelöst hatte, ging es auch gleich los. Nach kurzer Zeit waren die ersten Erfolge im Log zu finden:

mail.log:
Jun 13 18:28:41 server postfix/policy-spf[8620]: : SPF fail (Mechanism ‘-all’ matched): Envelope-from: awotwiackart@warhammerportal.de.
Jun 13 18:28:41 server postfix/policy-spf[8620]: handler sender_policy_framework: is decisive..
Jun 13 18:28:41 server postfix/policy-spf[8620]: : Policy action=550 Please see http://www.openspf.org/Why?…

Take this evil spam scumback!

Auch wenn es für die Allgemeinheit nicht so viel bringt… mein persönlicher Frieden ist erstmal wieder gesichert. Immerhin wurden in den letzten vier Stunden schon 71 Emails abgewiesen.

Im Laufe der nächsten Monate, könnte etwas wirklich Unerwartetes geschehen. Während der IE8 im März den RTM-Status erreicht, IE7 seit gefühlten Ewigkeiten sogar über Windows-Autoupdate vertrieben wird, ist sein Urahn die Version 6 leider Gottes noch weiter verbreitet als es jedem Webdesigner lieb ist. Während im deutschen Raum sich neuere Versionen oder alternative Browser schon stark verbreitet haben, sieht es in anderen Ländern recht schlimm aus:

Bei T³ gibt es den gleichen Inhalt mit zwei verschiedenen Domains: Eine .de-Domain, die primär von Deutschen, Österreichern und Schweizern besucht wird und eine .net-Domain, die primär von Franzosen, Belgiern und den restlichen internationalen Besuchern genutzt wird.

Zum Vergleich:

• .net – Auf einen IE6 Nutzer kommen 1,5 IE7 Nutzer und zwei FF-Nutzer
• .de – Auf einen IE6 Nutzer kommen 1,5 IE7 Nutzer und vier FF-Nutzer

Klingt nicht viel, aber wenn man 20% mit 40% vergleicht, klingt das schon ziemlich anders.

Dass der IE6 ein Dorn im Auge jedes Webdesigners ist, ist allgemein bekannt.  Bei seinem Alter ist das auch kein Wunder… er ist z.B. älter als Windows XP, Google AdSense oder 24 (die inzw. bei der 7. Staffel sind). Mangelnde Unterstützung für aktuelle Standards oder einfaches wie transparente PNGs machen Anpassungen für Webseiten zu Odysseen und eine Verschwendung von Zeit, die produktiver genutzt werden könnte.

Nun hat die norwegische Seite FINN.no damit begonnen, ihren Besucher, die den IE6 nutzen, einen Hinweis zu zeigen, dass sie doch bitte ein Upgrade oder einen Wechsel durchführen sollen. Gleichzeigt rufen sie andere Webseiten auf, es ihnen gleich zu tun. Was geschieht mit so einer Aktion natürlich? Sie breitet sich wie ein Lauffeuer im Netz aus:

Links:

• http://iedeathmarch.org/
• http://ie6.forteller.net/
• http://www.vincenthasselgard.no/2009/02/19/give-ie6-users-the-message-to-upgrade-or-change/
• http://www.golem.de/0902/65405.html
• http://www.google.de/search?q=ie6+soll+sterben für 40.000 weitere Treffer

Endlich mal eine Aktion, die meines Erachtens wirklich Sinn macht. Bleibt nur zu hoffen, dass der große Knackpunkt – Firmen-PCs – auch geknackt wird.

Ich für meinen Teil werde sehen, wie ich die Aktion unterstützen kann.

Irgendwie hab ich das hier gar nicht mitbekommen.

So… nachdem sich Mitte Dezember die Festplatte meines Webservers verabschiedet hat, bin ich endlich mal dazu gekommen, Wordpress wieder aufzusetzen. Bei der Gelegenheit konnte ich gleich mal die neuste Version einspielen und bin ja vom neuen Adminbereich richtig begeistert.

Leider fehlten meine Bilderuploads im Backup, so dass diese nun fehlen… aber war ja nichts weltbewegendes dabei.

Nachdem nun der Browser aus dem Hause Google “Chrome” schon eine Weile auf dem Markt ist, wollte ich mal einen Blick in meine Serverlogs werfen, um zu sehen, wie verbreitet Chrome eigentlich ist. Doch als was gibt sich Chrome eigentlich aus (User-Agent)?

Wen fragt man da natürlich? Google! Das Ergebnis gefunden bei Cappelmeister via Sebbis Blog lautet:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.13 (KHTML, like Gecko) Chrome/0.2.149.27 Safari/525.13

Ne ist klar! Wer sich in dem Moment gewundert hat, warum eigentlich alle Browser behaupten, sie wären Mozilla, dem wird in Sebbis Blog auch geholfen, denn er verweist auf folgenden Eintrag im WebAIM Blog:

In the beginning there was NCSA Mosaic, and Mosaic called itself NCSA_Mosaic/2.0 (Windows 3.1), and Mosaic displayed pictures along with text, and there was much rejoicing.

Unbedingt lesen: http://webaim.org/blog/user-agent-string-history/

Meinem eigentlichen Zielt bin ich aber nicht näher gekommen, da Chrome somit zwischen den anderen Mozilla/5.0-Browsern verschwindet. Da muss ich erstmal den Logparser anpassen.

Manchmal sind es ja die Kleinigkeiten die einen sehr verwirren können. So wechselte bei T³ beim Bestätigen einer Turnierabsage das Sprachinterface zur Hälfte auf Französisch und auch die entsprechenden Mails gingen nicht in Deutsch raus. Etwas Debugging später ergab sich die relativ einfache Lösung: Mit dem lang fälligen Serverupdate habe ich auch endlich PHP4 auf PHP5 aktualisiert. Da PHP5 eine ausgebaute Unterstützung für objektorientierte Programmierung erhalten hat, hat der alte Code, der die verschiedenen Sprachcontainer verwaltet nicht mehr korrekt funktioniert. Nun wurden nämlich (wie es ja auch sein sollte) die Verweise kopiert und nicht mehr die Objekte. Mit ein paar hinzugefügten “clone $object” läuft nun alles wieder rund.

Wie gesagt… die Kleinigkeiten, die einen echt verwirren können.

Um ein halbes Auge auf meinen Server zu haben, läuft das kleine Programm chkrootkit einmal am Tag über die Platte und sucht nach suspekten Dateien etc. Nun bekomm ich deswegen einmal am Tag einen Hinweis, dass die suspekte Datei “/lib/init/rw/.ramfs” vorliegt. Dummerweise ist die Datei alles andere als suspekt und gehört dahin. Nun streiten sich die zuständigen Parteien darüber, wer nun den “Fehler” gemacht hat und der Bug wird von A nach B und zurück geschoben. Als “Endnutzer” kann man da nichts machen, außer genervt sein oder selbst Hand anlegen (Danke für den Patch!).

Wie damals geschrieben, habe ich mich jeweils an den abuse-Kontakt der ISPs gewandt. Von beiden Seiten kam bis jetzt auch nach zweimaliger Kontaktaufnahme keine Reaktion. Ich werde es jetzt nochmal über den regulären Kontakt versuchen. Vielleicht laufen die abuse@domain.tld-Mailadressen ja ins Leere. Sollte auch darauf keine Reaktion kommen, werde ich wohl die Hosts komplett für meine Webserver sperren.