Kyrillische Zeichen im Betreff

[aradeke]

Hey,

ich stelle meine Website (www.aradeke.de) gerade auf PHP um und habe Probleme im Kontaktformular.

Eigentlich funktionert es ganz gut. Per mail([MAIL],$Betreff,$s_msg, $header); wird eine Nachricht erzeugt, die dank $s_msg = nl2br(utf8_encode($s_msg)); richtig dargestellt wird.

Das trifft jedoch leider nicht auf den Betreff zu. Dort erhalte ich, wenn ich kyrillische Zeichen angebe immer das &#XXXX;-Format. Bislang habe ich das wie folgt gelöst:

  
$header  = 'MIME-Version: 1.0'."\r\n";  
$header .= 'Content-type: text/html; charset=UTF-8' . "\r\n";  
$header .= 'Content-Transfer-Encoding: quoted_printable'."\r\n";  
...  
if(strlen($Betreff) == 0) {$Betreff = 'Anfrage von Website';}  
else {$Betreff = utf8_encode($Betreff);}  
...  
mail([MAIL],$Betreff,$s_msg, $header);  

Wäre sehr froh, wenn mir jemand einen Hinweis geben könnte.

Vielen Dank im Voraus!

Alexander

[Der Martin]

Hallo,

Eigentlich funktionert es ganz gut. Per mail([MAIL],$Betreff,$s_msg, $header); wird eine Nachricht erzeugt, die dank $s_msg = nl2br(utf8_encode($s_msg)); richtig dargestellt wird.

erzeugst du absichtlich HTML-Mails? Ich würde das nicht wollen, ist aber Geschmackssache.
Und utf8_encode() sollte vollkommen überflüssig sein, wenn man seine Quellcodes sowieso konsequent in UTF-8 codiert.

Das trifft jedoch leider nicht auf den Betreff zu. Dort erhalte ich, wenn ich kyrillische Zeichen angebe immer das &#XXXX;-Format. Bislang habe ich das wie folgt gelöst:

$header  = 'MIME-Version: 1.0'."\r\n";

$header .= 'Content-type: text/html; charset=UTF-8' . "\r\n";
$header .= 'Content-Transfer-Encoding: quoted_printable'."\r\n";
...
if(strlen($Betreff) == 0) {$Betreff = 'Anfrage von Website';}
else {$Betreff = utf8_encode($Betreff);}
...
mail([MAIL],$Betreff,$s_msg, $header);

  
Auch hier sollte utf8\_encode() überflüssig sein, wenn man's von Anfang an ordentlich macht.  
  
