Zammad: Optionale Deaktivierung der Unterstützung für HTML-E-Mails

Erstellt am 28. Okt. 2016  ·  15Kommentare  ·  Quelle: zammad/zammad

Es sollte eine Option zum Deaktivieren der Unterstützung für HTML-E-Mails geben.

Falls ausgewählt:

  • Der Editor für Nachrichten, Vorlagen, Fußzeilen,... könnte/sollte durch ein reines Textfeld ersetzt werden.
  • Eingehende Nachrichten sollten bei Bedarf in Text/Plain umgewandelt werden.
  • Ausgehende Nachrichten sollten nur Text/Nur sein.
enhancement

Hilfreichster Kommentar

Dieses Thema wieder ins Rampenlicht rücken. Die von Github kommenden Adressbestätigungs-E-Mails sind jetzt fehlerhaftes HTML und führen daher dazu, dass Produkte wie ProofPoint die E-Mail während der Übertragung verstümmeln. Der Wunsch nach Klartext-E-Mail sollte noch einmal überprüft werden, da die fragile HTML-Formatierung Probleme mit kommerziellen E-Mail-Filtern verursacht. Ich stimme zu, dass es unvernünftig ist, von GitHub Regressionstests gegen jeden Anbieter zu erwarten, aber die fehlende Möglichkeit, das E-Mail-Versandformat zu kontrollieren, legt GitHub die Verantwortung für solche Regressionstests auf

Alle 15 Kommentare

Hallo @MichaelHierweck

um es mir klarer zu machen. Was ist das Problem (Anwendungsfall) mit HTML-E-Mail?

Hinweis: Nur Agenten können HTML-E-Mails schreiben und auch "Klartext"-Anhänge werden an alle ausgehenden E-Mails angehängt (wenn Sie also pine/mutt usw. verwenden, haben Sie keinen Nachteil).

-Martin

Unsere Geschäftspartner sind irgendwie altmodisch und sicherheitsbewusst. Sie erwarten, dass E-Mails sowohl Text/Plain als auch GnuPG-signiert sind. Aber vielleicht ist altmodisch 2016 ein Vermächtnis... ;)

GnuPG ist nett und auch mit HTML-E-Mails machbar (mehrteilig mit Text+html drin). :)

Wir halten dieses Thema offen, um zu sehen, ob jemand auch an reinen Text-E-Mails interessiert ist.

Normalerweise verwende ich auch reine Text-E-Mails. In meinem E-Mail-Programm wechsle ich nur in besonderen Fällen auf HTML-Mails um.

Generell würde ich sagen, dass altmodische Benutzer wie ich heute akzeptieren müssen, dass HTML-Mails Standard sind.

Im Fall von zammad denke ich, dass es immer noch hilfreich wäre, einen reinen Text-E-Mail-Editor zu haben: Der eingebaute Editor hat viele Probleme mit der Bearbeitung von HTML ... Heute, sobald ich auf einen solchen Fehler stoße, öffne ich zammad Nachrichten mit Thunderbird und antworte von dort. Dies passiert ziemlich oft.

Ich würde diese Bitte sehr unterstützen. Nicht nur, weil ich grundsätzlich keine HTML-Mails schreibe, sondern auch, weil ich es gewohnt bin, Kunden tabellarische Übersichten und eingerückte Informationen wie

 | row 1    | row 2    |
 +----------+----------+
 | field 11 | field 21 |
 |   sub 11 |          |
 | field 12 | field 22 |
 +----------+----------+

was in einer formatierten Umgebung einfach beschissen, unlesbar und unprofessionell aussieht:

+----------+----------+
| Reihe 1 | Reihe 2 |
+----------+----------+
| Feld 11 | Feld 21 |
| unter 11 | |
| Feld 12 | Feld 22 |
+----------+----------+

Ideal wäre, wenn das Format per Mail mit einem Standardformat ausgewählt werden könnte, das von jedem Agenten eingestellt werden kann.

