Text Mails mit PHP versenden

[Josch]

Hallo Gemeinde,

wenn ich über PHP und einer MailKlasse eMails über meine Diskstation verschicke, wird der Header "text/html" anscheinend ignoriert.
Beim Empfang werden Umlaute und Zeilenumbrücke "\r\n" nicht berücksichtig, bzw. falsch dargestellt.

Hat jemand eine Idee woran das liegen könnte.

Besten Dank

 

[jahlives]

d.h. du hast ne eigene Mailklasse und verwendest nirgends die php-Funktion mail()? Ich würde mir mal den String der gesamten Mail ausgeben lassen, möglichst kurz bevor du diesen String zum "Versand" übergibst (also alle Header und der gesamte Body). Btw: Hast du ned ausser acht gelassen, dass Mails pro Zeile nur eine bestimmte Anzahl Zeichen haben dürfen? Sind afaik 72 d.h. minus dem nötigen Zeilenumbruch hast du pro Zeile also nur 70 Zeichen zur Verfügung. Die Umlaute hast du allesamt auch korrekt kodiert im String?
Und wo siehst du die Zeilenumbrüche ned? du bist dir bewusst, dass du bei html diese nur im Quellcode sehen kannst?

 

[Josch]

Ich habe das ganze mal online gestellt bei meinem Provider und da funzt das prima.
Die Zeilenumbrüche sehe ich in der Mail wie geschrieben. Also so: "/r/n".

 

[jahlives]

und du bist sicher dass du "\r\n" in deinem Code hast? Wichtig wäre immer noch folgende (offene) Frage: Verwendet diese Mailklasse zum Versand die PHP mail() Funktion oder baut sie selber Socketverbindungen zum SMTP Server auf?
Du sagst auf dem Server beim Provider würde es gehen. Weisst du denn was für ein Betriebssystem dort läuft? Die mail() Funktion ist auf Windows und Linux/Unix nicht identisch im Verhalten. Könnte es also sein, dass dein Provider ein Windows einsetzt?
**edit**
Mir ist noch eingefallen, dass es eventuell sinnvoll sein könnte, wenn du die Anzeige von PHP-Fehlern aktivierst. Das kannst du in den PHP Optionen im DSM machen. Per default zeigt PHP auf einer DS keinerlei Fehler an
**/edit**

 

[Josch]

beim Provider ebenfalls Linux.
Zeilenumbrüche sind vorhanden.

Mail() wird als Funktion ausgeführt.

 

[jahlives]

error_reporting in PHP voll aufgedreht und keinerlei Fehlerausgabe?

 

[Josch]

An dem PHP-Script kann es nicht liegen, da es ja beim Provider wunderbar funktioniert.

error_reporting( -1 )

 

[jahlives]

An dem PHP-Script kann es nicht liegen, da es ja beim Provider wunderbar funktioniert.

error_reporting( -1 )

Wieso kann es nicht doch am Script liegen? Und wenn du nicht endlich das error reporting aktivierst, dann lass ich es mit weiteren Ideen

 

[Josch]

Würde ein Fehler im Script vorliegen, dann würde dies bei meinem Provider nicht fehlerfrei laufen.

error reporting ist aktiviert! error_reporting(-1) bedeuted "alle Fehler anzeigen" (E_ALL). error_reporting(0) => "alle Fehler unterdrücken"

Meines erachtens wird der MIME-type nicht richtig gehandhabt von der Diskstation über SMTP.

 

[jahlives]

1. Nicht jeder Fehler im Script muss nicht zwangsläufig immer einen Fehler werfen. Das kann je nach Umgebung einen Fehler geben oder nicht.
2. error_reporting aktivieren alleine reicht bei der DS ned, denn Synology hat per default den display.errors Parameter auf 0. Damit wird dir nichts angezeigt. Egal welches error.reporting Level du drin hast
3. das mit dem MIME Type glaub ich weniger. Denn für die DS ist das ja nur ein String. Da wird rein gar nichts seitens der DS interpretiert. Der String wird einfach 1:1 weitergegeben.

