Mail-Header Kodierung

[TS]

Hello,

ich bin im Zweifel darüber, ob Mail-Header noch für 7-Bit-Wortlänge (Transfer-Encoding) kodiert werden müssen. Nach RFC 822 und RFC 2047 war das ja noch vorgeschrieben. Aber die sind heute wohl beide Überholt?

Ich habe inzwischen auch keinen SMTP-Server mehr gefunden, der noch auf 7-Bit Transfer-Encoding Wert legt, aber das hat ja nicht unbedingt etwas zu sagen.

Wer kann mir den Roten Faden wiederfinden helfen, was aktuell gültig ist?

Liebe Grüße
Tom S.

[TS]

Hello,

ich würde mich über etwas Unterstützung freuen!

Ich hatte versprochen, mich um einen neuen Artikel "wie baut man einen Formmailer" zu kümmern. Ich will also nicht noch_einen_Formmailer ins Netz schmeißen, sondern eher nach unserem Motto "Die Energie des Verstehens" zeigen, wie und warum man welche Maßnahmen ergreift. Nun ergibt sich langsam eine Struktur dafür. Leider fehlen mir an einigen Stellen (RFCs) die aktuellen Kenntnisse. Auch für die (späteren) Beispiele in OOP fehlen mir die Fachkenntnisse für Entwurfsmuster. Da würde ich selber gerne dazulernen.

Und ich kämpfe noch gewaltig gegen das Wiki. Ich weiß nicht, wie man welche Darstellungsart erzeugt.

Von unserem "Wiki-Workshop" beim Treffen hatte ich mir ein wenig mehr Benutzertraining erwartet. Das haben wir leider versäumt :-(

@Matthias Apsel: Und die PHP-Artikel sind deshalb ein "Friedhof des guten Willens", weil ich kein Alleinarbeiter bin - ich brauche den Dialog. Leider fehlt dieser!

Und andere versuchen es ja gar nicht erst, einen Artikel, wie z. B. File-Upload zu recherchieren und zusammenzutragen und dann auch am Leben zu halten (immer wieder neue Erkenntnisse nachzutragen). Es ist aber mMn der am häufigsten aufgerufene Artikel des gesamten Wikis. Schade, dass der Zugriffszähler nicht mehr geführt wird!

Ich würde ich auch gerne fertig™️ machen, was aber vermutlich nie möglich sein wird. Es gibt immer mindestens einen Trick/eine Lücke mehr, als man selber denkt :-O

Liebe Grüße
Tom S.

[dedlfix]

Tach!

Ich hatte versprochen, mich um einen neuen Artikel "wie baut man einen Formmailer" zu kümmern. Ich will also nicht noch_einen_Formmailer ins Netz schmeißen, sondern eher nach unserem Motto "Die Energie des Verstehens" zeigen, wie und warum man welche Maßnahmen ergreift.

Mach es nicht zu umfangreich. Die Sache mit dem Mailversand kannst du rauskürzen und stattdessen etwas fertiges nehmen, zum Beispiel den Swiftmailer. Wir haben da ja auch schon was. Versenden von Mails ist nichts Formmailer-spezifisches. Wenn es denn Details zum Mailversand sein sollen, dann lieber einen separaten Artikel erstellen.

Und ich kämpfe noch gewaltig gegen das Wiki. Ich weiß nicht, wie man welche Darstellungsart erzeugt.

Das kann man dann immer noch feinschleifen. Du kannst für Beispiele erstmal <pre></pre> nehmen, und die Beispiel-Vorlagen vorläufig ignorieren.

dedlfix.

[TS]

Hello,

Die Sache mit dem Mailversand kannst du rauskürzen und stattdessen etwas fertiges nehmen, zum Beispiel den Swiftmailer.

Dann müsste ich konsequenterweise reverse Engeneering betreiben und Kritik üben und würde an vielen Stellen mehr Unverständnis erzeugen, als Verständnis.

Liebe Grüße
Tom S.

[dedlfix]

Tach!

Die Sache mit dem Mailversand kannst du rauskürzen und stattdessen etwas fertiges nehmen, zum Beispiel den Swiftmailer.

Dann müsste ich konsequenterweise reverse Engeneering betreiben und Kritik üben und würde an vielen Stellen mehr Unverständnis erzeugen, als Verständnis.

Nicht unbedingt. Man macht doch auch nicht "konsequenterweise" Reverse Engeneering in die Programmiersprache, in das Betriebssystem, in den Prozessor, und so weiter bis in die Atomphysik hinein. Stattdessen hört man an einer geeigneten Grenze auf, was im Falle PHPs PHP selbst ist. Man schaut also üblicherweise nicht in die Implementationen der Funktionen und der Sprachelemente, sondern verwendet sie so, wie ihre Arbeitsweise im Handbuch beschrieben ist. Soviel Vertrauen muss sein, sonst kommt man vor lauter Verzetteln in Kleinkram nur schwer zum Ziel. Wenn man einen Verdacht hat, dass da irgendwas nicht stimmt, dann kann man - nachdem man seinen eigenen Code ausgeschlossen hat - immer noch abtauchen.

dedlfix.

[TS]

Hello,

Die Sache mit dem Mailversand kannst du rauskürzen und stattdessen etwas fertiges nehmen, zum Beispiel den Swiftmailer.

Dann müsste ich konsequenterweise reverse Engeneering betreiben und Kritik üben und würde an vielen Stellen mehr Unverständnis erzeugen, als Verständnis.

Nicht unbedingt. Man macht doch auch nicht "konsequenterweise" Reverse Engeneering in die Programmiersprache, [...]

Wenn man etwas Fertiges benutzt (hier eine PHP-Klasse oder Klassensammlung), um damit grundlegende Techniken der für die Klasse verwendeten Programmiersprache zu beschreiben, dann muss man die Klasse zumindest "aufmachen", um darin zeigen zu können, wie sie auf die Erfordernisse eingeht.

Dass man da nicht bis zum Befehlssatz des Prozessors durchgreift, sollte sich von alleine verstehen! Also rücke meine Aussagen bitte nicht in einen unzutreffenden Kontext :-)