Ich bin mir nicht ganz sicher, wie eingehende Mails behandelt werden sollen, aber ich würde wahrscheinlich vorschlagen:

  • eingehende Post ist Text/einfach: Anzeige in Monospaced/Fernschrift-Schriftart. Antworten können nur als Text/einfach gesendet werden
  • Eingehende Mail ist text/html _und_ text/plain: Der HTML-formatierte Teil sollte angezeigt und beibehalten werden. Für die Antwort sollte der Agent zwischen Plain und HTML wählen können. Für den zitierten Teil wird dann der jeweilige Teil der Originalmail verwendet. Das Zitieren des Nur-Text-Teils von HTML-Mails macht diesen Teil oft unbrauchbar (insbesondere wenn er Tabellen, Listen usw. enthielt). Daher sollten wir die Möglichkeit haben, es formatiert zu lassen
  • Eingehende E-Mail ist nur Text/HTML: Wie für normale/html-E-Mails

nur mein 2c

Dies ist so wichtig, dass ich gerade mein Github-Konto erstellt habe, um dies zu kommentieren. HTML-Mails halten mich davon ab, Zammad für mein Geschäft zu verwenden. Es würde meine Firma dumm aussehen lassen, wenn wir HTML-Mails versenden würden.

HTML für E-Mails wird von den meisten Fachleuten als böse angesehen. Es wird in der Wikipedia erklärt, daher habe ich erwartet, dass dies allgemein bekannt ist.

HTML wird viel zu oft verwendet und verursacht viel zu viele Probleme, darunter:

  • Sicherheitsprobleme. (Eingebettete Tracker-Items, JS, CSS...)
  • Falsche Erwartungen an E-Mails kombiniert mit schlechtem Kommunikationsstil (z. B. Verwendung von Farben statt korrekter Zitate)
  • Viel kompliziertere automatische Verarbeitung (müssen sich durch MIME-Container zurechtfinden, dann Tags loswerden...)
  • Viel größer
  • Kompatibilitätsprobleme (Erwarten Sie nicht, dass MUAs HTML verarbeiten!)
  • Barrierefreiheit für Menschen mit Behinderungen. Denken Sie nur an farbenblinde oder vollständig blinde Benutzer.
  • Sehr umständliche Bearbeitung. Zammad ist eigentlich das beste Beispiel. Diese HTML-Mails sind im Editor PITA.
  • Zitat. Wie fügt man ">" ein und wo? Was tun, wenn ein Blockquote-, P- oder Div-Tag oder sogar ein Img mittendrin ist?
  • Das deutsche BSI empfiehlt, HTML als Klartext anzuzeigen. Daher können in Zukunft Compliance-Probleme auftreten.

Normalerweise definiert der Empfänger, wie E-Mails präsentiert/formatiert werden sollen. HTML bricht diese Regel und erlaubt es dem Sender, ausgefallene (unlesbare?) Schriftarten, Hintergrundbilder und andere Schnickschnack zu definieren, während diese je nach Einstellung im Client des Empfängers teilweise oder vollständig verschwinden. Dies bedeutet, dass die Erwartungen des Absenders nicht erfüllt werden, während der Empfänger nicht weiß, ob die E-Mail wie vom Absender erwartet angezeigt wird. Das kann mit Klartext nicht passieren.

Ich denke, die Klartextverarbeitung sollte bei der Entwicklung immer an erster Stelle stehen und eine höhere Priorität haben. HTML ist als Extra zu betrachten, nicht umgekehrt.

Ich stimme zu und unterstütze daher dieses Problem

dito, wartet seit dem ersten Kommentar auf diese Option.

Zunächst vielen Dank für Ihre Teilnahme am Open-Source-Projekt Zammad. Wir erkennen Ihren Bedarf dafür. Es steht jedoch derzeit nicht auf Ihrer (kurzen) Liste der kommenden Funktionen. Das bedeutet, dass wir wahrscheinlich nicht mindestens im nächsten Jahr daran arbeiten werden, es sei denn, wir finden einen Sponsor. Eine andere Möglichkeit wäre das Senden eines Pull-Requests. Gerne unterstützen wir Sie dabei, um es in der gewünschten Qualität und Form auf Zammad-Art zu bekommen.
Da es keinen neuen Input zu den definierten Anforderungen gibt, die schon ziemlich klar sind, bitte ich Sie, Ihren Drang nach diesem Feature auf Emojis im ersten Post zu beschränken. Das Versenden von Kommentaren erzeugt viel Lärm und lenkt uns von unserer Arbeit an Zammad ab und verlangsamt uns. Ansonsten muss ich das Gespräch sperren. Fühlen Sie sich frei, eine lebhafte Diskussion in unserem Community-Board https://community.zammad.org/ zu starten, das der richtige Ort dafür ist.
Vielen Dank für Ihr Verständnis und Ihre Unterstützung!

Dieses Thema wieder ins Rampenlicht rücken. Die von Github kommenden Adressbestätigungs-E-Mails sind jetzt fehlerhaftes HTML und führen daher dazu, dass Produkte wie ProofPoint die E-Mail während der Übertragung verstümmeln. Der Wunsch nach Klartext-E-Mail sollte noch einmal überprüft werden, da die fragile HTML-Formatierung Probleme mit kommerziellen E-Mail-Filtern verursacht. Ich stimme zu, dass es unvernünftig ist, von GitHub Regressionstests gegen jeden Anbieter zu erwarten, aber die fehlende Möglichkeit, das E-Mail-Versandformat zu kontrollieren, legt GitHub die Verantwortung für solche Regressionstests auf

Ich wäre bereit, ein bisschen Geld in einen Topf zu werfen, um dieses Feature hinzuzufügen, wahrscheinlich jedoch nicht genug, um es alleine zu finanzieren. Ich habe mich ein wenig umgesehen und habe eine Reihe anderer GitHub-Probleme gesehen, die mit prioritised by payment markiert sind; Ich gehe davon aus, dass es für Benutzer möglich ist , bestimmte Funktionen zu finanzieren, die sie sehen möchten?

Ich möchte auch wirklich Unterstützung für Klartext-Mails. Das Beste wäre, wenn es flexibel wäre, wie @fthommen hervorhebt .

Entschuldigung, dass das wieder unter meinem Radar gelandet ist.
Bitte wenden Sie sich an den Vertrieb [at] zammad [dot] com.

Unsere Kollegen ermitteln die Kosten und prüfen bei Überschreitung auch, ob ein Zahlungspool für mehrere Personen in Frage kommt.

Ich vermute, dass dies derzeit von der Zukunft blockiert wird, um Editor für Zammad zu sein.
Zammad hat derzeit keine Möglichkeit zu sagen, ob Sie eine E-Mail formatieren dürfen oder nicht, was meiner Meinung nach derzeit mühsam sein könnte.

Hier ist ein inoffizieller Quick-Hack, der versucht, das Senden des HTML-Teils in allen E-Mails vollständig zu deaktivieren.
Achtung: noch nicht in der Produktion getestet, kann andere Sachen kaputt machen, Ihre Laufleistung kann variieren.

Dies ist ein Patch für Experten, die Zammad selbst betreiben und wissen, wie man ihre Installation anwendet, testet und debuggt.
Wenn Sie jedoch (zB aus Sicherheitsgründen) nur Text-/Plainmails versenden möchten, können Sie es versuchen.

```Patch
--- app/models/channel/email_build.rb.org 2021-03-18 17:43:54.776830273 +0100
+++ app/models/channel/email_build.rb 2021-03-18 17:49:45.262137627 +0100
@@ -63,4 +63,9 @@
# Klarteil generieren
attr[:body] = attr[:body].html2text
+

  • # ein Hack, um nur Text-/Plainmails zu versenden, siehe Feature Request
  • # https://github.com/zammad/zammad/issues/325
  • # Entfernen Sie den generierten html_alternative-Teil, damit er nicht gesendet werden kann:
  • html_alternative = false
    Ende

``` (applied against zammad Version: 3.6.0-1615986441.da478686.buster from the official Debian Buster package, /opt/zammad`)

Wir haben den Zammad-Vertrieb vor einiger Zeit wegen dieser Funktion kontaktiert und es sah so aus, als müsste es ein echtes kleines Projekt werden, das unser Budget überstiegen hätte. Stattdessen haben wir freiwillig einen kleinen dreistelligen Betrag an die https://www.zammad-foundation.org/ gezahlt, damit sie etwas für ihr schönes Freie-Software-Produkt zurückbekommen und es pflegen. Wenn Ihnen dieser Patch gefällt, denken Sie bitte daran, auch die Zammad-Stiftung zu bezahlen. :)

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen