Wohnzimmerhostblogger

Heute morgen hat ein - sagen wir mal - Anbieter von Online-Diensten unberechtigt von unserem Geschäftskonto abgebucht.

Sowas kann mir immer schön den Tag vermiesen. So ganz überraschend kommt es natürlich nie, schließlich kommunizieren wir diese Daten recht "freizugügig" überall hin - meistens um Geld für unsere Dienstleistungen zu bekommen. Das da auch mal Missbrauch stattfindet besagt allein schon die Statistik und ist daher wohl keine Überraschung.

Dem Anbieter mache ich auch keine wirklichen Vorwürfe, wobei ich mir recht sicher bin dass er keine schriftliche Einzugsermächtigung vorliegen hat, die aber natürlich auch "leicht" zu fälschen ist (zumindest in dem Umfang, dass es einer einfachen Prüfung stand hält). Ich bin vielmehr sauer und enttäuscht von dem jenigen, der dort diesen Betrug begeht.

Die Enttäuschung ist wohl was rein menschliches: Ich verstehe nicht, wieso Menschen derartigen Betrug wagen. Das bringt doch niemanden weiter und scheitert unter Garantie. Das es in Wahrheit tagtäglich wohl tausende Male passiert ist mir bewusst und so mag ich daran eigentlich auch keinen Gedanken verschwenden - immerhin kostet mich sowas schon mehr als genug Zeit.

Und dieser letzte Umstand macht mich sauer, denn ich bekomme die Info, dass da eine merkwürdige Abbuchung war, muss den Posten prüfen, mich mit dem abbuchenden Unternehmen in Verbindung setzen, den Fall dort vortragen, ein Blacklisting des Kontos erwirken und den Betrag rückbuchen lassen (Rücklastschriften sind ja böse, das geht eigentlich auch immer ohne). Zu guter letzt der größte Posten: Ich gehe zur Polizei und mache eine Anzeige. (Das machen wir mit jedem Fall so)

Letzteres tue ich meistens mit einer Verzögerung von 2-3 Tagen. Zum einen weil ich diese Atmosphäre überhaupt nicht mag, zum anderen weil ich bis dahin immer gerne an das Gute im Menschen glaube: Vielleicht kommt der Schuldige in der Zeit zur Besinnung, sieht ein dass er was dummes gemacht hat, und schreibt einfach mal eine entschuldigende E-Mail - einen Fehltritt hat doch jeder mal gut.

Ist bisher traurigerweise noch nie passiert und so bin ich mir auch dieses mal sehr sicher, dass ich meinen Termin am Donnerstag morgen wahrnehmen werde.

Am Wochenende war ich neben einem geschäftlichen Termin noch bei einem sehr guten Freund zu Besuch, der "zufällig in der Gegend" wohnt. Da er ähnlich wie ich eingestellt ist, waren unsere Gesprächsthemen auch eher technisch-lastig.

In einer kurzen Gesprächspause schaute ich seine Lebensgefährtin an und meinte:

So! Wir müssen nun ein Synonym für PHP finden, dass Dir auch mal etwas zusagt!

worauf hin sie mir nach einer kurzen Denkpause entgegnete:

Pinke Hochhackige Pömps

Sehr geil! :D 

Wir haben irgendwann dieses Jahr angefangen unsere Dokumente wie Angebote und Verträge im PDF/A1-Format zu generieren, abzuspeichern und zu versenden.

Gerade eben rief mich unsere Ansprechpartnerin bei einem unserer Distributoren an und meinte sie hätte Probleme den Lieferschein für eine Bestellung eines unserer Kunden zu öffnen. Auch die Logistik hätte es nicht geschafft das Dokument zu öffnen.

Ich habe daraufhin das Dokument noch einmal als "normale" PDF generiert, rübergemailt und schon hat es funktioniert. Merkwürdig, ganz naiv gesagt hätte ich es eher anders herum erwartet, da PDF/A ja auf den ganzen "fancy stuff" verzichtet...

Twitter wäre hierfür wohl die bessere Applikation, doch habe ich nur diesen Blog hier.
Auf den WorldHostingDays wurde ich just sehr freundlich begrüßt - in etwa mit den Worten:

Endlich mal jemand, der deutsch spricht!

Na dann...n.

Wir haben PHP heute morgen ein kleines Update spendiert und bieten ab sofort die Versionen 5.2.16 und 5.3.4 zusätzlich an.

Neukunden bekommen ab sofort die Version 5.2.16 auf ihr Webhosting geschaltet, Bestandskunden bleiben vorerst unangetastet können aber jederzeit ein Update per E-Mail erfragen.

Okay, das ging schneller als erwartet:

Unser Mailserver kennt nun das Sender Rewriting Scheme (SRS). Theoretisch gilt das für beide Richtungen, also das Umschreiben des Absenders wenn eine E-Mail weitergeleitet wird und das Umschreiben des Empfängers, wenn eine E-Mail an unsere SRS-Domain empfangen wird. Produktiv verfügbar ist aber vorerst nur zweiterer Dienst - der war einfach leichter zu testen und fällt auch eigentlich gar nicht auf, wenn wir den einfach dazu schalten.

Unsinnig eigentlich, denn ohne das shared secret aus unserem E-Mail-System ist es vermutlich niemandem möglich selbst E-Mail-Adressen zu bauen, die von unserem System akzeptiert werden. Vielleicht wollte da jemand einfach nur ein Kreuzchen auf der ToDo-Liste machen.

Dabei ist die andere Richtung viel interessanter und spannender. Wie ich letzte Woche bereits schrieb haben wir für die SRS-Einführung eigenes einen Patch für das von uns eingesetzte Postfix entwickelt. Wie schon dort angedeutet fehlten dementsprechend eigentlich nur noch zwei Dictionaries (bzw. Lookup-Tables). Eigentlich recht trivial, im Zweifel hätte es gereicht zwei Pipes in Richtung libsrs2 zu legen (wenn wir es denn einsetzen würden), aber das wäre nicht sehr "intelligent".

Der bereits erwähnte "Weg zurück", also das Umschreiben des Empfängers einer E-Mail an unsere SRS-Domain, funktioniert genau so. Darf man machen, da der erste Check hier ein Check der Domain ist und die ausschließlich für SRS verwendet wird. Der vorhergehende Schritt, das Umschreiben des Absenders gestalten wir jedoch etwas differenzierter:

1. Es werden keine Absender umgeschrieben, die von Domains kommen die ohnehin über unseren Mailserver laufen
2. Es werden nur Absender umgeschrieben, die von Domains mit aktivem SPF-Schutz kommen

Kleine persönliche Anmerkung: SRS hat erst einmal nichts mit OpenSRS am Hut. Das sind zwei unterschiedliche Dinge, letztere höre ich mir morgen vermutlich auf den WorldHostingDays im Europa-Park in Rust an

Das Sender Policy Framework (SPF) ist nun schon fast altes Zeug. Immer mehr Domains verfügen über einen solchen "Schutz" und dementsprechend öfter fallen nun E-Mails auf, die "klassisch" weitergeleitet werden sollten - sei es eine E-Mail die von GMX kommt, ursprünglich an eine bei uns gehostete Domain ging und wieder zurück an GMX geleitet wird - und es nicht funktioniert. Die Problematik ist zwar nahezu überall dokumentiert, aber mitunter doch recht schwer zu kommunizieren.

Das Problem ist bei uns eigentlich auch schon ewig bekannt: Seit 2006 setzen wir auf nahezu allen Domains SPF ein und auch der Lösungsansatz des "Sender Rewriting Scheme" (SRS) war uns ein Begriff. Nur mangelt es bis heute irgendwie an einer passenden Lösung für Postfix (so wie es bei uns zum Einsatz kommt).

Zwar gibt es hier und da ein paar Ansätze oder auch Aussagen a la "Wir haben es geschafft", aber konkrete Angaben bzw. Dokumentation oder etwas öffentlich verfügbares für den Produktiv-Einsatz fehlt gänzlich. In ein paar Foren findet man auch oft die Aussage SRS wäre ein Fall für einen Content-Filter. Letzteres ist sicherlich auch ein einfacher und schneller Weg das "Problem" anzugehen, doch scheint mir der Overhead hier recht enorm zu sein. Etwas schlankeres wäre mir doch lieber.