Hast du mal probiert, statt \r\n nur \n als Zeilenendzeichen zu verwenden. Es ist zwar eine Verletzung der entsprechenden RFCs aber es scheint Mailserver zu geben, die bei \r\n den Carriage return (\r) ebenfalls mit \n ersetzen, was dann zu einer Verdoppelung der Zeilenenden führt und dir damit natürlich die Header zerreisst.

 

[Josch]

display.errors auf der DS ist ON.

Es sind ja nicht nur die Zeilenumbrüche, sondern auch die Sonderzeichen die nicht richtig dargestellt werden.

Die Mail-Klasse ist nicht von mir geschrieben und ist meines Wissens auch fehlerfrei, da diese sehr verbreitet ist und ständig verbessert wurde.

Name der Klasse: MIMEMailxPHP4_V2, zu finden unter www.feike.biz

 

[jahlives]

hm du siehst aber, dass diese Klasse in PHP4 geschrieben ist? Auf der DS läuft PHP5.irgendwas. Könnte also sein, dass da was ned passt. Weiter habe ich auf der Seite folgendes gesehen (sorry hättest du auch finden können) http://lmgtfy.com/?q=MIMEMailPHP4+++linefeed

Important hint: Lots of users encounter problems with linefeeds. The usual problem is, that you use a windows editor to edit your codefile and a unix MTA to send the message. If - for some reason - your FTP transfer misses the /n -> /r/n replacement, your MTA will report a miss-build MIME mail. In this case experiment with function:
$mail->setEOL($eol); // $eol can be "\n" or "\r\n" defualt is unix like "\n"

 

[Josch]

Wie gesagt, wenn die Seite online ist, dann funzt das ganze ja. Also kann es nicht am FTP transfer liegen.
PHP5 dürfte an sich kein Problem mit dem Script haben.
Standardmäßig ist EOL -> "\n" in der mail-klasse als default gesetzt.
Ich werde mal "\r\n" als Standard definieren und auf der DS und beim Provider schauen was ich dann empfange.

 

[Holgo]

Ohoho, gerade als ich (bevor ich die DS hatte) auf meinem Test-XAMPP auf die neueste PHP-Version aktualisierte, funktionierte so gut wie gar nix mehr an Scripten. Viele Sachen, die sogar bei den ersten PHP 5 Versionen noch funktionierten und erstmal nur in Dokumentationen als veraltet gekennzeichnet waren, mit dem Hinweis, man solle sie nicht mehr verwenden, sind inzwischen ganz rausgeflogen und verursachen Fehler. Ein Beispiel - was allerdings weniger veraltete Technik ist, als vielmehr schlampige Programmierung, die vorher toleriert wurde - ist, die Verwendung einer Variablen, ohne vorherige explizite Definition selbiger und das findet man in fast jedem Script.

 

[jahlives]

@josch
Haste denn selber im Code \r\n verwendet und als default Wert nur \n? Das könnte das Durcheinander erklären
@Holgo
einen Fehler gibt es nicht wenn du eine Variable nicht initialisierst. Das gibt bestenfalls eine notice und nie einen error. PHP ist keine stark typisierte Sprache, von dem her muss der Parser eigentlich den Typ eine Variable ned kennen. Er guckt sich den Wert an und nimmt dann den treffendsten Typ. Du kannst zur Laufzeit problemlos den Typ einer Variable ändern. Entweder explizit oder automatisch durch PHP (auto typecast). Ein echtes Sicherheitsrisiko ist das nur wenn man eine Serverkonfig mit register_globals ON verwendet. Dann ist es aber wirklich gefährlich, weil man dann durch GET und POST Request direkt Variabeln in den Code speisen kann z.B.

