Zammad: Soporte de deshabilitación opcional para correos electrónicos HTML

Hola @MichaelHierweck

para que me quede más claro. ¿Cuál es el problema (caso de uso) con el correo electrónico HTML?

Nota: Solo los agentes pueden escribir correos electrónicos html y también se adjuntan archivos adjuntos de "texto sin formato" a todos los correos electrónicos salientes (por lo que si usa pine / mutt, etc., no tiene ninguna desventaja).

-Martín

Nuestros socios comerciales son algo anticuados y conscientes de la seguridad. Esperan que los correos electrónicos sean tanto de texto / sin formato y firmados con GnuPG. Pero quizás el legado pasado de moda en 2016 ...;)

GnuPG es bueno y también factible con correos electrónicos html (multiparte con texto + html allí). :)

Mantenemos este problema abierto para ver si alguien también está interesado en correos electrónicos de solo texto.

Por lo general, también uso correos electrónicos de solo texto. En mi programa de correo electrónico, cambio a HTML-mails solo en casos especiales.

En términos generales, diría que hoy en día los usuarios anticuados como yo tienen que aceptar el hecho de que los correos HTML son estándar.

En el caso de zammad, creo que aún sería útil tener un editor de correo electrónico de solo texto: el editor incorporado tiene muchos problemas con la edición de HTML ... Hoy, tan pronto como me encontré con un error de este tipo, abro zammad mensajes con Thunderbird y responda desde allí. Esto sucede con bastante frecuencia.

Apoyaría mucho esta solicitud. No solo porque, como principio, nunca escribo correos HTML, sino también porque estoy acostumbrado a enviar a los clientes descripciones generales tabulares e información con formato de sangría como

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

que parece una mierda, ilegible y poco profesional cuando se mira en un entorno formateado:

+ ---------- + ---------- +
| fila 1 | fila 2 |
+ ---------- + ---------- +
| campo 11 | campo 21 |
| sub 11 | |
| campo 12 | campo 22 |
+ ---------- + ---------- +

Lo ideal sería, si el formato pudiera seleccionarse por correo con un formato predeterminado, que puede ser configurado por cada agente.

No estoy completamente seguro de cómo se deben tratar los correos entrantes, pero probablemente sugeriría:

• el correo entrante es texto / sin formato: se muestra en tipo de letra monoespaciado / teletipo. Las respuestas solo se pueden enviar como texto / sin formato
• El correo entrante es texto / html _y_ texto / plano: la parte con formato HTML debe mostrarse y conservarse. Para la respuesta, el agente debe poder elegir entre simple y html. La parte respectiva del correo original se utiliza luego para la parte citada. Citar la parte de solo texto de los correos html a menudo hace que esta parte sea inutilizable (especialmente cuando contiene tablas, listas, etc.). Por lo tanto, deberíamos tener la opción de mantenerlo formateado.
• El correo entrante es solo texto / html: lo mismo que para los correos sin formato / html

solo mi 2c

Esto es tan importante que acabo de crear mi cuenta de github para comentar sobre esto. Los correos HTML me impiden usar Zammad para mi negocio. Haría parecer estúpida a mi empresa si enviáramos correos HTML.

La mayoría de los profesionales consideran el HTML para los correos electrónicos como un mal. Se explica en la wikipedia, por lo que esperaba que esto fuera de conocimiento común.

HTML se usa con demasiada frecuencia y causa demasiados problemas, entre ellos:

• Temas de seguridad. (Elementos de seguimiento integrados, JS, CSS ...)
• Falsas expectativas sobre los correos electrónicos combinadas con un mal estilo de comunicación (por ejemplo, usar colores en lugar de una cita adecuada)
• Procesamiento automático mucho más complicado (necesita encontrar su camino a través de contenedores MIME, luego deshacerse de las etiquetas ...)
• Tamaño mucho más grande
• Problemas de compatibilidad (¡no espere que los MUA procesen HTML!)
• Problemas de accesibilidad para personas con discapacidad. Solo piense en los usuarios ciegos al color o completamente ciegos.
• Edición muy torpe. Zammad es en realidad el mejor ejemplo. Esos correos HTML son PITA en el editor.
• Cotización. ¿Cómo se inserta ">" y dónde? ¿Qué haces cuando hay una etiqueta blockquote-, p- o div-tag o incluso una img justo en el medio?
• La BSI alemana recomienda mostrar HTML como texto sin formato. Por lo tanto, pueden surgir problemas de cumplimiento en el futuro.