Grund genug sich einmal den smtp-Client von Postfix anzuschauen und mal herauszufinden, was das Ding in die Richtung alles kann. Grundsätzlich bin ich bei Postfix gewöhnt alles irgendwie über Dictionaries umzuschreiben und so Daten nahezu endlos umzubiegen. Ein gutes Beispiel wäre hier sicherlich die Struktur unserer Relay-Funktionalität, die sich auch auf einzelne E-Mail-Adressen beschränken lässt und sich Domains so im gemischten Betrieb verwalten lassen. Oder natürlich auch die Anbindung von Zarafa-Mailboxen im Multi-Tenancy- sowie gemischten Betrieb mit normalen POP3/IMAP-Mailboxen - aber ich schweife ab.

Der SMTP-Client von Postfix kennt mit den smtp_generic_maps tatsächlich auch ein Dictionary um den Absender einer E-Mail umzuschreiben, also eigentlich wäre hier genau der richtige Punkt um mit einer SRS-Implementation anzusetzen. Ein einziges Problem gibt es dann allerdings:
Die smtp_generic_maps kommen sowohl für den Absender wie auch den Empfänger zum Einsatz und man kann technisch bedingt nicht unterscheiden, wonach genau gerade gesucht wird.

Die Lösung des Problems ist daher ganz einfach: Die smtp_generic_maps auseinander friemeln. Genau das tut ein Postfix-Patch (für 2.8 Patchlevel 1) von uns, den ich just in unser Build-System geschickt habe: Neben den smtp_generic_maps führt der Patch die smtp_sender_maps ein, die nur für MAIL FROM:-Einträge konsultiert werden.

Fehlt eigentlich nur noch das passende Dictionary, dass die Verarbeitung bzw. Konvertierung der Absender-Adressen vornimmt. Für den Moment behalte ich näheres dazu aber für mich bzw. überlasse das gerne der Community, zumal wir da noch nichts produktives haben - unsere SRS-Bibliothek hat noch Probleme mit SRS1 nach SRS1. Mal davon abgesehen, dass der Weg zurück noch gar nicht gebaut ist

Wir haben in der letzten Tagen eine Zarafa-Instanz bei uns aufgesetzt. Nun haben wir ja unsere eigene Hosting-Plattform und die richtet sich nicht gerade nach den offiziell von Zarafa unterstützten Betriebssystemen - nun ist die Frage, geht man den von Zarafa vorgeschriebenen Weg oder verbiegt man der Giraffe ein wenig den Hals?

Ich hatte mich in dieser Sache für den zweiten Weg entschieden. Auf Dauer schien es mir der bessere Weg zu sein, zumindest verkleinert es die Zahl der "Fremdkörper" die sich bei uns auf den Servern befinden. Aus dieser Entscheidung resultierten jedoch 3 wesentliche Probleme:

1. Zarafa ist auf eine Webserver-Umgebung mit mod_php ausgelegt
2. Die Webaccess-Oberfläche benötigt die Zarafa-eigene MAPI-Erweiterung für PHP
3. Z-Push ebenfalls auf mod_php ausgelegt

Um das Feld von hinten aufzuräumen: Die einzige Sache, die Z-Push an mod_php bindet, ist ein Aufruf der Funktion apache_request_headers(). Das Problem ist schon im Jahr 2007 im Z-Push-Forum diskutiert worden, hat es aber wohl nie in die offizielle Distribution geschafft - warum auch immer. Neben dem Patch, der in besagtem Forum zu finden ist, haben wir auch einen eigenen Patch geschrieben.

Punkt #1 ist im Vergleich zu #2 auch weniger kritisch. Es scheitert hier im wesentlichen daran, dass die .htaccess-Datei in /usr/share/zarafa-webaccess einfach so php_flag-Direktiven verwendet, die den Apachen dazu veranlassen einen 500er zu werden, wenn mod_php nicht vorhanden ist. Ich finde ja, dass es grundsätzlich guter Stil ist <IfModule>-Direktiven zu verwenden, auch oder gerade wenn man ein bestimmtes Modul voraussetzt.
Die Einstellungen, die man in der php.ini anpassen sollte sind:

