/Email - Umlaute für Mailbody kodieren?

[Oliver_E]

Moin liebe Comunity,

beim versenden einer Mail mittels der Funktion "mail()" habe ich das Problem, das sämtliche Umlaute nicht so in der E-Mail erscheinen, wie ich es erwarte, sprich es werden irgendwelche Sonderzeichen statt der ü's, ä's, etc. dargestellt.

In der php-Funktions-Übersicht bin ich leider nicht fündig geworden (oder ich habe nach den falschen Begriffen gesucht). Ich vermute das ich hier zusätzliche Header-Angaben machen muss, beim generieren der E-Mail, aber da bin ich mir leider nicht sicher, bzw. mein Versuch blieb bislang ohne dem gewünschten Ergebnis, wie z.B. dieses hier:

<start code-schnipsel>
$headers = "From: " . $absender ."\n";
$headers .= "Content-Type: text/plain; charset="iso-8859-1"\n";
...
if(mail($_SESSION["email"], $betreff, $koerper, $headers))
    { ... }
</end code-schnipsel>

Der eigentliche Inhalt wird in der String-Variablen $koerper festgelegt, wird also nicht dynamisch aus einem Formular übernommen, bis auf ein paar $_SESSION-Variablen (die aber sauber übernommen werden).

Vor längerer Zeit habe ich in einem Beispiel-Skript mal gesehen, das die Umlaute kodiert worden sind (beispielsweise das "ö" durch "^", was später in der E-Mail auch als "ö" dargestellt worden ist.

Nun meine Frage, gibt es eine Kodierungstabelle wo man dies nachschlagen kann? Gibt es eine Funktion, der ich den String übergeben kann, der die Umlaute korrekt kodiert? Liegt es an der Header-Angabe?

Bin für jeden Lösungsansatz dankbar.

Liebe Grüße

Oliver

[ray]

hallo,

In der php-Funktions-Übersicht bin ich leider nicht fündig geworden (oder ich habe nach den falschen Begriffen gesucht). Ich vermute das ich hier zusätzliche Header-Angaben machen muss, beim generieren der E-Mail, aber da bin ich mir leider nicht sicher, bzw. mein Versuch blieb bislang ohne dem gewünschten Ergebnis, wie z.B. dieses hier:

damit kannst du Zeichen in einem String durch andere Zeichen oder Zeichenfolgen ersetzen:

$koerper = str_replace("Ä","&Auml;",$koerper);
$koerper = str_replace("Ö","&Ouml;",$row);
$koerper = str_replace("Ü","&Uuml;",$row);
$koerper = str_replace("ä","&auml;",$row);
$koerper = str_replace("ö","&ouml;",$row);
$koerper = str_replace("ü","&uuml;",$row);

...hoffe ich konnte dir einen Ansatz geben
cya

[rob]

$koerper = str_replace("Ä","&Auml;",$koerper);

Das ist Mist. Es wird ja keine HTML-Mail verschickt. Das Ersetzen hätte zur Folge, daß die HTML-Maskierungen in der Mail stehen würden.
Mir scheint es so, als würde die Mail im US-ASCII-Format, also mit 7Bit-Encoding verschickt. Das hat dann natürlich zur Folge, daß alle Zeichen überhalb 127 verloren gehen, also auch alle Umlaute.

Ich würde als erstes mal versuchen, das Content-Transfer-Encoding auf 8 Bit zu setzen. Das geht, indem man der mail()-Funktion zusätzliche Header mitgibt.

$headers.= "Content-type: text/plain; charset=iso-8859-1\r\n";
$headers.= "Content-Transfer-Encoding: 8bit\r\n";

Und wenn das nicht funktionieren sollte, dann versuche es mal so:
$headers.= "MIME-Version: 1.0\r\n";
$headers.= "Content-type: text/plain; charset=iso-8859-1\r\n";

Gruß, rob

[Tom]

Hello,

erstens ist so ein Vorschlag nicht "Mist" sondern bestenfalls hier nicht geeignet und zweitens würde ich auch keine 8-bit-Mails verschicken. Es gibt noch zuviele Systeme, die das nicht unterstützen.

Bau den Text um auf quoted printable. Dafür kann man sich eine eigene Funktion schreiben, wenn es keine fertige geben sollte.

Und für die unbedingte Erstezung von Zeichen oder Sequenzen ist der Array-Mechanismus von str_replace() sehr zu empfehlen. Den möchte ich meinem Vorposter nochmals ans Herz legen.

Liebe Grüße aus http://www.braunschweig.de

Tom

[rob]

erstens ist so ein Vorschlag nicht "Mist" sondern bestenfalls hier nicht geeignet

Bringt aber hier leider ein noch "falscheres" Ergebnis (BTW: Das "Mist" sollte nicht beleidigend gemeint sein).

Und für die unbedingte Erstezung von Zeichen oder Sequenzen ist der Array-Mechanismus von str_replace() sehr zu empfehlen. Den möchte ich meinem Vorposter nochmals ans Herz legen.

Ja, dagegen habe ich auch nichts. Aber es bringt nichts ä durch &auml; zu ersetzen, wenn man der Content-Type der Mail auf text/plain steht. Dann würde aus einem "komischen Zeichen" nämlich fünf "komische Zeichen" werden.
In diesem Fall muß ein anderes Content-Transfer-Encoding gesetzt werden, so daß die Umlaute erhalten bleiben.

Gruß, rob

[Tom]

Hello,

[...] Aber es bringt nichts ä durch &auml; zu ersetzen, wenn man der Content-Type der Mail auf text/plain steht. Dann würde aus einem "komischen Zeichen" nämlich fünf "komische Zeichen" werden.
In diesem Fall muß ein anderes Content-Transfer-Encoding gesetzt werden, so daß die Umlaute erhalten bleiben.

Das kann ich nachvollziehen und stimme Dir zu. Um den Aufbau von eMails zu verstehen, braucht msn sich ja eigentlich nur einige ganz einfache (text, mit Attacehment, mit Bild, html, usw...) mit dem Mail-Client seines Vertrauens, so der das kann, zu produziern und dann mal den Quelltext anzuschauen...

Das versteht man zumindest leichter, als die RFCs

Liebe Grüße aus http://www.braunschweig.de

Tom

[Oliver_E]

Hi Rob, Ray, Tom,

Ich würde als erstes mal versuchen, das Content-Transfer-Encoding auf 8 Bit zu setzen. Das geht, indem man der mail()-Funktion zusätzliche Header mitgibt.

$headers.= "Content-type: text/plain; charset=iso-8859-1\r\n";
$headers.= "Content-Transfer-Encoding: 8bit\r\n";

Und wenn das nicht funktionieren sollte, dann versuche es mal so:
$headers.= "MIME-Version: 1.0\r\n";
$headers.= "Content-type: text/plain; charset=iso-8859-1\r\n";

Gruß, rob

ich habe gerade beides mal ausprobiert. Es kommt jedesmal die gleiche Mail wie vorher auch an, sprich immer noch die Sonderzeichen statt den erhofften Umlauten.

Ferner habe ich auch mal mit den "\r\n" und "\n" gespielt (was laut den Kommentaren bei der mail()-funktion auch mal zu unerwarteten Fehlern kommen kann). Auch hier der gleiche Effekt.

Das mit dem str_replace() habe ich eigentlich schon mal vorher indirekt getestet, indem gleich die Umlaute nach HTML-Format maskiert hatte. Aber die werden 1:1 übernommen, sprich "&auml;" bleibt auch in der späteren E-Mail "&auml;".

Was mich aber noch irgendwie wundert ist, das die Umlaute, die aus den $_SESSION Array kommen, sauber in der späteren Email dargestellt werden.

Danke schon mal für eure Mithilfe.

Lieben Gruß

Oliver

[Tom]

Hello Oliver,

poste uns doch mal die Header einer solchen einfachen angekommenen Mail hier. Dann kann man da doch besser dran rumdoktorn.

Liebe Grüße aus http://www.braunschweig.de

Tom

[Oliver_E]

Hi Tom,

Hello Oliver,

poste uns doch mal die Header einer solchen einfachen angekommenen Mail hier. Dann kann man da doch besser dran rumdoktorn.

auf die Gefahr hin, von euch erschlagen zu werden, nachfolgend der Header.

ausgetauscht wurden 4 Sachen:

proxy-server = der mir vorgeschaltete Proxy-Server mit Namen
mein-provider = der Server wo die Mail generiert wurde mit Namen
meine domain = selbsterklärend
IP's wurden durchge'x'ed.

Hoffe das tut dem ganzen jetzt keinen Abbruch.

Received: from mmail.proxy-server.de ([xxx.xxx.xxx.xxx]) by example.proxy-server.de with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
 id LRSY35YY; Tue, 15 Jun 2004 14:01:30 +0100
Received: from localhost ([127.0.0.1])
 by mmail.proxy-server.de with esmtp (Exim 4.30)
 id 1BaCd7-0006m1-8v
 for [e-mail]; Tue, 15 Jun 2004 14:01:29 +0200
Received: from mmail.proxy-server.de ([127.0.0.1])
 by localhost (mmail [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
 id 01089-44 for [e-mail];
 Tue, 15 Jun 2004 14:01:28 +0200 (CEST)
Received: from moutng.mein-provider.de ([xxx.xxx.xxx.xxx])
 by mmail.proxy-server.de with esmtp (Exim 4.30)
 id 1BaCd6-0006lw-Pm
 for [e-mail]; Tue, 15 Jun 2004 14:01:28 +0200
Received: from [xxx.xxx.xxx.xxx] (helo=mrvnet.mein-provider.de)
 by moutng.mein-provider.de with esmtp (Exim 3.35 #1)
 id 1BaCd5-00065L-00
 for [e-mail]; Tue, 15 Jun 2004 14:01:27 +0200
Received: from [xxx.xxx.xxx.xxx] (helo=infong117 ident=8)
 by mrvnet.mein-provider.de with smtp (Exim 3.35 #1)
 id 1BaCd5-00015M-00
 for [e-mail]; Tue, 15 Jun 2004 14:01:27 +0200
Received: from [xxx.xxx.xxx.xxx](IP may be forged by CGI script)
 by infong117.mein-provider.de with HTTP; Tue, 15 Jun 2004 14:01:27 +0200
Date: Tue, 15 Jun 2004 14:01:27 +0200
Precedence: bulk
To: [e-mail]
Subject: Mein tolles Subject
From: [e-mail]  // ist gleich dem Inhalt aus $absender (s. Posting weiter oben)
Content-Type: text/plain; charset=iso-8859-1
Message-Id: [e-mail]
X-Provags-ID: mein-provider.de [e-mail] sender-info:34379510@infong117
X-Virus-Scanned: by amavisd-new at proxy-server.de

Liebe Grüße

Oliver

[wahsaga]

hi,

Hoffe das tut dem ganzen jetzt keinen Abbruch.

nein, da der ganze kram sowieso nicht relevant ist für das problem.

allerdings frage ich mich doch, warum du das alles herauslöschst. jeder, dem du einem mail schickst, hat doch sowieso diese ganzen angaben zur verfügung - und dein rechner lebt ja offenbar immer noch, also warum jetzt diese paranoia?

frühestens ab hier wird' interessant:

Date: Tue, 15 Jun 2004 14:01:27 +0200
Precedence: bulk
To: [e-mail]
Subject: Mein tolles Subject
From: [e-mail]  // ist gleich dem Inhalt aus $absender (s. Posting weiter oben)
Content-Type: text/plain; charset=iso-8859-1
Message-Id: [e-mail]
X-Provags-ID: mein-provider.de [e-mail] sender-info:34379510@infong117
X-Virus-Scanned: by amavisd-new at proxy-server.de

gruß,
wahsaga

[Oliver_E]

Hi wahsaga,

allerdings frage ich mich doch, warum du das alles herauslöschst. jeder, dem du einem mail schickst, hat doch sowieso diese ganzen angaben zur verfügung - und dein rechner lebt ja offenbar immer noch, also warum jetzt diese paranoia?

Das hatte ich mir schon fast gedacht, das diese Angaben nicht wichtig sind. Da ich aber nicht wusste, ab wo Tom, bzw. ihr, die Header-Angaben braucht (dafür versteh ich leider noch zu wenig, was genau da drin steht, sonst hätte ich vermutlich dieses Problem überhaupt nicht), habe ich sie halt ausgetauscht. Zumal das halt die Firmendaten sind und ich ungern für irgendwelchen Schabernack verantwortlich sein möchte, der evtl. aus diesen Daten hervorgeht.

»[...]

gruß,
wahsaga

Liebe Grüße

Oliver

[Tom]

Hello,

... und wenn Du dir jetzt nochmal den Tipp von rob anschaust, dann müsstest Du feststellen können, welcher header da fehlt. Wenn Du dem Client nicht sagst, wie er encoden soll, dann nimmt der seinen default und der ist üblicherweise quoted-printable oder 7-bit (American ASCII)

Der angegebene und benutzte Typ muss aber mit dem für die Daten verwendeten übereinstimmen, dass ist doch logisch, oder ? ;-))

Liebe Grüße aus http://www.braunschweig.de

Tom

[Oliver_E]

Re Tom,

Der angegebene und benutzte Typ muss aber mit dem für die Daten verwendeten übereinstimmen, dass ist doch logisch, oder ? ;-))
Tom

demnach kannst du ja jetzt nur noch auf "Content-Transfer-Encoding: 8bit" angespielt haben oder ich seh den Wald vor lauter Bäumen nicht mehr. Wenn die E-Mail dann aber immer noch nicht sauber dargestellt wird, dann kommt irgendwas nicht mit dem "8bit" klar (wenn ein früheres Posting von dir berücksichtige) und mir bleibt dann nichts anderes übrig als den Text-String nach Quoted Printable umzustricken, oder?

Lieg ich soweit richtig?

Liebe Grüße

Oliver

[wahsaga]

hi,

Wenn die E-Mail dann aber immer noch nicht sauber dargestellt wird

hast du denn mal die möglichkeit, eine zweite test-email vom mailprogramm aus zu verschicken, die explizit mit 8-bit-codierung versehen ist?

dann könntest du ja mal schauen, wie darin umlaute und sonstige sonderzeichen übergeben werden, und mit deinr ausgabe vergleichen, ob's "stimmt".

gruß,
wahsaga

[Oliver_E]

Hi wahsaga,

hast du denn mal die möglichkeit, eine zweite test-email vom mailprogramm aus zu verschicken, die explizit mit 8-bit-codierung versehen ist?

Das sieht mir leider nicht danach aus. Ich habe zumindest diesbezüglich in Outlook keine entsprechenden Einstellungen gefunden, bis auf den Dateianhang (unbekannt, Mime, Uuencode und BinHex), aber das hat damit ja nichts zu tun.

Naja, ich werd jetzt erstmal Tom's ersten Vorschlag beherzigen und mich damit auseinandersetzen und wenn das auch nicht hilft, wird man hier halt mit den Kreuzworträtsel-Umlauten leben müssen.

gruß,
wahsaga

Ich danke euch auf jeden Fall ganz herzlich für eure Hilfe (dazugelernt habe ich ja auf jeden Fall schon mal was ;) )