Es geht nicht darum, wie der Switftmailer (oder sonst irgend einer) das macht, sondern wie man selber vorgehen könnte, um einen eigenen zu erstellen. Und dazu muss man sich zwangsweise erst einmal mit den Rahmenbedingungen (Vereinbarungen, Protokollen, Schnittstellen, ...) auseinandersetzen.

Liebe Grüße
Tom S.

[dedlfix]

Tach!

Es geht nicht darum, wie der Switftmailer (oder sonst irgend einer) das macht, sondern wie man selber vorgehen könnte, um einen eigenen zu erstellen. Und dazu muss man sich zwangsweise erst einmal mit den Rahmenbedingungen (Vereinbarungen, Protokollen, Schnittstellen, ...) auseinandersetzen.

Ein Formmailer übergibt die Daten wie Empfänger, Subjekt und Mailinhalt, die er aus den Formulardaten entnommen (und vorher fehlergeprüft) hat der Mail-Komponente und fertig ist seine Aufgabe. Um die ordnungsgemäße Abwicklung der Erstellung und des Versandes der Mail kümmert sich die Mailkomponente. Wie gesagt, Mailversand und dessen Feinheiten ist ein anderes Thema.

Es muss nicht unbedingt der Swiftmailer sein, nur wurde der mal hier vor Jahren ins Gespräch gebracht und ich habe mangels Notwendigkeit keinen Überblick über die am Markt verfügbaren Mailer-Komponenten.

dedlfix.

[pl]

Hello,

ich würde mich über etwas Unterstützung freuen!

Eine Diskussion daüber ob 8 bit in Mailheaders funktionieren erachte ich weder als unterstützend noch als sinnvoll.

Auch für die (späteren) Beispiele in OOP fehlen mir die Fachkenntnisse für Entwurfsmuster. Da würde ich selber gerne dazulernen.

Na das ist doch schon eher was. Ich hab mal ein Mailermodul für Perl geschrieben, das hat # Drei Module in Einem: SendMail, SendMail::Attach, SendMail::HTML und nutzt hierzu OOP/Vererbung. D.h., die Superklasse ist SendMail und die stellt den Konstruktor. Jede Klassenerweiterung definiert eine Methode sendmail(), somit ist die Anwendung immer gleich, bis auf die unterschiedlichen Möglichkeiten welche die Erweiterungen bieten, z.B. das Erstellen einer HTML Mail oder einer Mail mit Attachments, da wird also stets die Methode sendmail() aufgerufen, nur mit anderen Parametern halt.

Da es sehr viele Möglichkeiten gibt, Multipart-Mails zusammenzustellen, ist dieser Ansatz natürlich erweiterbar, für HTML Mails mit eingebauten Images wäre hier also eine neue Erweiterung zu schreiben welche die Methode senmail() entsprechend überschreibt.

Das ist die Idee, die ich hiermit mal weitergebe. Die Maildateien werden über eine Template-Engine erstellt. Du könntest mal recherchieren welchen Unterschied es macht, ob multipart/mixed oder multipart/alternative deklariert wird.

MfG

[TS]

Hello,

Eine Diskussion daüber ob 8 bit in Mailheaders funktionieren erachte ich weder als unterstützend noch als sinnvoll.

