Am 10.02.2018 um 15:45 schrieb [email protected]: > 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 -- If I could, I would wish for ONE news INDEED being a fake, namely for the news of this immature cockalorum in fact became President of the United States. -- Liste abmelden mit E-Mail an: [email protected] Probleme? https://de.libreoffice.org/hilfe-kontakt/mailing-listen/abmeldung-liste/ Tipps zu Listenmails: https://wiki.documentfoundation.org/Netiquette/de Listenarchiv: https://listarchives.libreoffice.org/de/users/ Alle E-Mails an diese Liste werden unlöschbar öffentlich archiviert