Liebe Grüße

Oliver

[Tom]

Hello,

Naja, ich werd jetzt erstmal Tom's ersten Vorschlag beherzigen und mich damit auseinandersetzen und wenn das auch nicht hilft, wird man hier halt mit den Kreuzworträtsel-Umlauten leben müssen.

Das wird schon klappen.

Du musst doch nur vor dem Aufruf der Mail-Funktion den Header ergänzen:

http://de.php.net/manual/de/function.mail.php

$mail_ok = mail($to, $subject, $message , $headers ,$parameters);

die beiden letzen sind optional. Das bedeutet also, einfach den Tipp von rob einbauen:

$to = '[e-mail]';
  $subject = 'Testmail von Oliver';
  $message = "hier kommt der ganze Schwall rein\r\nund so weiter\r\nEnde";

$headers = "";
  $headers = "From: [e-mail]\r\n";

$headers .= ....  ### wat U nied

$headers .= "Content-Transfer-Encoding: 8bit\r\n";

$mail_ok = mail($to, $subject, $message , $headers);

Und das wars;

Und sonst kannst Du mir ja mal eine email schicken nach dem Muster:

Liebe Grüße aus http://www.braunschweig.de

Tom

[Oliver_E]

Re Tom,

Hello,

[...]

Du musst doch nur vor dem Aufruf der Mail-Funktion den Header ergänzen:

[...]

das sieht schon im großen und ganzen so aus, wie von dir beschrieben, lieber Tom. Das Auseinandersetzen bezog sich eher auf das "quoted printable" und das zusammenstricken einer diesbezüglichen Funktion (da werd ich erst noch was nachlesen müssen), aber, das wird schon ;) ... wenn nicht, komme ich gern auf dein Angebot zurück.

Nur was mir immer noch nicht in dem Kopf will, ist, warum die Umlaute, die ich aus den Formularfeldern in die $_SESSION Variablen schreiben lasse, warum die in dem gleichen Text-String, in der gleichen Email, so dargestellt werden, wie sie sollen.

Liebe Grüße aus http://www.braunschweig.de

Tom

Liebe Grüße, einen schönen Feierabend und auf ein erfolgreiches Fussballspiel heute abend ;)

Oliver

[Tom]

Hello,

Nur was mir immer noch nicht in dem Kopf will, ist, warum die Umlaute, die ich aus den Formularfeldern in die $_SESSION Variablen schreiben lasse, warum die in dem gleichen Text-String, in der gleichen Email, so dargestellt werden, wie sie sollen.

Da komme ich jetzt nicht mit. Woher kommen denn die Daten? Die kommen doch aus einem Formular, oder? Und welchen EncType hat das? Das funktioniert nämlich bei manchen Browsern im Zusammenspiel mit PHP auch nicht, wenn man nicht "multipart/form-data" benutzt. Das Dokument des Formulars muss natürlich auch den passenden Typ verwenden.

