Sendmail, PHP und der falsche Absender in Outlook

Bei einem größeren Kunden von mir gab es heute Abend das Problem das sich einige seiner Kunden beschwerten bei einem Newsletter immer eine falsche Absenderadresse mitgeteilt zu bekommen. So wurde oft die Default Confixx-Adresse web0@s3.teamgeist-media.de genutzt die in dem Apache vHost als sendmail_from – Direktive eingetragen war.

Nach kurzem Testen konnte ich allerdings keine Fehlkonfiguration erkennen – sendmail mailte richtig, der From-Header war richtig gesetzt und zu guter letzt kamen bei mir richtige Testmails im Posteingang an.

Der Fehler lag nach kurzer Recherche im Detail – Outlook ist einer der wenigen Mailclienten der den Mailheader-Tag Return-Path auswertet. Normalerweise wird dieser immer auf die From-Adresse gesetzt. Allerdings nicht wenn der Hostname der From-Adresse nicht der eigene Server ist!

In meinem Fall zeigt eine Subdomain eines Kunden per A-Record auf meinen Server – in der Anwendung die auf dem Server liegt wird allerdings die Hauptdomain als Absender für ausgehende Mails verwendet – weiter kein Problem bei den meisten Mailclienten – nur Outlook macht da einen Strich durch die Rechnung ;-).

Man könnte jetzt als Absenderadresse eine Adresse mit Subdomain statt Domain nutzen oder Sendmail durch SMTP ersetzen. Oder man kennt den fünften Parameter der mail() – Funktion 😉 Hier kann man nämlich Parameter direkt an /sendmail durchschleusen. Nutze ich hier -f als Parameter mit der From-Adresse als anzuhängender Wert, so wird ein Check des Hostnames übersprungen und so auch korrekt der Return-Path – Parameter gesetzt.

Das Ganze würde dann wie folgt aussehen:

 mail('euer@empfaenger.de', 'Noch ein toller Betreff', 'Text nicht vergessen', 'From: absender@adresse.de', '-fabsender@adresse.de');

Wichtig ist hier ihr hinter dem -f – Parameter kein Leerzeichen setzt, sondern direkt mit der Absender-Adresse weitermacht.

Kommt ihr damit klar und wurde euer Problem damit behoben?

Flattr this!

Smarty Locale i18n Dezimalzeichen

Vor kurzem führte ich in einem Bezahlungs-Portal die Internationalisierung ein (i18n). Ein Bestandteil war es, auch die eingesetzte Programmiersprache „einzudeutschen“ – in PHP gesprochen hieß es, das ich setlocale() einsetzen musste.

Foto: Jon Matthies (jmatthies / Flickr, CC BY 2.0)

i18n – eine Kunst für sich Foto: Jon Matthies (jmatthies / Flickr, CC BY 2.0)

i18n war schnell angepasst und eingerichtet. Vom Prinzip her einleuchtend. Doch auf einmal funktionierte die PayPal-Schnittstelle nicht mehr. Man denkt natürlich nicht unbedingt an einen Zusammenhang, wenn zwischen Zeitpunkt <Änderung> und Zeitpunkt <Fehler erkennen> ein paar Tage und viel Code liegen.

Was war geschehen? Paypal’s API erwartet bei einem Express-Checkout eine Menge von Zahlen. Meist sind das ganze Zahlen (integer) – zum Beispiel für die Anzahl Artikel. Oft hat man allerdings auch mit Dezimalzahlen (float) zu tun – und genau hier lag der Stein begraben.

Die oben angesprochene Internationalisierung greift nämlich nicht nur bei deutschen Strings oder Datums-Formaten – sondern auch bei Dezimalzahlen. Ein früheres 0.50 Euro ist jetzt ein 0,50 Euro. Und damit kommt die Paypal-API mal so gar nicht klar. Aber warum sollte sie auch?

Problem ist schnell gelöst – nach meinem setlocale(LC_ALL, 'de_DE'); wird einfach ein setlocale(LC_NUMERIC, 'C'); eingefügt – dieser Reset zu „C“ für alle Zahlenwerte führt dazu, das wieder mit einem Punkt statt Komma die Nachkommastellen (haha..) abgetrennt werden.

Flattr this!

PHP und das Caching via HTTP-Header-ETag

Normalerweise wird das Caching in PHP serverseitig vollautomatisch bestimmt. Das kann gut funktionieren, wir können dies aber noch verbessern indem wir eine extra Funktion in unsere Webprogramme einbauen um noch viel aktiver das Caching via HTTP-Header klientseitig im Browser zu beeinflussen.

Ich könnte euch jetzt direkt viel zu diesen Caching-Controls und dem so genannten eTag (dazu später mehr) erzählen. Aber zunächst möchte ich euch diese kurze PHP-Funktion an den Kopf werfen: Weiterlesen →

Flattr this!