Allerdings müssen Headerzeilen in Mails sowieso anders codiert werden, wenn sie Zeichen außerhalb des ASCII-Bereichs enthalten. Das [PHP-Manual](http://www.php.net/manual/en/function.iconv-mime-encode.php) zeigt dort, wo die geeignete Funktion beschrieben ist, auch ein paar Beispiele, wie die korrekte Codierung dann aussieht.  
  
So long,  
 Martin  

-- 
Paradox ist, wenn der Innenminister sich äußert und der Außenminister sich erinnert.  
  
Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(

[Tom]

Hello,

Allerdings müssen Headerzeilen in Mails sowieso anders codiert werden, wenn sie Zeichen außerhalb des ASCII-Bereichs enthalten. Das PHP-Manual zeigt dort, wo die geeignete Funktion beschrieben ist, auch ein paar Beispiele, wie die korrekte Codierung dann aussieht.

Die Funktion lässt vermuten, dass sie das bekannte Problem mit dem Zeilenumbruch verursacht, wenn auf einem Linux-System das Sendmail-Script verwendet wird. Es sollte dann also wieder die Konstante PHP_EOL benutzt werden

$prefs = array(
    'scheme' => 'Q',
    'input-charset' => 'UTF-8',
    'output-charset' => 'UTF-8',
    'line-length' => 76,
    'line-break-chars' => PHP_EOL,
  );

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Der Martin]

Hallo,

http://www.php.net/manual/en/function.iconv-mime-encode.php
Die Funktion lässt vermuten, dass sie das bekannte Problem mit dem Zeilenumbruch verursacht, wenn auf einem Linux-System das Sendmail-Script verwendet wird. Es sollte dann also wieder die Konstante PHP_EOL benutzt werden

das ist ganz bestimmt kein Fehler - obwohl ich aus eigener Erfahrung sagen kann, dass die Devise "Verwende CR/LF auf Windows-Host, nur LF auf Linux-Hosts" auch nicht immer richtig ist. Bei meinem Hoster, der Apache auf Linux-Hosts einsetzt, verwende ich auch konsequent CR/LF, ohne dass ich je Probleme damit hatte.
Es scheint also nur ganz bestimmte sendmail-Implementierungen oder sendmail-Clones zu betreffen, die mit CR/LF Zicken machen.

So long,
 Martin

[dedlfix]

Hi!

Bei meinem Hoster, der Apache auf Linux-Hosts einsetzt, verwende ich auch konsequent CR/LF, [...]

Dein konsequentes Handeln lohnt sich aber nicht, weil es von PHP zunichte gemacht wird. Die Funktion mail() verwendet intern LFs, um die Header zusammenzustellen und abzuschließen.

Lo!

[Tom]

Hello,

Bei meinem Hoster, der Apache auf Linux-Hosts einsetzt, verwende ich auch konsequent CR/LF, [...]

Dein konsequentes Handeln lohnt sich aber nicht, weil es von PHP zunichte gemacht wird. Die Funktion mail() verwendet intern LFs, um die Header zusammenzustellen und abzuschließen.

Aber eben nur für 'To:' und 'Subject:' und nur, wenn LINUX detectiert wird. Folglich sollten sich die Umbrüche des Arguments für Additional Headers dem anschließen. Das muss aber der Programmierer berücksichtigen...

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Tom]

Hello,

Es scheint also nur ganz bestimmte sendmail-Implementierungen oder sendmail-Clones zu betreffen, die mit CR/LF Zicken machen.

Das ist jetzt die Frage, ob es Zicken sind, oder ob es "works as designed" ist, wenn die per Script übergebene Maildatei konsequent von "\n" auf "\r\n" umgebaut wird.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Der Martin]

Hallo,

Es scheint also nur ganz bestimmte sendmail-Implementierungen oder sendmail-Clones zu betreffen, die mit CR/LF Zicken machen.
Das ist jetzt die Frage, ob es Zicken sind, oder ob es "works as designed" ist, wenn die per Script übergebene Maildatei konsequent von "\n" auf "\r\n" umgebaut wird.

es ist ganz bestimmt "works as designed", wenn ich als PHP-Programmierer nur LF verwende und sendmail macht vor der Übergabe an den MTA ordentlich CR/LF daraus, wie es im RFC vorgesehen ist. Das muss so sein.

Wenn ich aber schon CR/LF übergebe, liegt es an der Intelligenz von sendmail, ob es den Zeilenumbruch zuerst untersucht und nur dann ein CR ergänzt, wenn noch keins da ist, oder stur alle LF durch CR/LF ersetzt, so dass doppelte CRs entstehen können, oder gar alle CR *UND* alle LF durch CR/LF ersetzt. Oder, wie dedlfix andeutet, PHP übersetzt zwischendrin auch schon ...
Ich weiß bis heute nicht genau, ob die Zeilenumbrüche an den Schnittstellen
  PHP-Script -> PHP-Interpreter -> sendmail
wirklich exakt spezifiziert sind oder nicht.

Ciao,
 Martin

[Tom]

Hello,

es ist ganz bestimmt "works as designed", wenn ich als PHP-Programmierer nur LF verwende und sendmail macht vor der Übergabe an den MTA ordentlich CR/LF daraus, wie es im RFC vorgesehen ist. Das muss so sein.

Nein, macht es eben gerade nicht, wenn es um Linux-Systeme (mit Sendmail-Script) geht. Dann macht PHP nur "\n" daraus und alles funktioniert. Das Sendmail-Script macht dann aus "\n" erst "\r\n" zur Übergabe an den SMTP-Server. Folglich darf der Programmierer auch nix anderes einbauen in die Additional Headers, denn die werden von PHP nicht zurückgebaut, aber vom Sendmail-Script wieder aufgebaut.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Der Martin]

Hallo,

es ist ganz bestimmt "works as designed", wenn ich als PHP-Programmierer nur LF verwende und sendmail macht vor der Übergabe an den MTA ordentlich CR/LF daraus, wie es im RFC vorgesehen ist. Das muss so sein.
Nein, macht es eben gerade nicht, wenn es um Linux-Systeme (mit Sendmail-Script) geht. Dann macht PHP nur "\n" daraus und alles funktioniert. Das Sendmail-Script macht dann aus "\n" erst "\r\n" zur Übergabe an den SMTP-Server.

genau das schrieb ich doch.

Folglich darf der Programmierer auch nix anderes einbauen in die Additional Headers, denn die werden von PHP nicht zurückgebaut, aber vom Sendmail-Script wieder aufgebaut.

Ja, aber es gibt offenbar unterschiedliche Implementierungen: Solche, die damit klarkommen, wenn sie schon CR/LF angeliefert bekommen und das im Sinne des Programmierers interpretieren können, und solche, die das nicht können.

Ciao,
 Martin

[Tom]

Hello,

es ist ganz bestimmt "works as designed", wenn ich als PHP-Programmierer nur LF verwende und sendmail macht vor der Übergabe an den MTA ordentlich CR/LF daraus, wie es im RFC vorgesehen ist. Das muss so sein.
Nein, macht es eben gerade nicht, wenn es um Linux-Systeme (mit Sendmail-Script) geht. Dann macht PHP nur "\n" daraus und alles funktioniert. Das Sendmail-Script macht dann aus "\n" erst "\r\n" zur Übergabe an den SMTP-Server.

genau das schrieb ich doch.

*Ach* Was habe ich denn da eben wieder gelesen. Tut mir leid, habe ich irgendwie übersehen, dass Du das schon richtig beschrieben hattest.

Was die unterschiedlichen Implementierungen betrifft, müsste man mal forschen. Ich hatte auch mal einen V-Server, dem das egal war...

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[dedlfix]

Hi!

Wenn ich aber schon CR/LF übergebe, liegt es an der Intelligenz von sendmail, ob es den Zeilenumbruch zuerst untersucht und nur dann ein CR ergänzt, wenn noch keins da ist, oder stur alle LF durch CR/LF ersetzt, so dass doppelte CRs entstehen können, oder gar alle CR *UND* alle LF durch CR/LF ersetzt. Oder, wie dedlfix andeutet, PHP übersetzt zwischendrin auch schon ...

Nee, PHP übersetzt nicht, es verwendet einfach LF für seine Zeilenumbrüche und lässt die vom Nutzer angegebenen (für die zusätzlichen Header) so wie sie sind. (Es sei denn, die sind in Subject und To, da werden sie mittlerweile in Leerzeichen (wenn ich mich recht erinnere) übersetzt.)

Ich weiß bis heute nicht genau, ob die Zeilenumbrüche an den Schnittstellen
  PHP-Script -> PHP-Interpreter -> sendmail
wirklich exakt spezifiziert sind oder nicht.

Genau zu diesen Zeilenumbrüchen gibt es mindestens eine Diskussion im PHP-Bug-Tracker. Ich vermische da mal meine Erinnerungen an die dortige Diskussion mit meinem Verständnis der Sachlage: Ein MTA muss notwendige Anpassungen zwischen den im System üblichen Zeilenumbrüchen und SMTP vornehmen. Es kann ja auch sein, dass gar kein SMTP im Spiel ist und der MTA das auf anderem Weg zum Empfänger befördert. Das Programm, das eine Nachricht an den MTA übergibt, kann das nicht wissen und sollte sich deshalb an die Gepflogenheiten des Systems halten. Genau das haben einige MTAs getan und haben CRLFs in CRCRLFs konvertiert, weil sie systemspezifisch nur LFs erwarteten. Aus dieser Bugmeldung resultierte dann auch die Empfehlung im Handbuch, im Problemfall nur LFs zu verwenden und vermutlich auch die interne Verwendung von nur LFs. Aufgrund der nicht beeinflussbaren internen LFs kann man wie gesagt getrost auch stets nur LFs verwenden, der MTA hat ja sowieso welche zu konvertieren.

Lo!