Liebe Grüße aus http://www.braunschweig.de

Tom

[Oliver_E]

Wb Tom,

Da komme ich jetzt nicht mit. [...]

das habe ich mir schon fast gedacht, als ich den Satz geschrieben habe ;) ...

Also, auf der Formular-Seite, gibt es Felder, in denen du deinen Namen, Vornamen, Email-Adresse (input type=text), sowie die dazugehörige Anrede (input type=radio) eingeben sollst. Dann gibt es noch eine optionale Liste, wo du eine Stadtauswahl treffen kannst. Soweit inhaltlich. Der Enctype ist multipart/formdata und wird per method=post an das Verarbeitungsskript übergeben.

Das Verarbeitungsskript setzt nun nach dem Session-Aufruf die übergebenen Variablen in das $_SESSION - Array

Bsp:

$_SESSION["name"] = $name;
$_SESSION["vorname"] = $vorname;
etc...

nach diesem Vorgang, 'bastel' ich mir jetzt den mailbody-string zusammen mit den dynamischen Daten aus dem Formular, die mir ja jetzt im $_SESSION Array zur Verfügung stehen. (Session verwende ich deswegen, weil die gemachten Daten noch 5 Tage erhalten bleiben sollen).

Bsp:

$koerper = "Bitte überprüfen Sie folgende Angaben:\n\n";
$koerper .= "Name: " . $_SESSION["name"] . "\n";
$koerper .= "Vorname: " . $_SESSION["vorname"] . "\n";
etc...

anschließend noch den Betreff in eine Variable abgelegt und weiter gehts zur mail-versenden-Funktion.

function mail_versenden($betreff, $koerper)
    {
        ... // Verknuepfung um eine saubere Anrede zu haben.
        $absender = "[e-mail]";
        $headers = wie schon weiter oben beschrieben
        if(!(mail($_SESSION["email"], $betreff, $koerper, $headers)))
             {
                die("Da hat was nicht funktioniert");
             }
    }

dann noch der Funktions-Aufruf:

mail_versenden($betreff, $koerper);

und das wars.

So, und wenn jetzt beispielsweise in $_SESSION["name"] "M_ü_ller-L_ü_denscheid steht, dann steht in der E-mail die ich erhalte "M_ü_ller-L_ü_denscheid", hingegen werden die Umlaute (s. 1. Beispielzeile aus $koerper) als irgendwelche Sonderzeichen dargestellt.

Und das ist das, was ich zur Zeit so gar nicht nachvollziehen kann. Denn eigentlich sollte ich doch annehmen müssen/sollen, das entweder alle Umlaute als Sonderzeichen oder aber korrekt dargestellt werden. Oder mach ich jetzt nen ganz bösen Denkfehler?

Liebe Grüße aus http://www.braunschweig.de

Tom

