Mail mit Anhang generieren: Nur Anhang wird angezeigt (Thunderb)

[Hameeelh]

hi,
ich arbeite gerade an einem Projekt, in dem Administratoren Emails mit und ohne Anhängen versenden können. Soweit so gut, nur habe ich das Problem, dass zumindest in Thunderbird ausschließlich der Anhang anzeigt wird bzw. der Text wird verschluckt. Bei E-Mails ohne Anhang ist das leere E-Mail natürlich besonders "g'schmackig". Ich habe den Quellcode mit dem einer von Thunderbird selbst generierten (richtig dargestellten) Nachricht mit Anhang verglichen und mir ist kein Unterschied aufgefallen. NASA, hier ist der Code:

[START]
Return-Path: [e-mail]
X-Sieve: CMU Sieve 2.3
To: Newsletter:;
Subject: Design-Newsletter für Profidesigner
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=5caa52eb6bad56b23732bcf57339321b
From: XYZ@design [e-mail]
Date: Tue, 26 Oct 2010 19:36:37 +0200

This is a multi-part message in MIME format.
--5caa52eb6bad56b23732bcf57339321b
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Bitte beantworten Sie diese E-Mail nicht, sondern setzten Sie sich bitte mit dem Autor in Verbindung: John James [e-mail]

--5caa52eb6bad56b23732bcf57339321b
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Text

--5caa52eb6bad56b23732bcf57339321b
Content-Type: image/jpeg; name="Beispiel-Fadentechnik.jpg"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Hintergrund2-Vorlage.jpg"