Por lo general, el receptor define cómo quiere que se presenten / formateen los correos electrónicos. HTML rompe esta regla y permite al remitente definir fuentes elegantes (¿ilegibles?), Imágenes de fondo y otras campanas y silbidos, mientras que estos desaparecerán parcial o completamente en el cliente del receptor, dependiendo de su configuración. Esto significa que no se cumplen las expectativas del remitente, mientras que el destinatario no sabrá si el remitente muestra el correo como esperaba. Esto no puede suceder con texto sin formato.

Creo que el procesamiento de texto plano siempre debe ser lo primero en el desarrollo y tener una mayor prioridad. HTML debe considerarse un extra, no al revés.

Estoy de acuerdo y, por lo tanto, apoyo este problema.

dito, esperando esta opción desde el primer comentario.

En primer lugar, muchas gracias por su participación en el proyecto de código abierto Zammad. Reconocemos su necesidad de esto. Sin embargo, actualmente no está en su (breve) lista de próximas funciones. Esto significa que probablemente no trabajaremos en ello al menos durante el próximo año a menos que encontremos un patrocinador. Otra opción sería enviar una solicitud de extracción. Nos complace apoyarlo en eso para que obtenga la calidad y la forma requeridas para hacerlo al estilo Zammad.
Dado que no hay una nueva entrada sobre los requisitos definidos, que ya están bastante claros, le pido que limite su impulso de esta función a los emojis en la publicación inicial. Enviar comentarios crea mucho ruido y nos distrae de nuestro trabajo en Zammad y nos ralentiza. De lo contrario, tengo que bloquear la conversación. Siéntase libre de comenzar una discusión vívida en nuestra junta comunitaria https://community.zammad.org/, que es el lugar adecuado para eso.
Gracias por su comprensión y apoyo!

Devolviendo este problema al centro de atención. Los correos electrónicos de conformación de direcciones que provienen de Github ahora son html mal formados y, como tal, están causando que productos como ProofPoint alteren el correo electrónico en tránsito. El deseo del correo electrónico de texto sin formato debe revisarse una vez más, ya que el formato html frágil causa problemas con los filtros de correo electrónico comerciales. Estoy de acuerdo en que no es razonable esperar que GitHub realice una prueba de regresión contra todos los proveedores, pero la falta de capacidad para controlar el formato de entrega de correo electrónico pone la responsabilidad de GitHub para realizar tales pruebas de regresión.

https://useplaintext.email/
https://useplaintext.email/#why -plaintext

Estaría dispuesto a tirar un poco de dinero en un bote para que se agregue esta función, aunque probablemente no lo suficiente para financiarla por mi cuenta. Miré un poco a mi alrededor y vi una serie de otros problemas de GitHub etiquetados con prioritised by payment ; Asumo que significa que es posible que los usuarios específicos fondo de características que les gustaría ver?

También quiero realmente soporte para mensajes de texto sin formato. Lo mejor sería si fuera flexible, como señala @fthommen .

Lo siento, esto volvió a pasar por debajo de mi radar.
Comuníquese con el departamento de ventas [arroba] zammad [punto] com.

Nuestros colegas calcularán el costo y, si es demasiado, también verificarán si califica para un grupo de pago para que varias personas lo lleven a cabo.

Supongo que esto está actualmente bloqueado por el futuro para ser editor de Zammad.
Actualmente, Zammad no tiene forma de saber si puede formatear un correo o no, lo que en mi opinión puede ser problemático a partir de ahora.

Aquí hay un truco rápido no oficial que intenta deshabilitar por completo el envío de la parte html en todos los correos electrónicos.
Advertencia: aún no probado en producción, puede romper otras cosas, su kilometraje puede variar.

Este es un parche para los expertos que ejecutan Zammad y saben cómo aplicar, probar y depurar su instalación.
Sin embargo, si solo desea enviar mensajes de texto o correos sin formato (por ejemplo, por razones de seguridad), puede intentarlo.

`` parche
--- 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 @@
# generar parte plana
atributo [: cuerpo] = atributo [: cuerpo] .html2text
+

• # un truco para enviar solo mensajes de texto / correos sin formato, consulte la solicitud de función
• # https://github.com/zammad/zammad/issues/325
• # elimine la parte html_alternative generada para que no se pueda enviar:
• html_alternative = falso
  fin

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

Nos pusimos en contacto con el departamento de ventas de Zammad hace un tiempo acerca de esta función y parecía que tendría que convertirse en un proyecto realmente pequeño, que habría estado más allá de nuestro presupuesto. En su lugar, pagamos voluntariamente una pequeña suma de tres dígitos a https://www.zammad-foundation.org/ para que obtengan algo a cambio de su agradable producto de software libre y lo mantengan. Si le gusta este parche, considere pagar también a la fundación Zammad. :)