Liebe Grüße

Oliver

[Tom]

Hello,

[...] Soweit inhaltlich. Der Enctype ist multipart/formdata und wird per method=post an das Verarbeitungsskript übergeben.

der enctype heißt "multipart/form-data"

Das Verarbeitungsskript setzt nun nach dem Session-Aufruf die übergebenen Variablen in das $_SESSION - Array

Bsp:

$_SESSION["name"] = $name;
$_SESSION["vorname"] = $vorname;

$_SESSION['name'] = $_POST['name'];
$_SESSION['vorname'] = $_POST['vorname'];

etc...

$koerper = "Bitte überprüfen Sie folgende ärgerliche Angaben:\n\n";

da sind doch schon Umlaute. Was paasiert denn mit denen?

$koerper .= "Name: " . $_SESSION['name'] . "\n";
 $koerper .= "Vorname: " . $_SESSION['vorname'] . "\n";

etc...

function mail_versenden($betreff, $koerper)
    {
        ... // Verknuepfung um eine saubere Anrede zu haben.
        $absender = "[e-mail]";

wo bleibt denn $absender?

$headers = wie schon weiter oben beschrieben
        if(!(mail($_SESSION["email"], $betreff, $koerper, $headers)))
             {
                die("Da hat was nicht funktioniert");
             }
    }

dann noch der Funktions-Aufruf:

mail_versenden($betreff, $koerper);

und das wars.

So, und wenn jetzt beispielsweise in $_SESSION["name"] "M_ü_ller-L_ü_denscheid steht, dann steht in der E-mail die ich erhalte "M_ü_ller-L_ü_denscheid", hingegen werden die Umlaute (s. 1. Beispielzeile aus $koerper) als irgendwelche Sonderzeichen dargestellt.

Und das ist das, was ich zur Zeit so gar nicht nachvollziehen kann. Denn eigentlich sollte ich doch annehmen müssen/sollen, das entweder alle Umlaute als Sonderzeichen oder aber korrekt dargestellt werden. Oder mach ich jetzt nen ganz bösen Denkfehler?

Dann frage ich jetzt mal, welchen Editor Du benutzt und welchen Zeichensatz Du zum Abspeichern benutzt?

Nimm mal textpad und speicher das als Ansi und UNIX (falls im Einsatz) ab.
Das ist ein Problem von Deinem dämlichen Editor. Der erstzt automatisch.

Liebe Grüße aus http://www.braunschweig.de

Tom

[Oliver_E]

Moin,

Hello,

der enctype heißt "multipart/form-data"

ja natürlich, sry.

$_SESSION['name'] = $_POST['name'];
$_SESSION['vorname'] = $_POST['vorname'];

auch das sieht mir sauberer aus, werd ich noch abändern.

$koerper = "Bitte überprüfen Sie folgende ärgerliche Angaben:\n\n";

da sind doch schon Umlaute. Was passiert denn mit denen?

eben jene wurden//werden als Sonderzeichen dargestellt.

wo bleibt denn $absender?

$headers = wie schon weiter oben beschrieben

steht in  $headers = "From: " . $absender ."\r\n";

Dann frage ich jetzt mal, welchen Editor Du benutzt und welchen Zeichensatz Du zum Abspeichern benutzt?

bbedit 5.0 mac-version

Nimm mal textpad und speicher das als Ansi und UNIX (falls im Einsatz) ab.
Das ist ein Problem von Deinem dämlichen Editor. Der erstzt automatisch.

Sowas in der Art glaub ich nach einer Nacht drüber schlafen mittlerweile auch.

Liebe Grüße aus http://www.braunschweig.de

Tom

Liebe Grüße

Oliver

[Tom]

Hello,

$_SESSION['name'] = $_POST['name'];
$_SESSION['vorname'] = $_POST['vorname'];

auch das sieht mir sauberer aus, werd ich noch abändern.

Hier nur doppelte Häkchen benutzen, wenn der String noch ersetzt werden muss...

$koerper = "Bitte überprüfen Sie folgende ärgerliche Angaben:\n\n";