/9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAUDBAQEAwUEBAQFBQUGBwwIBwcHBw8LCwkMEQ8SEhEP
ERETFhwXExQaFRERGCEYGh0dHx8fExciJCIeJBweHx7/2wBDAQUFBQcGBw4ICA4eFBEUHh4eHh4e
Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh7/wgARCAMABAADASIA
AhEBAxEB/8QAHAAAAwEBAQEBAQAAAAAAAAAAAAECAwQFBgcI/8QAGAEBAQEBAQAAAAAAAAAAAAAA
AAECAwT/2gAMAwEAAhADEAAAAfyk1mMy0sgQDomr1OR7C4vcMH00ca7ucwNZMxpBIGQjQzE0Mg1M
CiSQuBWJiGSplkK3Gek2NjtAayrUgylRSCjqrlVKJKJINs0ihlw9DKm4KLFPs9tvy2dx3xNZ1jWh
NzRU3NPSNCnVLlOswdPGzqwp1zLqaci2quStutPHy7OaMZ2lMlaDPSA1yQqEQtEQtJJVKSW9bMGU
0AyaSymblBDRgCY4o6OeWoFm1U33ZFyTrOgdEEetlyelb5+e8Eq5TCNsyGapk0Dc6E9fNudEyjWX
C58/bkcOfTjBjpCwtszNUiJuzF0kcUEHTy2IakSdJm2DcsQ3LAFly2I6MSbRSGomldQ6SEUyLA2v
Bmqza1tGsaxvnm4JztNyDltc1cIJhLYVLoatKi1AMGk1GMGXZLYJVRDHKk1JDcxIxAGCtQOXK5c4
vTFHdmtCsrKjTTNrfpcPUTiSMFY4tEVImC0zHrGgqWpQ0VNUBh0HFz93MuMaRETeZM6IzpixQyRy
kFWmCpJLpElMh0yDbKSWFNgTQzbJlSqCKYku2ZFsgoGnUs2Nd3l0y6RppHnxvjpNBUqkGfVzIm6M
3TIqmCYqGAMFSC5GNrWoqSLmpAYSCzVeZHbw9fKksUminVc6RkJ6TVqn2kK5th2oWpovSipMWpqm
aWYlQSDM41SQ9oJ1nWnpDM1UlOCJQlxy3yMZ0CVehzzopYYiCkkzpUc7sszdiQW0hWqhWkluiOrn
YmA09zm1nprkTqJHoQtYWHfSclaDUOyDadM3SlJzxpFklxogCKYibZNNr9J85rlUNuM22TciNDEz
Qz0SIe6cy6MSSkCbJp1UHZzEK3EUqpK3LF1ot8zCXdSwWgE1HQkGkky0Jt1DoBUyC1EqgWnRymLa
qWxEMFciE2kmppaqUrAlASp1nl08oRJRkhqVMAVKa9FXfbGUdEW5bRZLpJNt1m1KXcllxQZlIVrp
zUq5SpFqSU7JuUl6ZMuo6Tzr1zJbodxot6TcMTlhaVLitM4UWzn1nzrj0r5uib1gStKVIsWsOjnl
zjRGa0EyNS3NapMjS0yWiqI1kgtJJTSLO6vMNIQbsRSWXUQlrJmayQWomna1nrCSMIKKkoSSggpC
GxOpIWpLCuRaxRtyao5l0wme+eLG8Z6NoKaUsJbIWkMRRmoYsjJXFGUTpOb7y2PTz5o6MbM280tT
rqPPrwTB2xNMnqw6UjDWl5tKsxuxaY8iXM09Z3MmSGemJWWmUDKXOtNDnWqXO1SwEmRoRmtUQdfP
WZpac5qGb0S4zsWYHRkmTpJL3zMabROtawPpvAMU7gz0azm5AYFlkSqEDErQlpJLqUhUhNg4Yohx
LHUvSSi0Zq5Mp1kmdJIGoBiuaBM1jM97xVWdrNkolgpSzO2WL9C6z9PKpc2RhtCK56rMs94rJ2Jj
ekquGW0mLEbcnvKvwSijypbVSc9OcVegNLcmSUm5BTclq+sAUeZHtZkwV3oEdpE0u09OiLi4NCJa
rBQLFvAW5q3gKwiBSAW1BovtratqIVcCjzagFSAVKlttOZtJanBEaFHkeJCFcAm/KJO3mdGtLifQ
KpTtJZBAxmKdDoRWh1PIotITivlEq1avg5yeVaKKGtq13KZatNkXdTJnBNdvdiz9uBz3E7yjIu4j
MhN53AqwvJW5CVrV9XEF9bCvrmJuavqyu+Su85GV5W4lW5WU8ZCDckoRTIjaoBNkPj6POR/hin9E
NS4T4HbXBMbIRFFKV2nLtlGIoxFOiKfEUWFFpRGoNHjSc2tC2uA1KrQBVpSpEaNLmE+eJ27eDtm3
Uj1zFh0KbM5jCUSidJ345ivTdSc9OenORKtWrVq1atEoFE6WmuTHUo5XBNmJVokJtOWwprUQ9yMD
yvpXr6KVSYkjUIAo4YkIYU2GJfTsXYIT4XKgiYwu8wJ2QvrJEcnJchHNIsXpkbzjYHaViJpzcZOy
d6cwSBkPhkFLsFbHBFpTrTisFzXLLEVRyM7roMO5MKESnpUTw/oiyekzRB0T2qijoBqaukUdAjZK
pUqTQqVKlS22qR0pUiFSpUqVKlSpVoeVEnQ6UNmh+EdQEaTnIuTnI8CdLQK6Zj4s7JaDgtyvcNGq
OKRybjuGgcm2VBGUIWrtMTWRpvaQLVvFTPDmGFwTmTBf7E8uXdcmzFNltbl96DXlNhXYiQjx2ISw
sLM9wTcyZy7TpT/jnKPFkYmROCaDqQE5v27AU6P7cOmvy2sc2U045R2d0yQ4mQfp/qw+HvOcydoK
oXNEQdpQX6HwiFSctqAVKlSqkAgEQo9l0qRC2otVKlSpUqQVLxspALHwJZmSRlhpEUa0pu3QEglO
JdxpWijoSE6ROciVfpCa6laJ0BQ8qHFe9Y+LDGtoWwESY6jxUzbGnPBQPi1upblaL/O9Fya5BwCf
NFUpjK7iD3LuORc4r7ltJXakRYv9YP8ArIjc4JhlcmWV2/LGIbKDWINag1UVtKrxI3a7KY6syGUp
7Zmpks0ZjzsoJufMo85+2PKBVRFdthT4U6IJzPG1bVtRajH4ELnIwuC7a2CtqDFtVIhbVtW1bVjS
V5aFkijE8k8dD+EJxZdazBbw1isahB4GMMVLAzfEkWJtXKKtEXXDuAH6eR8hLyW2HeJxB6TV67fv
wx8NEMUcq8DWTWPQ22kukI6mUE2IWWnFmrPDuOF7V4jITj64RcjPND7lNQg4+7R0+JnYye1mzn4E
hKRW+hqYY2W0/kk24ZOcsDVc4z8Eld06Lpw+J8knKloZSWlrtEEvQgrRR7GjJhk4fCQhrHDMkEHB
PzxLo+xUdZ2IQaGhZy/g8J3saH2F9CCSvgVS2WmPbZB0E26phD4nBXjX2NEIXwHjhkFLNs62PWFd
LonC5gyX/aMB4JfLhL4LnYlmLY0041By4EfjjJxIbLaaEjrQkQb9dLwR0oNLZOUiWUyCwJzQwZmu
SLC4nCGdSkLv3xeMcLfKbTqETtE6G2xzx8Wy2SbXEHbV/XChYJ1TJqREW2u4LW098ZBRJkd31w4q
LReDEcISUd6RBC3kR/QNPbXCHojGic8GMgqcKgRxvKDRJjSoZaIQgxriUyez0RfJ1BocIYaGiEJk
/BAo2336EiCXEEnK29qaIThIhBYTwThD4TaGnGivLsWat+RcvjAZFFihcTl01+gTicPXCYSsZHwi
DNrRj423ZjxDA6V5/fwT0j7O9DUsutMW0JGzeGuWXhqplDNNjZnl8M0D3lQZELg9FF6We45cDZMi
ccS8QrPgs3lvh34zzDyrLm/OIKNjTFVW7ZcxLjcYamfNO6i04zM+4AjLYKDt/wAbmJbUtgKKc7yB
1NoNTwzdn5lPkYVZfkj59oI/SY5KRtTjXEBxbLpuE1gKGylvUGtI9wDGNVmXRMwiwNKX9oEqb4Uq
QbRRdicXiEbBOYL8j0TKZYLQWGwqkGL3bJS0+o88eQ2MWZIytJTiO6/0lm9a7FcRaAGgaO5lGFgd
hxC1hDRdn31EkSigWv8AMqUQaHJ/5iKxTYahK0Tc09wtsCwtI5PUyEE7AcQWyyKFNQ1AF3Uc7Lh4
lARdZliCrZ1/mUuAc4i2fUMvV3wfLDB+FJ/ufSykCCK9k9M5Y3Isqa7gFsFYhgzEbhOSApejH9tl
Mc2axXEViJvwYZV36hIAYD+ZassuOEXvwp1FxiEJcuuJglLqIzk/Ev1Li31FqDi6m0vrcV7l+GMC
wC9rBLLoEafkisYahV7mBQbqLuLGXHU5i34vwvwk3QUb+L4uXLlwZcuIrdzm5cuV44hN1qANDBR3
GcDasaBLmPD4uX5uDNMcll5agmqT+Q6gpWukt/7LNBlxmGDszmXpTeoUUDA4HsuVBUWy/wCI8GbK
M1AWqTReWZjRbefFWTI7NzLGaGG2cM1XuCdkXrTFxDsSlX3LfoLyWVDfjcYEiegaba1oO4wa1MAZ
sr/wsr/wsBf62f8AUZ/xGNM/os//2Q==

--5caa52eb6bad56b23732bcf57339321b--

[ENDE]

Nun meine zwei Fragen:
1. Wie kann ich auch den Text anzeigen lassen, ohne dabei auf den Anhang zu verzichten?
2. Die Angabe des MIME-Typs der hoch geladenen Datei stammt ja vom Client. Trotzdem verzichten viele Beispiele auf Überprüfung, ob keine Injektionen eingebaut sind. Warum? Und falls ich doch eine Überprüfung verwenden sollte: Gibt es hierfür einen guten vorgefertigten RegEx/eine Funktion oder muss ich mir selbst einen passenden RegEx zur Überprüfung zurecht zimmern?
3. Verkraften eh alle E-Mail-Programme mehrere text/plain-Abschnitte oder sollte ich die zusammenlegen und eben mit irgendetwas anderem trennen. (Nein, auch mit 2 Abschnitten funktioniert das generierte Mail nicht ;-) )

Vielen Dank für alle Hinweise!
lg Hameeelh.

[Der Martin]

Hallo,

[...] nur habe ich das Problem, dass zumindest in Thunderbird ausschließlich der Anhang anzeigt wird bzw. der Text wird verschluckt.

nicht nachvollziehbar. Ich habe deinen beispielhaften Mail-Quellcode von

[START]

