Technik

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...

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