register_globals = Off

magic_quotes_gpc = Off
magic_quotes_runtime = Off

post_max_size = 32M
upload_max_filesize = 30M

short_open_tag = On

log_errors = On
error_log = error.log

... das meiste war bei uns ohnehin so voreingestellt. Weiter sollte das Verzeichnis /var/lib/zarafa-webaccess/tmp auch noch für den Benutzer unter dem der FastCGI-Prozess ausgeführt wird schreibbar sein.

Wir bieten seit heute morgen eine gewisse Unterstützung für die Autokonfiguration von Mozilla Thunderbird.

So ganz glücklich bin ich mit dem Status Quo nicht, er mutet an zwei Stellen etwas dreckig an, ist aber definitiv schöner als der Zustand vorher. Zum einen haben wir uns auf den E-Mail-Domains die Subdomain "autoconfig.%DOMAIN" genommen bzw. nehmen müssen.
Eine Delegation der Einstellungen über DNS wäre da wesentlich schöner gewesen und das Thunderbird-Projekt hat da auch schon was in der Mache - funktionieren tut es nur noch nicht

Ein weiterer Nachteil ist, dass sich bei uns der Benutzername von der E-Mail-Adresse unterscheidet oder - anders gesagt - ein Benutzer mehrere E-Mail-Adressen haben kann, die er über die selbe Mailbox abholt. Thunderbird ist sich dieses Umstand bewusst hat aber noch keine Lösung parat, die "stable" wäre. Schlussendlich müssen wir da wohl noch etwas warten - bis dahin schlagen wir als Benutzernamen "BEARBEITEN" vor - mit einem schönen "Bearbeiten"-Button daneben. Ich hoffe mal jeder ist so weise den auch zu klicken

Ich bin ein wenig hin und her gerissen... Ich habe gerade eben online den Status einer Lieferung geprüft - wegen der großen Vorfreude und so. Da fiel mir die Option "Detaillierte Empfängerinformationen anzeigen" auf:

Ich würde eigentlich davon ausgehen, dass die Postleitzahl hier als eine Art Passwort verwendet wird um den nachfolgenden Namen zu schützen. Wenn ich mir aber die URL anschaue, kann ich das nicht so ganz nachvollziehen:

http://nolp.hdl.de/nextt-online-public/set_identcodes.do?lang=de&zip=70191&idc=XXXXXXXX

Denn da steht die Postleitzahl offensichtlich auch mit drin. Man könnte nun vermutlich viel über das Für und Wider diskutieren oder auch die Frage stellen, wie wichtig oder vertraulich diese Daten sind, aber eigentlich ist es mir recht egal und ich wollte es nur mal erwähnt wissen

Ein aufmerksamer Kunde fragte eben vorsichtig per Jabebr/XMPP an:

[10:55:29] <Kunde> wenn ich im kunderinterface rumspiel, dann werden die sachen schon automatisch geändert, oder? nicht das ihr das dann alles macht
[10:58:22] <Support> *gg* Da würden wir ja verrückt werden

Man muss ihm da zu gute halten, dass ich in der Tat schon mal darüber nachgedacht habe, bestimmte Prozesse im KIF abzubilden, die dann schlussendlich nach hinten heraus nur eine E-Mail zu manuellen Bearbeitung rausschicken - um sie schneller in ein Release-fähigen Zustand zu bekommen. Doch sowas tun wir nicht.

Es wäre auch schlimm, wenn man bedenkt, dass das KIF seit dem 24.10.2008 knapp 33.986 asyncrone Jobs ausgeführt hat, also solche Jobs die z.B. die Webserver-Konfiguration verändern und nicht in Echtzeit ablaufen. Umgerechnet sind das zwar immer noch nur knapp 1,5 Jobs pro Stunde, aber wir haben hier weiß Gott anderes zu tun