bis

[ENDE]

in eine Datei kopiert und sie test.eml genannt, und diese Datei mit T-Bird geöffnet. Ergebnis: Beide Plaintext-Teile wurden mir angezeigt - interessanterweise ohne die Trennlinie dazwischen, die T-Bird sonst üblicherweise einfügt. Der zweite Textteil ("Text") wird mir zusätzlich nochmal als Attachment angeboten. Konnte es leider nur mit T-Bird 1.5 unter Windows testen - die Versionen 2.0 und 3.0, die ich unter Linux zur Verfügung hätte, sind offensichtlich zu doof, eine Message-Datei zu öffnen.

Die JPEG-Datei sieht übrigens ziemlich kaputt aus. ;-)
Problematisch ist auch das 'ü' im Subject - das muss entsprechend codiert sein.

So long,
 Martin

[Tom]

Hello Martin,

Ich habe deinen beispielhaften Mail-Quellcode von

[START]

bis

[ENDE]

in eine Datei kopiert und sie test.eml genannt

Wie bist Du denn an die Datei herangekommen?
Ich vermute mal, dass Du sie einfach in der Browseranzeige markiert, kopiert und dann in deinen Dateieditor eingefügt hast.

Und deshalb vermute ich, dass der Browser bereits die "\n" in "\r\n" umgewandelt hatte.
Du müsstest den Versuch mit der Originaldatei von Hameeelh durchführen.
Auch das kaputte JPG deutet auf einen falschen Zeilenumbruch innerhalb des Base64-codierten Teiles hin.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Der Martin]

Hallo Tom,

Ich habe deinen beispielhaften Mail-Quellcode [...]
in eine Datei kopiert und sie test.eml genannt
Wie bist Du denn an die Datei herangekommen?
Ich vermute mal, dass Du sie einfach in der Browseranzeige markiert, kopiert und dann in deinen Dateieditor eingefügt hast.

genau so, ja.

Und deshalb vermute ich, dass der Browser bereits die "\n" in "\r\n" umgewandelt hatte.

Darauf hatte ich in der Tat nicht geachtet; ich meine aber, dass T-Bird \n und \r\n gleich behandelt. Aber ich werde das heute abend nochmal in beiden Varianten probieren; habe hier momentan nur stark eingeschränkte Möglichkeiten.

Auch das kaputte JPG deutet auf einen falschen Zeilenumbruch innerhalb des Base64-codierten Teiles hin.

Videbimus. Ich vermute eher, dass der OP die lange base64-Wurst nach ein paar Dutzend Zeilen abgebrochen hat.

So long,
 Martin

[Hameeelh]

Hallo Tom,

