Mejores prácticas: ¿separadores ascii en correos electrónicos?

Hola comunidad de Discourse,

En primer lugar, gracias por crear una herramienta que estoy encontrando excelente, valiosa, flexible y (en su mayoría) intuitiva. Estamos trabajando en cambiar varios modos de comunicación de nuestro proyecto para utilizar Discourse, desde listas de correo para discusión comunitaria basada en usuarios hasta correos electrónicos generados por scripts que nos notifican eventos clave (nuevos problemas, fallos en pruebas, etc.), y estamos emocionados por los cambios.

Uno de los contratiempos que he encontrado al configurar las cosas es el recorte automático del contenido que sigue a líneas como ----- en los correos enviados a Discourse. Si entiendo correctamente, esto se hace para evitar que las publicaciones realizadas por correo electrónico lleven toda la cadena de respuestas consigo, y en general he quedado impresionado con la forma limpia en que se renderizan las respuestas basadas en correo en Discourse, así que no critico esa decisión en absoluto en esta pregunta.

Tradicionalmente hemos utilizado estos separadores con frecuencia en correos electrónicos de notificación generados por scripts (que ahora reflejamos en Discourse) para facilitar su lectura, ya sea con tecnologías antiguas o modernas. Estoy en el proceso de eliminarlos y reemplazarlos con técnicas como “probemos simplemente usando más espacio vertical”, pero antes de avanzar demasiado en ese esfuerzo, quería consultar si existe alguna otra práctica recomendada para crear dichos separadores en correos enviados a Discourse, o alguna forma de escaparlos / pasarlos por alto el filtro actual que no haya encontrado (mi mejor intento hasta ahora ha sido usar una línea de guiones n en lugar de guiones o signos menos ASCII, pero no me agrada recurrir a caracteres no ASCII, por simplicidad).

Varios de nosotros también tendemos a usar habitualmente pequeños separadores --- en correos para delimitar un bloque de código o algo similar, así que me preocupa que, incluso una vez que haya convertido todos nuestros mensajes generados por scripts, esto afecte a los usuarios que confían en la opción de responder para contestar a temas de Discourse reflejados en sus bandejas de entrada (pero quizás sea solo una curva de aprendizaje que tendremos que superar).

Gracias por cualquier consejo o sugerencia al respecto,
-Brad

Aja… algo que acabo de descubrir yo mismo y que puede ayudar a otros que lleguen a este hilo: mezclar símbolos ASCII que no son separadores ni signos de puntuación en una línea que de otro modo actuaría como separador hace que pase el filtro de Discourse. Así que cambiar una línea como:

Encabezado
--------------------------------

por:

--- Encabezado ---------------------

es una forma de conservar cierta forma de línea separadora sin que Discourse la elimine. Por supuesto, esto aún no ayuda a los usuarios acostumbrados a confiar en pequeñas líneas separadoras ---- para destacar algo en un correo electrónico, así que sigo curioso sobre si otros tienen prácticas recomendadas al respecto.

A riesgo de seguir hablando solo, aquí hay un ejemplo motivador concreto que encontramos hoy:

Uno de los casos en los que utilizamos scripts para notificar a las personas sobre eventos es enviar correos a los desarrolladores cuando se fusionan nuevas PRs en nuestro repositorio de GitHub. Ahora hemos modificado estos scripts para que envíen correos a una categoría específica de nuestro sitio Discourse. Sin embargo, dado que GitHub utiliza Markdown para describir las PRs, a menudo tenemos encabezados de sección como el siguiente en las descripciones de nuestras PRs:

Detalles de esta PR
------------------

que se renderizan como encabezados de sección en GitHub. Pero cuando se envían por correo a Discourse, esta línea de guiones hace que el resto del mensaje se recorte.

Podríamos, por supuesto, entrenar a todos nuestros desarrolladores para que usen otros estilos de encabezados que no se recorten (como ## Detalles de esta PR), pero si hubiera alguna manera de modificar nuestro script para procesar el mensaje de fusión y proteger o escapar dichos patrones de modo que se preserven al llegar a Discourse, eso parecería más atractivo.