Hi,
Der Versuch von Fastüx ist irrelevant, da er nicht vorhersehen kann kann, ob immer alle SMTP-Relays mitspielen. Dafür muss man sich an die gültigen Konventionen (RFCs) halten, ggf. auch an ältere. Man weiß ja nicht immer, welchen Weg die Email nimmt.
Was macht Dich so sicher?
Die Frage müsste lauten: warum ist das noch so unsicher?
Du hast die Testbedingungen noch nicht genannt. Lass uns das jetzt also bitte gemeinsam zu Ende denken/testen :-)
- Basissystem: Linux (?)
- Prüfstelle für den Output von von mb_send_mail(), reingucken kannst Du ja nicht. Hast Du das sendmail-Script (?) verbogen? Das wäre eine Möglichkeit, die generierte Maildatei anzusehen. Anstelle von sendmail ein Script einbinden, dass die Maildatei erst einmal speichert, anstatt sie an den SMTP-Service zu übergeben.
- Als Transfer-Encoding base64 zu benutzen, halte ich unter den gegebenen Umständen am bequemsten, hatte das auch gehofft, dass es so ist. Dass Du das ermittelt hattest, war mir bisher leider nicht aufgefallen.
- Die Array-Variante für die Header austesten, welche Umbrüche werden da produziert? Welche werden bei der Stringwurst-Variante richtig umgesetzt von mb_send_mail()? Das Handbuch ist an dieser Stelle vermutlich falsch.
- Wie kann man einen multipart-mixed Body produzieren?
- Müssen die Header noch vorher MIME-codiert werden, oder stimmt es, dass
mb_send_mail() sich selber darum kümmert?
- Was passiert auf Windows-Systemen?
Ich komme leider erst am Montag, 15. Jun wieder an meinen Linux-PC. Der steht in der Firma. Es wäre also nett, wenn Du das praktisch testen könntest. Und dann sollten wir versuchen, eine kleine Doku fürs Wiki darüber zu verfassen, in mehreren (3?) Anforderungsgraden. Dabei ginge es ums Verständnis, nicht ums Vermeiden vom Swift-Mailer o.ä. Wo liegen die Injection-Schwachstellen, was muss man noch beachten, usw.? Was bedeutet "Content-Type", was "Content-Transfer-Encoding", Was ist eine Multipart-MIME-Mail, usw.
Ich hab mir jetzt das mail mal angesehen.
Also mb_send_mail() produziert, da es ja UTF-8 verschickt, ein Mail, dessen Body wie folgt transportiert wird:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: BASE64
Mithin also genau so, wie binären Kram.
Man könnte also damit jetzt jede Datei versenden, auch Bilder... Da wäre dann nur der Content-Type-Header falsch. Wird der Default-Header überschrieben, wenn man den explizit setzt?
Und da in BASE64 die originalen Zeilenumbrüche ebenfalls kodiert werden, nimmt mb_send_mail() die Gelegenheit beim Schopf und bricht das BASE64-Zeug nach 76 Zeichen um, der Zeilnumbruch ist "\n". (Auch beim Shell-Programm base64 passiert genau das per Voreinstellung!)
Mich persönlich würde noch interessieren, woher die 76 kommt (also 78 incl. CRLF)? Die RFCs sprechen imho immer von 80 Bytes incl. CRLF!?
Meine Aussage war, dass ich mit mb_send_mail() kein wordwrap() benötige. Meine zweite Aussage war, dass ein Mail mit einer superlangen Zeile im Body ankommt. Nichts gesagt habe ich über den Transfer, aber eigentlich war das - wg. URF-8 absehbar…
Na eben :-)
Ich hatte jetzt der Vorsicht halber angenommen, dass Du die Datei nach dem Transport angeschaut hast, nachdem sie auch sendmail und die Kette der SMTP-Hops durchlaufen hat. Die ist aber höchst unbestimmt.
Dazu müsste man jetzt noch wissen, welche Mailserver involviert waren, Typ und Version. Dass Content mit base64-Encoding richtig durchläuft, wäre heutzutage aber zu erwarten.
Viele Fragen, lass es uns fertig machen!
Das würde dann das Antworten auf die Fragen dieses OP und die des @Linuchs in Zukunft vereinfachen. Und auch meine unx deine klären :-)
LG
me-too
Kralle
Der Martin
Matthias Apsel
Rolf B
Julius
Tabellenkalk
MudGuard