Ich habe deinen beispielhaften Mail-Quellcode [...]
in eine Datei kopiert und sie test.eml genannt
Wie bist Du denn an die Datei herangekommen?
Ich vermute mal, dass Du sie einfach in der Browseranzeige markiert, kopiert und dann in deinen Dateieditor eingefügt hast.

genau so, ja.

Und deshalb vermute ich, dass der Browser bereits die "\n" in "\r\n" umgewandelt hatte.

Darauf hatte ich in der Tat nicht geachtet; ich meine aber, dass T-Bird \n und \r\n gleich behandelt. Aber ich werde das heute abend nochmal in beiden Varianten probieren; habe hier momentan nur stark eingeschränkte Möglichkeiten.

Ich habe diverse Tutorials gesehen und alle arbeiten mit \n; daran dürfte es also nicht liegen. Auf jeden Fall die Datei hochgeladen und an diesen Beitrag angehängt, wie Sie mir Thunderbird geliefert hat.

Auch das kaputte JPG deutet auf einen falschen Zeilenumbruch innerhalb des Base64-codierten Teiles hin.

Videbimus. Ich vermute eher, dass der OP die lange base64-Wurst nach ein paar Dutzend Zeilen abgebrochen hat.

Das JPG ist nicht kaputt. Im Gegenteil: Der Anhang ist ja das einzige, was zuverlässig funktioniert. Ich habe nur einen Ausschnitt aus der JPG-Datei, weil die ganze Datei den Rahmen eines SELFHTML-Betrags gesprengt hätte (Zeichenbeschränkung, Urheberrecht ;-) ).

lg Hameeelh.

PS: Anscheinend ist die Lösung der Frage 1 noch nicht ganz gefunden; hat jemand eine Idee in puncto 2 und 3? Danke!

[Tom]

Hello,

Hallo Tom,

Ich habe diverse Tutorials gesehen und alle arbeiten mit \n; daran dürfte es also nicht liegen.

Dann sind die alle falsch oder zumindest unvollständig.
Das kann man hier inzwischen auch mindestens einmal die Woche ausführlich erklären, wie der ganze Apparat arbeitet, es machen hinterher trotzdem wieder die Meisten falsch.

In der maildatei selber haben nur CRLF als Zeilenümbrüche von Headern und Blockabschnitten zu stehen. Das regeln die RFC2822 ff. Nur innerhalb codierter Blöcke kannst Du machen, was Du willst. Die werden auch nicht vom SMTP-Server interpretiert.

Wie diese CRLF nun in die Datei hinein gelangen und wer sie überhaupt endgültig erstellt, das ist eine längere Geschichte.

Du solltest im Script für die Zeilenumbrüche von am besten immer die PHP-Konstante PHP_EOL dafür benutzen.

Wenn Du die aktiven Threads aufmerksam durchgehst, müsstest Du eigentlich noch einen finden, der nahezu dasselbe Thema behandelt hat.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Hameeelh]

hi,

Du solltest im Script für die Zeilenumbrüche von am besten immer die PHP-Konstante PHP_EOL dafür benutzen.

Vielen Dank für deinen Hinweis! Leider: Kein Effekt. Der gleiche Fehler wie vorhin: Anhang angezeigt, rest verloren.

Nun noch etwas interessantes: Anscheinend (so spricht Notepad++ [mit seinen netten Lehrzeichenpünktchen]) haben sich bei meinen generierten (fehlerhaften) Emails vor dem Umbruch (egal ob LF oder CR+LF) manchmal Leerzeichen (U+0020) eingeschlichen, obwohl mein PHP-Code eh so aussieht - vielleicht bin ich blind, aber von einem Lehrzeichen sehe ich hier nix und das ist Originalcode.

