Skip to content

Format des Date:-Headers in E-Mails

Aufgrund einer bei mir eingegangenen Anfrage habe ich mich heute mal mit dem korrekten Format eines Date:-Headers in einer E-Mail befasst.

Ein Leser meiner Homepage schilderte mir das Problem, das automatisch generierte E-Mails aus seiner Webanwendung bei ihm im Posteingang von GMX (Webinterface) immer mit dem Datum "01.01.1970" angezeigt würden, in seinem Mailclient (Outlook) aber korrekt. Das Datum (die "Epoche") roch natürlich nach fehlendem oder nicht standardkonformen Date:-Header … Nach Überlassung eines Beispiels konnte ich sehen, daß die Anwendung den Header nach dem Muster Wed, 29 Sep 10 22:45:24 generiert. Meine erste Vermutung, daß das Jahr vierstellig angegeben werden müsse, erwies sich als falsch … aber die zweite, nämlich daßdie Angabe der Zeitzone fehlt, als goldrichtig.

Der letzte STD 10, RFC 822, sieht die Angabe einer Zeitzone nämlich ebenso wie seine Nachfolger, RFC 2822 und der momentan auf dem Standard Track befindliche RFC 5322 (der künftige Standard) als zwingend vor; eine Datumsangabe ohne diese ist somit nicht nur uneindeutig, sondern auch syntaktisch fehlerhaft. Test-E-Mails an GMX bestätigten dann auch, daß im Posteingang der Weboberfläche (nur) die Mails mit fehlender Zeitzone fälschlisch auf den 1.1.1970 datiert wurden. Interessanterweise wurde das Datum aber in der Einzelansicht der E-Mails - genau wie auch in meinem Mailclient - korrekt (in der - hier ja auch zutreffenden - lokalen Zeitzone) angezeigt.

Die Anwendung sollte dementsprechend nachgebessert werden, um undefinierte Ergebnisse zu vermeiden.

Update meines HTC Desire

Ich hatte bereits im August von einem größeren Update meines Smartphones berichtet; mittlerweile gab es ein weiteres "over the air"-Update (Build 2.10.405.2), und sogar mir sind trotz meines ständigen Zeitmangels, der dazu führt, daß ich derzeit wenig an meinen Gadgets herumspiele, ein paar Änderungen aufgefallen. :-)

Zunächst einmal gibt es ein paar neue Apps, die serienmäßig mitgeliefert werden; gestolpert bin ich zunächst über die Taschenlampe, die tatsächlich eine Taschenlampe im Display anzeigt und beim Antippen des Einschaltknopfes dort drei Helligkeitsstufen zur Anzeige bringt - und das Blitzlich der eingebauten Kamera entsprechend in drei Stufen im Dauerbetrieb zum Leuchten verwendet. :-O Lustig, aber sicherlich im Falle eines Falles auch praktisch. Danach ist mir der WLAN-Hotspot aufgefallen; der soll es lt. Beschreibung ermöglichen, daß das Telefon als WLAN-Accesspoint werkelt und zugleich per UMTS eine Datenverbindung herstellt, so daß man auf diese Weise einen Laptop oder anderen Rechner drahtlos ins Netz bringen kann. Klingt auch nett - ausprobiert habe ich es aber noch nicht. Außerdem haben sich auch bei den Einstellungen einige Änderungen ergeben; dazu zählt der Menüpunkt "Geräte-Administratoren" unter dem Punkt "Sicherheit". Dort werden Sicherheitsrichtlinien, die bspw. per Exchange Active Sync (EAS) durch den entfernten Server aufgezwungen werden, dargestellt und können - um den Preis der Löschung des entsprechenden EAS-Kontos - entfernt werden. Außerdem kann die Display-Sperre nunmehr - ggf. im Rahmen der Vorgaben einer Sicherheitsrichtlinie - zwischen "Keine", "Sperrmuster", "PIN" und "Passwort" gewählt werden und - meiner Erinnerung nach auch neu - ein Zeitraum für die Telefonsperre festgelegt werden. Dass Anwendungen jetzt auch auf der SD-Karte installiert werden können, war mir hingegen nicht neu.