da sind doch schon Umlaute. Was passiert denn mit denen?

eben jene wurden//werden als Sonderzeichen dargestellt.

Nimm mal textpad und speicher das als Ansi und UNIX (falls im Einsatz) ab.
Das ist ein Problem von Deinem dämlichen Editor. Der erstzt automatisch.

Sowas in der Art glaub ich nach einer Nacht drüber schlafen mittlerweile auch.

Das ist eben WYSINWYG-Editor. Mach doch mal einen hexdump von der resultierenden Datei. Dann weißt Du Becheid. Aber wahrscheinlich kann man das an dem Editor auch einstellen. Sonst wäre der Entwickler doof.

Liebe Grüße aus http://www.braunschweig.de

Tom

[Oliver_E]

Moin,

Das ist eben WYSINWYG-Editor. Mach doch mal einen hexdump von der resultierenden Datei. Dann weißt Du Becheid. Aber wahrscheinlich kann man das an dem Editor auch einstellen. Sonst wäre der Entwickler doof.

also, ich hab das ganze skript noch mal neu in nem schlichten Text-Editor nachgebaut, hochgeladen und getestet. Brachte nichts.

Der Hex-Dump sah mir eigentlich sauber aus, sofern ich das beurteilen kann.

Dann hab ich heute nochmal in den RFC's (2045 + 1652) gestöbert, irgendwie bin ich der Meinung das da noch immer was bei den Headern nicht stimmt bzw. fehlt.

Was ich gerne noch probiert hätte, wäre die Möglichkeit "body-value ::= 8BITMIME", wie in

http://www.faqs.org/rfcs/rfc1652.html

beschrieben, allerdings werde ich nicht schlau draus, wie ich den header mit der dort angegeben Syntax zusammenbauen muss.

Liebe Grüße aus http://www.braunschweig.de

Tom

Liebe Grüße

Oliver

[Tom]

Hello,

das gibts nicht!

Schick mir doch biite das Script (zumidest den relevanten Teil) mal per eMail.

Liebe Grüße aus http://www.braunschweig.de

Tom

[Oliver_E]

Moin Tom,

halt dich fest, ich habs endlich gefunden worans lag ;)))

Es lag an der _Zeilenlänge_, die war bis eben vereinzelnd noch über 76 !! Zeichen. Nachdem ich das geändert hatte, läuft es einwandfrei. Die Header natürlich so übernommen, wie "rob" es oben vorgeschlagen hat.

Nochmals vielen lieben Dank für deine Ausdauer und dein Engagement!!

das gibts nicht!

Schick mir doch biite das Script (zumidest den relevanten Teil) mal per eMail.

Liebe Grüße aus http://www.braunschweig.de

Tom

Liebe Grüße

Oliver

[Tom]

Hello,

halt dich fest, ich habs endlich gefunden worans lag ;)))

Es lag an der _Zeilenlänge_, die war bis eben vereinzelnd noch über 76 !! Zeichen. Nachdem ich das geändert hatte, läuft es einwandfrei. Die Header natürlich so übernommen, wie "rob" es oben vorgeschlagen hat.

Vielen Dank für die Rückmeldung. Nun bin ich aber wirklich erstaunt, denn die zulässige Zeilenlänge für das DDDATA-Segment einer plain/text Mail ist definitiv 998 exclusive Zeilenendezeichen. Das haben wir schon mal irgendwann in mühevoller Kleinarbeit aus RFC 2822 rausgesucht. Die Empfehlung, bei 78 + CRLF umzubrechen, bleibt davon unberührt.

Nur für codierte Bereiche gibt es andere Vorgaben. Bei base64 z.B. darf man diese 76 (oder 78, das kann ich mir nie merken) nicht überschreiten.

Liebe Grüße aus http://www.braunschweig.de

Tom

[Oliver_E]

Moin,

Hello,

Vielen Dank für die Rückmeldung.

naja, is ja wohl das mindeste was ich tun konnte. Alles weitere werden jetzt noch zusätzliche Tests ergeben. Falls sich noch was drastisches Ergeben sollte, werde ich mich melden.

Liebe Grüße aus http://www.braunschweig.de

Tom

Liebe Grüße

Oliver

P.s. 76 Zeichen ;)