function checkLogin($secret) {
 if ($secret === 'geheim') {
  $checked = true;
 }
}
checkLogin($_POST['password']));
[anderer Code]
if($checked == true) {
 echo 'Total geheimer Text';
}

diesen Code zerleg ich dir bei register_globals on indem ich dir eine GET oder POST Variable Namens checked mit Wert 1 schicke. Klar hats noch ein weiteres böses don't do drin, aber es gibt leider zuviele Codes die genau so laufen

 

[Holgo]

Nee, ich meine nicht, dass man der Variablen einen Typ zuweisen muß aber man muß sie neuerdings erwähnen. Früher konnte man beispielsweise abfragen:

if ($variable == "blabla") {echo("Gurkensalat ist alle.");} else {echo("Ein Loeffel ist noch da.");}

ohne, dass $variable vorher im Script erwähnt wurde. Dann wurde es eben als NULL ausgewertet und es war noch ein Löffel da. Jetzt verhält sich der Server wie Mädchen und fängt an zu heulen, dass er $variable nicht kennt. Ja und diese Mitteilung bezeichne ich auch als Fehler, weil ich ja bescheid gesagt bekomme, dass irgendwas nicht richtig ist und wenn was nicht richtig ist, ist es falsch und das ist für mich ein Fehler, auch wenn es für den Informatiker kein "Error" ist.

 

[jahlives]

Kennst du isset() ? Spart die Notice resp "Fehler"
Deinen Codeschnippel würde ich so schreiben

if (isset($variable) && $variable == "blabla") {echo("Gurkensalat ist alle.");} else {echo("Ein Loeffel ist noch da.");}

Man sollte immer erst die Existenz einer Variable prüfen, bevor man was damit anstellen will

Btw: der Server wertet ein nicht gesetztes $var immer noch als NULL

PHP Notice:  Undefined variable: var in /root/null.php on line 3
NULL

eigentlich sollte das error_reporting auf einem Produktivserver immer abgeschaltet sein. Zumindest aber notices sollten deaktiviert sein. PHP kann auch in Files loggen. Wenn man die Fehlerausgabe im Browser trotzdem will sollte man zumindest notice und deprecated rausfiltern

error_reporting = E_ALL & ~E_DEPRECATED & ~E_NOTICE

Gruss

tobi

@topicstarter:
Sorry für den Offtopic in deinem Thread

 

[Holgo]

Kennst du isset() ? Spart die Notice resp "Fehler"
Deinen Codeschnippel würde ich so schreiben

if (isset($variable) && $variable == "blabla") {echo("Gurkensalat ist alle.");} else {echo("Ein Loeffel ist noch da.");}

Man sollte immer erst die Existenz einer Variable prüfen, bevor man was damit anstellen will
...

Jojo, das hab ich ja inzwischen gelernt und ich hab ja auch in meinem ersten Post das Ganze selbst als "schlampige Programmierung" bezeichnet. War vielleicht kein gutes Beispiel für "Fehler". Aber es hat sich doch unabhäng davon jetzt, bei der Entwicklung von PHP4 zu PHP5 tatsächlich soviel geändert, dass etwas, was irgendwo bei einem Webhoster noch funktioniert, nicht zwangsweise auf der DS auch funktioniert - um mal jetzt die Kurve zum Thema zurückzubiegen.

 

[Josch]

Ja, Du hast recht. Ich habe im Code \r\n verwendet und den default Wert auf \n gesetzt. War natürlich ein WirrWarr.
Das mit den Umlauten ist noch ein Problem. Wenn ich charset auf utf-8 setze bekomme ich die Umlaute, bzw. Sonderzeichen richtig angezeigt wenn ich lokal über die DS sende. Über den Provider werden diese jetzt nicht mehr angezeigt. vorher war es genau anders herum. ??!!

 

[jahlives]

wie genau kommen denn die Umlaute an? Als kryptischer Zeichensalat oder als &-codiertes Zeichen?