E-Mail und Umlaute bringen mich noch ins Grab!

Galanos

Galanos

Aktives Mitglied
Thread Starter
Dabei seit
19.12.2005
Beiträge
625
Reaktionspunkte
23
Hallo zusammen,

ich bin mal wieder verzweifelt und braeuchte Hilfe. Habe mich bereits an alle Bekannten gewendet, die wenigstens ein bisschen Ahnung davon haben, aber keiner kann mir helfen.

Folgendes:
Mein Shop verschickt nach Bestellung eine Bestaetigungs-E-Mail mit angehaengtem PDF. Auf (allen getesteten) Mac-Systemen kommt die E-Mail in Apple Mail mit allen Sonderzeichen an, in Webmail-Applikationen (1und1) in Safari auch. Hatte lange gebraucht, bis ich mein Script so weit gebracht hatte.

Jedoch erzaehlen mir jetzt schon 2 Verwandte mit Windows-PCs, dass Umlaute in ihren Bestaetigungs-E-Mails als Hieroglypen ankommen ("Bitte überweisen Sie …"). Der eine mit Outlook 10, der andere mit IE7 im GMX-Portal. Und ich habe keine Ahnung, woran das liegt.

Der Header der E-Mail enthaelt folgende, fuer die Zeichenkodierung relevante, Eintraege (aus einer eingehenden Mail kopiert, nicht aus dem Script):
Code: 
Content-Type: multipart/mixed; boundary="-----=8494f9cc7389f5dc37f921f47e2cd8fd"; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
"multipart/mixed" wegen angehaengtem PDF. "UTF-8" verwende ich global auf der Site, von der Datenbank ueber die Scripts bis zur HTML-Ausgabe.
Die Boundary trennt spaeter Text von PDF.
Code: 
-------=8494f9cc7389f5dc37f921f47e2cd8fd
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Sehr geehrte/r Frau/Herr ... wir bestätigen ...
Gleich nach den Headern kommt eine Boundary, um auf Textmodus "umzustellen". Dann folgt der Text – der, wie erwaehnt verhackstueckt wird. Ohne diese Boundary kam der Text, soweit ich mich erinnere (ein paar Wochen her und mittlerweile verdraengt) auch auf Apple-Systemen mit kaputten Sonderzeichen an.
Moeglicherweise sollte ich hier nochmals "charset=UTF-8" unterbringen ("Content-Type: text/plain; charset=UTF-8")?
Code: 
-------=8494f9cc7389f5dc37f921f47e2cd8fd
Content-Type: application/pdf
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=schnickschnack.pdf"
Nach dem Text eine weitere Boundary, dann das PDF als Base64-Daten.

