Es stimmt sicherlich, dass WebMailer und einige "proprietäre" Apps technisch/fachlich nicht ausgereift und durchdacht sind. Es fehlt auch die Transparenz, was sie im Hintergrund alles machen.
Aber es gibt eben starke Use Cases, sie zu verwenden, ergo würde ich das nicht per se verdammen.
Hint: Wenn sie technisch kaputt /sind/, *sind* sie technisch kaputt,
egal wie viele Leute sie verwenden.
Ein Problem ist sicherlich, dass sich die Clients alle anders verhalten (und das ganze intransparent ist).
Nicht, wenn du einen vernünftigen Client verwendest.
Meine WEB.DE Mobile App z.B. scheint auf eine E-Mail aus dem Forum mit der gleichen Codierung zu antworten, also "text/plain" und UTF-8. Genauso verhält sich z.B. auch Microsoft Outlook. Und diese E-Mails werden dann auch sauber im Forum "verarbeitet".
Also /mein/ Thunderbird macht ziemlich [tm] zuverlässig und relativ [tm]
nachvollziehbar mehr oder weniger [tm] genau das, was ich bei ihm
eingestellt habe. Q.E.D.
Die WEB.DE-WebMail (und ich vermute auch andere Produkte der United Interet AG wie 1&1 oder GMX) haben eine Einstellung "Design-Mail" (HTML) und "Text-Mail", die quasi persistent ist. D.h. auch eine E-Mail mit "text/plain" wird mit "text/html" beantwortet. Für mich ist das offen gesagt ein Riesen-Bullshit.
[dsf 9.1]
Das entspricht eigentlich nicht der normalen Erwartungshaltung. Und das habe ich bei WEB.DE bereits platziert. Und das ist auch nicht alles, was dort m.E. dilettantisch umgesetzt ist.
Und trotzdem darf man das angeblich nicht per se verdammen (behauptete
zumindest kürzlich irgend so ein <zensiert>) ... <meinjanur>
Jetzt noch etwas anderes, bei dem jemand sicherlich mehr weiß und weiterhelfen kann.
Prinzipiell ist eine HTML-Mail ja nichts Schlimmes. Untereinander (d.h. außerhalb des Forums und mit beliebigen Clients) kann man ja gut kommunizieren und das geschilderte Problem tritt nicht auf. Ob man BASE64 unbedingt braucht kann ich nicht sagen.
Man braucht es sicherlich nicht, wenn der Text eh schon in einer
MIME-Kodierung vorliegt, so wie das bei Stefan der Fall *ist*. Das wäre
ungefähr so, als würde man ein ZIP-File nur für den Transport nochmal
mit RAR komprimieren wollen; d. h. es /wäre/ nicht nur, es /ist/.
Aber es ist sicherlich nicht nur für Binärdaten sondern reduziert nur den "Zeichensatz" auf 64 Zeichen
Man *kann* es benutzen, wenn man es *anstelle* einer MIME-Kodierung o.
ä. benutzt. *Zusätzlich* *dazu* ist es *völliger* Unsinn.
Und wenn es noch dazu den Text so verstümmelt, wie hier geschehen, dann
ist es *weit* *mehr* als nur Unsinn. Sorry, aber da gibt es keine
Diskussion.
- das müsste man wahrscheinlich schon für UTF-8 und HTML machen. Wie gesagt - wenn es nötig wäre.
Das ganze "Problem" scheint ja nur mit den LibreOffice Mailing-Listen aufzutreten. Ich kann nur mutmaßen, dass eben dieser "Client" nicht vollumfänglich mit HTML umgehen kann.
Hmm; du warst aber nicht gestern Abend auf einer höchst
feucht-fröhlichen Faschingsssitzung, oder? Anders kann ich mir nicht
erklären, dass du hier allen Ernstes anzudeuten scheinst, dass die
ML-Software den Body der Emails in irgend einer Weise bearbeiten würde.
Oder der Codierung. Es würde ja nichts dagebensprechen, diese Mails
richtig zu "importieren", mit den entsprechenden Tools.
Nochmal ganz langsam zum mitdenken: Die Email von Stefan wurde so kaputt
bei mir eingeliefert, und das bedeutet, dass sie genau so kaputt von
seinem Provider in Umlauf gebracht wurde. Unterwegs wurden zwar zur
Dokumentation des Transportweges einige Header hinzu gefügt, aber am
Body selbst wurde garantiert nix mehr verändert.
Das soll jetzt keine "Schuldzuweisung" sein oder das Problem auf das Forum schieben. Man weiß ja nicht, was genau aus den Mail-Servern übertragen wird.
Doch, das weiß man sehr genau. Lies die einschlägigen RFCs.
Und ein HTML-Importfilter ist sicherlich nicht einfach, denn ich muss ja einen Teil von nicht mehr darstellbaren Zeichen und Objekten nach irgendwelchen Regeln substituieren oder wegwerfen.
Erstens wäre er sehr einfach, denn es müssten lediglich alle HTML-Tags
entfernt werden, und die erkennt man ganz einfach daran, dass sie mit
einem '<' beginnen und einem '>' enden.
Und zweitens dürfte er sogar so kaputt sein wie er möchte, denn Stefans
Text liegt gar nicht in HTML-Text vor, ein HTML-Filter würde also gar
nicht darauf angewendet werden.
Wenn sich aber jemand mit der Technik diese Forums gut auskennt könne man ja mal prüfen, ob man bestimmte Zeichen sauber "importieren" kann - ist vielleicht nur eine Konfiguration.
Drittens ist das hier kein Forum, sondern eine Mailingliste, viertens
hat das überhaupt nix mit der Technik einer ML o. ä. zu tun, sondern mit
Email-Formaten, und -Transportkonventionen, so wie sie in diversen RFCs
definiert sind, angefangen bei RFC 5321, RFC 5322, über RFC 4648 bis hin
zu den RFCs 2045-2049 u. v. m., und fünftens *gibt* es mit Sicherheit
mindestens eine Person (höchstwahrscheinlich sogar mehrere), die sich
damit aus *kennt*. [dsf 3.1]
Und siebtens kann man keine Zeichen importieren, die gar nicht
übertragen wurden - weder sauber noch unsauber.
[TOFU entfernt]
Wolfgang
![[TEST] Document Foundation Community](https://communitytest.documentfoundation.org/images/discourse-logo-sketch.png){kind=logo}