Ob "es funktioniert" geht es doch gar nicht!

Es geht darum, was der anerkannte Stand der Technik ist (gültige RFCs) und wieviel Durchdringung der bereits geschafft hat.

Ich kann doch nicht einfach irgendwelche Beobachtungen als allgemeingültige Tatsachen in den Raum stellen tztz

Liebe Grüße
Tom S.

[pl]

Hello,

Ich kann doch nicht einfach irgendwelche Beobachtungen als allgemeingültige Tatsachen in den Raum stellen tztz

Oh doch das können wir. Wäre ja noch schöner, wenn nicht. Um hier mal ein Beispiel zu geben: Der ganze MIME-Standard ist Schrott und gehört auf den Scheiterhaufen der Geschichte (und ja ich kann das auch begründen).

Mit freundlichen Grüßen 😉

[TS]

Hello,

Ich kann doch nicht einfach irgendwelche Beobachtungen als allgemeingültige Tatsachen in den Raum stellen tztz

Oh doch das können wir. Wäre ja noch schöner, wenn nicht. Um hier mal ein Beispiel zu geben: Der ganze MIME-Standard ist Schrott und gehört auf den Scheiterhaufen der Geschichte (und ja ich kann das auch begründen).

Dann tu's bitte!

Und wenn Du eigene Beobachtugnen zu sogenannten Standards hast, die deiner Meinung nach nicht mehr oder noch nie allgemeingültig waren, aber als solche dargestellt werden, dann übe bitte substantiierte Kritik! Aber dann bitte ausführlich und allgemeinverständlich!

Liebe Grüße
Tom S.

[pl]

Hello,

Ich kann doch nicht einfach irgendwelche Beobachtungen als allgemeingültige Tatsachen in den Raum stellen tztz

Oh doch das können wir. Wäre ja noch schöner, wenn nicht. Um hier mal ein Beispiel zu geben: Der ganze MIME-Standard ist Schrott und gehört auf den Scheiterhaufen der Geschichte (und ja ich kann das auch begründen).

Dann tu's bitte!

Mach ich doch seit Jahren auf meinem Blog. MfG

[TS]

Hello,

Dann tu's bitte!

Mach ich doch seit Jahren auf meinem Blog. MfG

Link?

Fehlt schon wieder!

Liebe Grüße
Tom S.

[pl]

Einer von.. und Forum

[Mitleser]

Einer von..

"Dieser Entwurf beschreibt einen möglichen zukünftigen Standard für die Übertragung von Hyper-Media-Dateien"

Hyper-Media-Dateien? WTF?! LOL

[pl]

Geht der Link zum Forum nicht?

[pl]

moin @TS ,

Und wenn Du eigene Beobachtugnen zu sogenannten Standards hast, die deiner Meinung nach nicht mehr oder noch nie allgemeingültig waren, aber als solche dargestellt werden, dann übe bitte substantiierte Kritik! Aber dann bitte ausführlich und allgemeinverständlich!

Vielleicht hast Du Dir meinen Vorschlag ja mal angeschaut. Anstelle von Mailheadern empfehle ich Schlüssel in einem assoziativen Array was zur Übertragung serialisiert wird. Die spannende Frage wäre hier nun, ob es möglich ist, in den Namen dieser Schlüssel Nicht-ASCII-Zeichen zu verwenden, genauso wie Du diese Frage bezüglich Mailheader stellst. Und die Antwort ist diese hier:

Ja, natürlich ist das möglich. So sind chinesische Schriftzeichen oder deutsche Umlaute in Mailheadern technisch genauso möglich wie in Schlüsseln für assoziative Arrays, aber wir sollten bedenken, daß es sich um internationale Abmachungen handelt, wo man einen gemeinsamen Nenner haben möchte. Somit ist das also keine technische Frage sondern eine Frage der sprachlichen Vereinbarung.

MfG

[TS]

Hello,

[...]

Das ist ja schön und gut, dass Du einen neuen Standard einführen willst. Aber das ändert nichts an meinem Vorhaben, den vorhandenen Klartext-Standard genauer vorstellen zu wollen in Bezug auf die Möglichkeiten, ihn mittels PHP und üblichem Mailserver zu benutzen.

Und meine Frage, ob Mailheader mehr Codepoints als printable-ASCII (n von 128, 7-Bit) enthalten dürfen, oder ob inzwischen ISO-8859-1 (n / 256, 8-Bit) benutzt werden darf, wird dadurch nicht beantwortet.

Es gibt reichlich ernstzunehmende Posts im Web, die zweiteres behaupten. Das habe ich auch beobachtet. Beobachtungen sind aber kein Beweis für eine gültige Übereinkunft, sondern nur ein Indiz.

Liebe Grüße
Tom S.