Ich befuerchte fast, dass ich jede einzelne Zeile, die in die E-Mail kommt, in das Schema "=?UTF-8?Q?encoded_text?=" wandeln muss. Bitte nicht :(

Noch zu erwaehnen: Mein X-SpamScore ist ziemlich hoch, mit folgenden Tests:
Code: 
X-SpamScore: 4.7
	tests= BAD_ENC_HEADER HS_INDEX_PARAM MIME_QP_LONG_LINE
"BAD_ENC_HEADER" scheint ja auch auf ein Zeichenkodierungs-Problem hinzuweisen. Kann aber nicht erkennen, was an den Headern falsch sein soll.

Die anderen beiden Tests sind klar – kennt jemand eine in PHP integrierte Funktion, die automatisch einen Umbruch nach 76 Zeichen einfuegt? Kann auch selber was schreiben, verwende aber lieber hauseigene Funktionen.

Ich kann gerne das Script liefern, wenn das von Belang ist.

Schon mal vielen Dank! Galanos
 
UTF-8 ist des Rätels Lösung.
Musst du mal googlen. Hier ein Lösungsansatz für OSCommerce, das ist ein sehr bekannter OpenSource Online Shop.
 
oneOeight schrieb:
das ist dann aber kein quoted-printable bei den umlauten...
Zum Vergrößern anklicken....
Du meinst, weil sie nicht im "="-Zeichen-Schema sind? So kommen sie bei mir in Apple Mail an (wo sie korrekt dargestellt werden), wenn ich den Quelltext anschaue.

oneOeight schrieb:
warum nutzt du z.b nicht http://www.php.net/manual/en/function.quoted-printable-encode.php ?
Zum Vergrößern anklicken....
Hmm. Ich habe schon wie ein Irrer mit "utf8_encode()", "utf8_decode()", "htmlentities()" und "html_entity_decode()" rumgefuhrwerkt, um Sonderzeichen sowohl im "To:", Betreff und Text als auch im PDF auf Apple-Systemen darstellen zu koennen. Aber ich kann's mal probieren. Danke.

Was haeltst du von mb_encode_mimeheader() fuer meine Zwecke?

Irgendwie fehlt mir das Verstaendnis dafuer. Ich habe alles, was nur irgendwie geht, auf UTF-8 umgestellt: Kodierung der Script- und HTML-Dateien im Editor, HTML-Header, Formulare, Scripte intern, Verbindung zur Datenbank, die Datenbank-Tabellen selbst, die Tabellen-Felder – einfach alles.
Und dann muss ich die sauberen UTF-8-Daten aus Formulareingaben und aus der Datenbank in eine E-Mail quetschen und nichts funktioniert, obwohl auch der E-Mail-Header die UTF-8-Kodierung enthaelt.
Fuer die E-Mail bin ich nach Trial&Error vorgegangen: Solange mit oben erwaehnten Funktionen rumgesaut, bis die E-Mail ordentlich bei mir ankam und abgehakt.
 
tja, e-mail ist halt ein sonderfall, da funktioniert es nur reibungslos wenn, du mit 7 bit arbeitest...
aber an sich solltest du auch utf-8 problemlos nutzen können, wenn du mal die kodierung richtig angibst...

gerade mal mit gmail getestet, der macht aus utf-8:
Code: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Dies ist ein Test mit Umlauten...
=C3=84
=C3=A4
=C3=9C
=C3=BC
 
Habe "Content-Type: text/plain; charset=UTF-8" nach der ersten Boundary notiert, probiert und es kommt genau wie vorher im Apple Mail an, also mit lesbaren Umlauten, aber nicht im "="-Zeichen-Schema.
Lasse es mal von einem Windows-Benutzer testen und melde mich. Danke fuer die bisherige Hilfe.

Uebrigens geht "quoted_printable_encode()" bei mir leider nicht, erst ab PHP 5.3.0 :(
 
es müsste < 5.3.0 doch auch eine imap_8bit geben mit der imap extension bzw eine andere MIME kodierungsfunktion...

ansonsten musst du halt Content-Transfer-Encoding auf 8bit setzen und hoffen, dass der mail server das kann...
 
Hmmmm – jetzt, wo du "imap_8bit()" erwaehnst, faellt mir ein, dass ich damit bereits den "To:"-String kodiert habe, falls der Name des Kunden Umlaute enthaelt. Das waer doch glatt mal 'nen weiteren Versuch wert.

Wenn du meinst, dass ich hoffen soll, dass der Mail-Server das kann: Betrifft das nur meinen Server (Shared Hosting und Versand per "sendmail", nebenbei), oder muessen weitere Stationen das auch unterstuetzen?
 
die meisten mail-server sollten inzwischen 8BITMIME haben, weiß aber gerade nicht, ob der mail-server es dann automatisch umkodiert, falls die andere gegenstelle es nicht hat...
 
Okay, ich habe Feedback bekommen: Mit "Content-Type: text/plain; charset=UTF-8" nach der ersten Boundary hat es geklappt *jubel*

Dann muss ich nur noch den X-SpamScore verringern ... *seufz*

Vielen, vielen Dank, oneOeight – ich schulde dir ein Eis :)
 
Noch immer in der Steinzeit?
ZendMail
Damit bekommst keine Probleme mit Umlauten, HTML/Text Mails etc etc.
 
Ah ja, dankeschoen. Ich arbeite mit Pear:Mail, so umfangreich wie dein Paket scheint es nicht zu sein. Pear:Mail_Mime sieht aehnlich aus.

Letztendlich bin ich aber ganz froh, mich selbst darum gekuemmert zu haben (mit eurer Hilfe), statt die Abkuerzung ueber fertige Classes zu nehmen, somit habe ich einen wichtigen Einblick in den Versand von E-Mails per PHP bekommen.

Falls es jemanden interessiert, ich habe auch den X-SpamScore unserer Bestaetigungs-E-Mails verringern koennen. Folgende Tests (von Apaches SpamAssassin) hatten sie nicht bestanden:

BAD_ENC_HEADER: Irgendwo im Header waren kodierte Strings, die nicht der angegebenen Zeichenkodierung entsprachen.

HS_INDEX_PARAM: Irgendwo im Body befand sich eine URL, die einen Query-Parameter enthaelt (z. B. "http://www.example.org/?12345").

MIME_QP_LONG_LINE: RFC 1521 verlangt, dass Zeilen in E-Mails nach 76 Zeichen umbrechen.


Alles Merkmale von potentiellen Spam-E-Mails. In Summe kamen wir auf 4,7 Punkte, die meisten Mail-Provider ordnen dies bereits als Spam ein, 1und1 erst ab ca. 5.

BAD_ENC_HEADER war am schwerwiegendsten, mit ca. 3 Punkten. Lag bei uns an der "To:"-Adresse, die falsch UTF-8-kodiert war. Konnte ich, nach einigem Herumprobieren, mit mb_encode_mimeheader() und vorherigem Aufruf von mb_internal_encoding() loesen.

Die zu langen Zeilen habe ich manuell umbrochen, es waren nur 2 statische Zeilen. Gibt es aber auch Funktionen fuer, z. B. wordwrap().

"HS_INDEX_PARAM" hat nur einen winzigen Score, deshalb habe ich es vorerst so belassen. Auf lange Sicht werde ich aber die URL in der E-Mail durch eine ohne Query-Parameter ersetzen, die einfach auf die gewuenschte Seite weiterleitet.
 
Galanos schrieb:
"HS_INDEX_PARAM" hat nur einen winzigen Score, deshalb habe ich es vorerst so belassen. Auf lange Sicht werde ich aber die URL in der E-Mail durch eine ohne Query-Parameter ersetzen, die einfach auf die gewuenschte Seite weiterleitet.
Zum Vergrößern anklicken....

Oder Du machst den Parameter unerkenntlich.

und per .htaccess-Weiterleitung auf

EDIT: Oh, ich glaube das meintest Du auch …

Der Tipp mit einem besseren Mailer würde ich mir allerdings zu Herzen nehmen. Ich nutze PHPMailer. Dann kannst Du Dich in der Zeit um Deine Kunden/Produkte kümmern.
 
Meinte ich beinahe:
PHP: 
<?php
    header("Location: ./?12345");
    die();
?>
Aber per .htaccess ist ja eigentlich noch eleganter ...
Jetzt sehe ich es gerade: Mein Query-Parameter ist als solcher nicht notwendig – er verweist nur auf die statischen AGB (example.org/?agb) ;) Ich weiss, unnoetig wie ein Kropf … Jedenfalls koennte deine Variante ("…/id/query") dem Spam-Algorithmus als Versuch der Kaschierung des Query-Parameters erscheinen (was es ja auch ist) – worauf die Dinger meines Wissens seeehr empfindlich reagieren.
Jakob schrieb:
Der Tipp mit einem besseren Mailer würde ich mir allerdings zu Herzen nehmen. Ich nutze PHPMailer. Dann kannst Du Dich in der Zeit um Deine Kunden/Produkte kümmern.
Zum Vergrößern anklicken....
Das macht meine Frau :) Ist ihr Shop, ich habe ihr den "nur" geschrieben.
Naechstes Mal werde ich auch auf Klassen zurueckgreifen, denke ich. Ich fand's nur wichtig, es zu verstehen und erst dann die bequeme Variante zu nutzen – es ist mein erster Shop.
 
Zuletzt bearbeitet:
Zurück
Oben Unten