"Update meines HTC Desire" vollständig lesen

Twitter, OAuth und Serendipity

Twitter verlangt jetzt für die Anmeldung zwingend OAuth.

Man muß nicht zwingend wissen, was das heißt oder bedeutet oder gar, wie das funktioniert. Aber wenn man weiter Twitter-Dienste nutzen will, bspw. das Serendipity-Twitter-Plugin, dann muß man sie auf OAuth umstellen.

Für das Serendipity-Microblogging-Plugin bedeutet das:

  • Man installiere (oder update auf) die neueste Version.
  • Man "verwalte" das Plugin und klicke dort auf den - bei mir gar nicht angezeigten und daher unsichtbaren … - Button zur Registrierung als Twitter-Application und gebe bei Twitter die notwendigen Daten ein.
  • Das dann generierte Key- und Secret-Paar gebe man im Serendipity-Plugin ein.
  • Danach klicke man wiederum auf den erscheinenden (bei mir erneut nicht sichtbaren …) Button des Serendipity-Plugins und bestätige, daß dieses auf Twitter zugreifen darf.

Fertig. Jetzt sollte alles wieder funktionieren. :-)

Strato und DHCP

Unschön, wenn man am Samstag gerade auf dem Weg zu einem Usertreffen ist und im Auto eine SMS vom Monitoring-System bekommt, das sich ein Server gerade aus dem weltweiten Netz verabschiedet hat. Vor Ort bestand nach der Begrüßung - und dem Aushändigen von WLAN-Credentials - dann die Möglichkeit zu einem kurzen Blick: das System ist wirklich (ganz) weg, die Remote-Konsole mag offenbar auch nicht, ein Reboot über das Webinterface zeitigt auch keine Reaktion, weder normal noch ins Rettungssystem. Also frischauf eine Supportanfrage gestartet, und dann: abwarten. (Die automatische Bestätigung läßt Gutes erwarten: in der Regel antworte man binnen 24 Stunden - vermutlich aber wohl nicht am Wochenende, oder so.)

Ein paar Stunden später hat sich noch nichts getan, also ein erneuter Blick auf die Angelegenheit. Diesmal will die Remote-Konsole mitspielen, und, oh Wunder: die Maschine läuft problemlos, sie hat auch eine Uptime seit dem letzten Kernelupdate (also kein Reboot), nur eines hat sie nicht - Netz. Kein Wunder mit einer IP aus dem local link-Bereich … Die sich aufdrängende Ahnung wird dann schnell Gewissheit: der Anbieter konfiguriert seine Server-Images alle mit einem dhcpcd, der regelmäßig per DHCP IP-Adresse und Routen aktualisiert, mutmaßlich, um Änderungen in der internen Struktur zu vereinfachen. Dumm nur, wenn sich der DHCP-Server weghängt … dann kommt nämlich per DHCP nichts mehr nach, das Lease läuft ab, und das war’s dann mit dem Netz.

Glücklicherweise läßt sich dieses Problem ja recht einfach beheben, auch dann, wenn man eigentlich von Routing (erst recht unter Linux!) keine Ahnung hat; wofür gibt es Google? Die "korrekte" IP läßt sich aus dem Logfile heraussuchen bzw. sollte bekannt sein (nehmen wir mal "85.214.50.55" an), das Gateway auch (im Logfile findet sich dann bspw. etwas wie "eth0: removing default route via 85.214.50.1 metric 0"), und dann machen wir folgendes:

ifconfig eth0 down
ifconfig eth0 85.214.50.55 netmask 255.255.255.255 up
route add -host 85.214.50.1 eth0
route add default gw 85.214.50.1

Voilà! Das Netz ist wieder da. (IP-Adressen passend ersetzen!)

Mal sehen, ob sich der Support irgendwann meldet oder man gar wieder auf DHCP antworten mag … (Ich hätte jetzt gedacht, solche Systeme hat man im Monitoring, aber gut. Immerhin hat das - kostenlose - Monitoring-Tool des Serveranbieters schon knapp 30 Minuten nach meinem eigenen Monitoring den Server"ausfall" erkannt und gemeldet.)

tweetbackcheck