Quellcode: $Abschnitt = PHP_EOL.'Content-Type: text/plain; charset=utf-8; format=flowed'.PHP_EOL.'Content-Transfer-Encoding: 8bit'.PHP_EOL.PHP_EOL.$Inhalt.PHP_EOL;
Funktionstüchtige Datei: http://www.file-upload.net/download-2923794/Nachricht3.eml.html
Datei mit seltsamen Abständen: http://www.file-upload.net/download-2923795/Nachricht4.eml.html

Und hier noch einmal meine Fragen:
1. Wie kann ich auch den Text anzeigen lassen, ohne dabei auf den Anhang zu verzichten?
2. Die Angabe des MIME-Typs der hoch geladenen Datei stammt ja vom Client. Trotzdem verzichten viele Beispiele auf Überprüfung, ob keine Injektionen eingebaut sind. Warum? Und falls ich doch eine Überprüfung verwenden sollte: Gibt es hierfür einen guten vorgefertigten RegEx/eine Funktion oder muss ich mir selbst einen passenden RegEx zur Überprüfung zurecht zimmern?
3. [HAT SICH ERLEDIGT]

lg Hameeelh

PS: Ja, ich probiere mit den Uploaddiensten noch herum ;-)

[Der Martin]

Hallo,

Vielen Dank für deinen Hinweis! Leider: Kein Effekt. Der gleiche Fehler wie vorhin: Anhang angezeigt, rest verloren.

das deckt sich mit meinem Test, den ich heute vormittag angekündigt und eben durchgeführt habe. Ob die Zeilenumbrüche nur mit LF oder mit CR+LF realisiert sind, stört den T-Bird nicht die Bohne.

Nun noch etwas interessantes: Anscheinend (so spricht Notepad++ [mit seinen netten Lehrzeichenpünktchen]) haben sich bei meinen generierten (fehlerhaften) Emails vor dem Umbruch (egal ob LF oder CR+LF) manchmal Leerzeichen (U+0020) eingeschlichen, obwohl mein PHP-Code eh so aussieht - vielleicht bin ich blind, aber von einem Lehrzeichen sehe ich hier nix und das ist Originalcode.

Überschüssige Blanks am Zeilenende sind nicht weiter schlimm - aber der Standard erfordert, dass an manchen Stellen LEERE Zeilen stehen, beispielsweise um Header vom Content zu trennen (auch Sub-Header von ihrem zugehörigen Content-Block). Eine Zeile, die ein paar Blanks enthält, ist aber keine Leerzeile!

Funktionstüchtige Datei: http://www.file-upload.net/download-2923794/Nachricht3.eml.html
Datei mit seltsamen Abständen: http://www.file-upload.net/download-2923795/Nachricht4.eml.html

Ausschnitt aus deiner Nachricht4.eml ab Zeile 10:

This is a multi-part message in MIME format.
--5caa52eb6bad56b23732bcf57339321b
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
______
ssssdddddd
________
--5caa52eb6bad56b23732bcf57339321b
Content-Type: image/jpeg; name="Hintergrund2-Vorlage.jpg"
Content-Transfer-Encoding: base64

Die Unterstriche habe ich zur Verdeutlichung genommen, an ihrer Stelle stehen in deiner Original-Message Blanks. Hier ist vollkommen klar, dass der Textteil "unterschlagen" wird. Die Leerzeile, die ihn eigentlich von seinen Headern trennen sollte, fehlt. Daher werden alle Zeilen bis zur ersten Leerzeile als (teils unsinnige) Headerzeilen interpretiert. Der JPEG-Anhang ist damit tatsächlich der erste Block der Nachricht (und der einzige).

Und hier noch einmal meine Fragen:

1. Wie kann ich auch den Text anzeigen lassen, ohne dabei auf den Anhang zu verzichten?

Ist damit hoffentlich auch geklärt.

2. Die Angabe des MIME-Typs der hoch geladenen Datei stammt ja vom Client. Trotzdem verzichten viele Beispiele auf Überprüfung, ob keine Injektionen eingebaut sind. Warum? Und falls ich doch eine Überprüfung verwenden sollte: Gibt es hierfür einen guten vorgefertigten RegEx/eine Funktion oder muss ich mir selbst einen passenden RegEx zur Überprüfung zurecht zimmern?

Wovon willst du denn den MIME-Type ableiten? Die Datei-Extension ist ein unzuverlässiges Merkmal, aber vermutlich das einzige, das dir zur Verfügung steht. Also nimm eine Zuordnungsliste mit ein paar Extensions und den "dazugehörigen" MIME-Types.

PS: Ja, ich probiere mit den Uploaddiensten noch herum ;-)

Das muss ich jetzt nicht verstehen, oder?

Ciao,
 Martin

[Hameeelh]

Hallo,

Vielen Dank für deinen Hinweis! Leider: Kein Effekt. Der gleiche Fehler wie vorhin: Anhang angezeigt, rest verloren.

das deckt sich mit meinem Test, den ich heute vormittag angekündigt und eben durchgeführt habe. Ob die Zeilenumbrüche nur mit LF oder mit CR+LF realisiert sind, stört den T-Bird nicht die Bohne.

Nun noch etwas interessantes: Anscheinend (so spricht Notepad++ [mit seinen netten Lehrzeichenpünktchen]) haben sich bei meinen generierten (fehlerhaften) Emails vor dem Umbruch (egal ob LF oder CR+LF) manchmal Leerzeichen (U+0020) eingeschlichen, obwohl mein PHP-Code eh so aussieht - vielleicht bin ich blind, aber von einem Lehrzeichen sehe ich hier nix und das ist Originalcode.

Überschüssige Blanks am Zeilenende sind nicht weiter schlimm - aber der Standard erfordert, dass an manchen Stellen LEERE Zeilen stehen, beispielsweise um Header vom Content zu trennen (auch Sub-Header von ihrem zugehörigen Content-Block). Eine Zeile, die ein paar Blanks enthält, ist aber keine Leerzeile!

Ja, das ist mir klar. Nur: Woher kommen diese Leerzeichen, wenn ich doch folgenden Code verwende, der an KEINEM Zeilenende irgendwelche Leerzeichen schreibt :ratlosigsein: $Abschnitt = PHP_EOL.'Content-Type: text/plain; charset=utf-8; format=flowed'.PHP_EOL.'Content-Transfer-Encoding: 8bit'.PHP_EOL.PHP_EOL.$Inhalt.PHP_EOL;

Wovon willst du denn den MIME-Type ableiten?

Aus $_FILES['thefile']['type'] will ich sie nicht nur ableiten, sondern dort steht er. Die Frage ist nur: Könnte dort auch stehen: "text/html[EOL][irgendeine Injektion]". Also: Ist es auch möglich, Injektionen statt einem (korrekten) MIME-Typ zu übergeben? Hat PHP schon überprüft, ob es sich beim "type"-Element überhaupt um einen MIME-Typ handelt (keine Injektion) oder muss ich das (via RegEx) selbst prüfen.

Das muss ich jetzt nicht verstehen, oder?

Nein ;-)

Auf jeden Fall Danke!
lg Hameeelh.

[Tom]

Hello,

Wovon willst du denn den MIME-Type ableiten?
Aus $_FILES['thefile']['type'] will ich sie nicht nur ableiten, sondern dort steht er.

Nein, dort steht ggf. auch "scheisse"
Diese Angabe sendet der Client mit und der lügt ziemlich oft.

Aber auf einem Linux-System kannst Du das Kommando 'file' benutzen und solange es das in PHP noch gibt, die Funktion mime_content_type()
http://de.php.net/manual/de/function.mime-content-type.php

Und außerdem musst Du beim Upload von Files darauf achten, dass nicht ausführbare Scripte in einem Verzeichnis auftauchen, das per HTTP erreichbar ist und das geparst wird.

Besser ist es immer, nur spezielle Endungen und MimeTypes zuzulassen, wobei für die Sicherheit tatsächlich ersteres wichtiger ist!

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg