Technik

Gestern morgen meldete sich ein Kunde bei mir und meinte, dass eine Weiterleitung nicht funktioniert. Sicherlich, diese Aussage war nicht ganz richtig, denn die Weiterleitung funktioniert nur teilweise nicht. Und eben dieses Teilweise hängt sehr stark vom Absender der E-Mail ab.

Nach ein wenig Recherche habe ich nun SPF in Verdacht schuld an der ganzen Sache zu sein, denn es scheint, dass es immer dann schief geht, sobal die Mail an die Weiterleitung von einer Domain kommt die auch einen SPF-Datensatz beherbergt.

Nachgeprüft habe ich es noch nicht, aber ich denke, dass mein Mailserver, sofern er eine Mail weiterleitet ein "MAIL FROM: absender@domain.tld" sendet und - sofern der empfangende Mailserver SPF-Checks macht - die Mail zurückweist, da mein Server z.B. keine Absender @gmx.de versenden darf.

Bleiben nun zwei Fragen: Wer sollte vorrang haben - Schutz gegen Spam und Absenderfäschung (SPF) oder die Weiterleitungen? Ich bin da ja eher für ersteres zumal ich für zweiteres schon einen Plan aushäcke, der sich auch just auf die Zweite Frage bezieht: Wie lösen wir das Problem?

Wäre es nicht sinnvoll bzw. in Anbetracht der Tatsachen angemessen beim Weiterleiten einer E-Mail ein "MAIL FROM: alias@weiterleitung.tld" (also die Adresse der Weiterleitung) zu senden anstatt des ursprünglichen "MAIL FROM: absender@domain.tld". Solange kein Bounce entsteht, funktioniert das eigentlich recht gut und ist auch Nachvollziehbar. Aber was, wenn doch ein Bounce entsteht? Wäre dann sowas wie "MAIL FROM: postmaster@anderedomain.tld" sinnvoll um die Bounces abzufangen?

Ehrlich gesagt: Die perfekte Lösung scheint es nicht zu geben oder ich habe sie noch nicht gefunden. Ich frage mich, ob da jemand dran gedacht hat, als SPF geschaffen worden ist.

Und was erzähl ich nun dem Kunden?
Eine Weiterleitung, die nur partiell funktioniert, ist wohl nicht gerade etwas, was man gerne im Portfolio hat...

Mit ASCII fing das Problem an, mit ISO-8859-X wurde es temporär gelöst, UTF-8 räumt vorerst mit allem auf - sofern wir nicht demnächst auf extra-terrestrisches Leben treffen, das gerne bereit ist mit uns zu kommunizieren (anstatt uns auszulöschen) und wir deren Zeichensatz auch noch unterstützen müssen.

Doch hat sich UTF-8 noch lange nicht als Standard durchgesetzt und somit gibt es schon mal gerne einen Zeichensalat - so passiert ist es mir gestern Abend - Mit MySQL. Ich sehe mich schon irgendwo ein wenig als Vorreiter in Sachen UTF-8, denn meine Webserver laufen schon lange auf diesem Zeichensatz. Meine neueren Datenbank-Server tun dies ebenfalls und bisher dachte ich, würde es da mit der Migration keine Probleme geben, dank individueller Festlegung der Kodierung für jede Tabelle. Doch Trugschluss!

Es kommt nicht nur auf den Zeichensatz der Tabelle an, nein, bei MySQL gibt es an anderer Stelle noch viele weitere Punkte, bei denen man auf die richtigen Angaben achten muss. So werden die Daten z.B. für die Kommunikation mit dem Client nochmal extra kodiert. Sollte man nun also von einem MySQL-Server der latin1 sprach auf einen der utf8 spricht wechseln, sollte man entweder für den gesamten Datenbankserver den Zeichensatz für Client-Verbindungen auf latin1 zurücksetzen, oder dies pro Verbindung tun:

SET character_set_client=latin1;
SET character_set_connection=latin1;
SET character_set_results=latin1;

... so sollten auch in Zukunft "alte" Anwendungen mit der neuen Datenbank laufen, während neue Anwendungen sich gleich schon mal an UTF-8 gewöhnen können.

Nachdem ich vor viel zu langer Zeit das Logging für die Statistiken abgeschaltet hatte, läuft das Logging mit dem Update der Apache-Server nun komplett über das neue System - zwar ist das ganze noch etwas langsamer als vorher, dafür ist die Basis eine wesentlich robustere und bietet auch ein kleines Stückchen mehr Komfort. In Zukunft werde ich mich also auf die Geschwindigkeit des Logging-Vorgangs konzentrieren - die keinesfalls Auswirkung auf die Geschwindigkeit des Webservers hat.

Statistiken gehen trotzdem noch nicht, da werde ich mich in den nächsten Tagen drum kümmern.

Ich fühl mich heute morgen (ein Blick auf die Uhr sagt "mittag", aber das ist mir egal.) ein wenig in die Vergangenheit zurückgesetzt, denn ich hab es schon echt lange nicht mehr gemacht.

Die Rede ist von Sprachen sprechen, die nicht meine eigene ist. In diesem Falle werden sie sogar nur recht selten von Menschen gesprochen, dafür aber von Computern untereinander sicherlich eine Milliarde mal am Tag.

Konkret heißt das für mich: FTP, HTTP, SMTP, POP3, IMAP, XMPP, IGMP und etwas was ich nicht wirklich kann aber zu erraten versuche: SSH

Der Hintergrund der ganzen Geschichte ist ein Programm zum monitoren von Servern, das ein wenig weiter geht als einfach nur Ports zu öffnen und wieder zu schließen. So kann es sich z.B. via FTP einloggen und Verzeichnisse überprüfen oder eine Testseite via HTTP abrufen.

Hinzu kommt dann noch die Möglichkeit bei Ausfall nicht nur via SMS und E-Mail sondern auch via Jabber und per Fax (!!!) informiert zu werden

Seit gestern Abend durfte ich schon mehrere dynamische Subdomains für Kunden und auch ein paar .de- und .info*-Domains für "Neukunden" / Beta-Tester registrieren. Es hällt sich in Grenzen - soll es auch - und macht schon ein wenig Spass. Schön dabei ist, dass sich der Support hierfür durchaus stark in Grenzen hällt und unsere Tester sich eigentlich komplett selbst ihren Weg durch die neue DynDNS-Welt suchen.

An dieser Stelle möchte ich vielleicht noch einmal erwähnen, dass das Kontingent an "kostenlosen Domains" nicht aus vorregistrierten Domains besteht, sondern jeder Tester seine ganz eigene Domain a la irgendwas.de bekommt. - Hat schon mehrmals Missverständnisse gegeben

Doch was genau steckt eigentlich hinter dem System, wie funktioniert das?

Im Prinzip ist unser DynDNS-Server nur ein kleineres Frontend zur bestehenden Datenbank. Jede dort liegende Zone hat ein spezielles DynDNS-Flag bekommen, welches sie über den DynDNS-Server editierbar macht und wo dann auch beliebig viele "Unterzonen" erstellt werden können.

Aus technischen Gründen sind ca. 8 Datensätze für jede Zone automatisch vorhanden:

• Der normale A-Record für die Zone selbst
• Ein Wildcard-Record für alles unterhalb der Zone
• Zwei Records für Primary und Backup MX
• Ein Record zur Weiterleitung sofern die Zone offline ist
• Drei Einträge meiner Nameserver

Alle diese Records sind immer vorhanden und werden nur bei Bedarf entsprechend (de-)aktiviert. In der Alpha-Phase des neuen Dienstes war das noch anders, da ist sehr viel mit INSERT's und DELETE's gearbeitet worden - was mir am Tag schon mal bis zu 500 neuer Zeilen in der Datenbank beschehrt hat - zumindest wenn man nach dem Primärschlüssel geht und sowas sehe ich eigentlich überhaupt nicht gerne.

Der DynDNS-Server ist nahezu 100% kompatibel mit dem Server von DynDNS.org - nur der Servername ist ein anderer, sogar die Pfade stimmen überein - und ist via HTTP und HTTPS erreichbar. In dieser Ausbauphase sind bisher keine anderen Schnittstellen geplant.

Bei einer Update-Anfrage an den Server werden alle Informationen, abgesehen von den Anmelde-Informationen, per GET in der URL übertragen - das will die Spezifikation so, wobei wir uns erlaubt haben auch POST zuzulassen. Der Server geht dann lediglich her und überprüft die Werte (recht streng) bevor er ein internes Handle für die entsprechende Zone erzeugt und die neuen Daten übernimmt.

Fertig ist der DynDNS-Dienst.
Wobei im Hintergrund noch ein ausführliches Logging (für den Support) stattfindet, das scheint aber eher unerheblich zu sein

* Ja, .info-Domains gibts auch im Kontingent...

In Absprache mit meinem Helferlein startet mit dem heutigen Tag der "Public Beta-Test" für unseren neuen DynDNS-Dienst. Wir suchen nun nach freiwilligen Testern, die auch gerne mal bereit sind selbst nach neuen Clienten zu suchen und diese zu testen, denn gerade ich habe z.B. ein Problem Windows-Clienten zu testen.

Den Support hierfür werde ich diesmal nicht mitmachen, sondern erledigt das ausschließlich mein Helferlein, wer ihn also mal kennenlernen will sollte mitmachen!

Für Interessierte - ganz besonders auch für Nicht-Kunden - habe ich auch gleich mal ein paar .de-Domains klar gemacht, die ich zum kostenlosen Testen für ein Jahr spendiere. (Nur DynDNS, kein Hosting, kein E-Mail)

Bei Interesse kurz eine E-Mail an mich oder das Kontakt-Formular benutzen!

Merke: Alle Regeln aus einer Firewall zu löschen, deren Standard-Regel "verbieten" ist, ist dumm.
Wisse: Noch dümmer ist es, sowas von Unterwegs zu machen!

Genau das dachte ich am Dienstag im Zug, als ich "iptables -F" auf meinem Router zu Hause im Büro ausgeführt habe und sich danach nichts mehr regte...

Ich denke dieses Erlebnis war einschneidend genug um es in Zukunft seltener zu tun...

Ich habe mir in letzter Zeit angewöhnt, immer wenn ein internet Umzug auf einen anderen Webserver geplant stattfindet ca. 24h vorher die TTL der betroffenend DNS-Datensätze extrem niedrig zu setzen - in der Regel auf eine Zeitspanne von 2 bis 5 Minuten.

Auf beiden Seiten (Client und Server) mag für diesen Zeitraum wohl etwas Performance verloren gehen, doch sehe ich hier überwiegend Vorteile, denn so ist die Ausfallzeit nach Änderung der Datensätze eher minimal und alles ist perfekt

Ich denke ich werde es in Zukunft auch bei abgehenden Domain-Transfers machen, zwar nicht gerne aber was solls. Auch ein guter Abgang ist als Dienst am Kunden zu verstehen

Hiermit erkläre ich den heutigen Tag zum World-Writeable-Day!
Oder auch Tag des Satans.

Sofern ich weiß ist ersteres ganz allein auf meinem Mist gewachsen, wenn ich irre, bitte losschreien!

Ansonsten freue ich mich auf Juli nächsten Jahres, wo es für alle nochmal ein Execute-Bit gratis, quasi für umsonst, dazu gibt.

Ich sitze gerade an einem Computer auf dem kein OpenOffice installiert ist.

Schön und gut - wirklich als Standard hat sich die Software wohl auch noch nicht durchgesetzt, auch wenn sie sich offener Standards bedient.

Da mir aber ein Interessent eine .ods (OpenDocument Spreadsheet) zugemailt hat, ich wirklich neugierig auf deren Inhalt und zu faul mir einen Reader dafür zu suchen war, habe ich die Datei einfach mal von Hand "geparsed"

Ist ja bei .ods denkbar einfach - die Datei als ZIP-Datei behandeln, entpacken und die content.xml im Editor der Wahl öffnen und loslesen...

In einer Quasi-Zusammenarbeit mit dem manitu-Support hatte ich gestern eine zündende Idee für eine kleinere Erweiterung meines Rechnungssystem.

Ich weiß nicht mehr genau, wie ich darauf gekommen bin... :hmm:

Aber wenn meine Kunden Geburtstag haben, möchte ich Ihnen an diesem Tag keine Rechnung schenken. Aus dem Grund habe ich heute morgen eine kleinere Abfrage in dem Dienst der bei mir immer die Rechnungen schreibt eingefügt, so werden Rechnungen für Geburtstagskinderkunden auf frühestens den nächsten Tag vertagt. Ist das nicht toll?`

Wobei ich mich frage, ob nicht eine Auszeit von 2 Tagen ratsam wären, damit man noch Zeit hat aufzuräumen und den Rausch auszuschlafen