Hmmm, en ese ejemplo y en el código fuente completo del correo electrónico que me enviaste (¡gracias!), el atributo moz-do-not-send no debería afectar la visualización de las etiquetas \u003cimg\u003e o \u003ca\u003e en las que aparece dicho atributo. El mozfilter solo examina los valores del atributo class, y no logro ver inmediatamente ningún otro lugar donde podría filtrarse.
Por lo tanto, no puedo entender por qué el contenido y el href del enlace con alias se separan, a menos que, por alguna razón, el importador de Discourse haya decidido de repente utilizar la parte plain/text del correo codificado en Mime (que sí tiene el texto y la URL separados). No sé por qué haría eso.
En tu configuración de prueba de Discourse, ¿podrías intentar importar o enviar por correo un archivo HTML de Thunderbird que incluya tanto un enlace con alias como, por ejemplo, una imagen incrustada o cualquier otro elemento que lo identifique claramente como la parte HTML del correo?
Sigo pensando que esto podría ser Discourse utilizando las otras partes MIME (en este caso, una parte plain/text seguida de una parte image/… del correo electrónico para crear su versión en Markdown, aunque no sé por qué. Quizás un validador HTML esté rechazando la parte text/html debido a atributos estrictamente no validadores como moz-do-not-send!?
¿Podrías realizar una prueba más con el mismo mensaje (algunos textos con una imagen en medio, pero también haz que parte del texto, aunque no todo, esté en negrita, incluso solo una palabra). Creo que eso determinará si la parte de texto proviene de un bloque text/plain o text/html.
Y disculpa por preguntar, pero solo para asegurarme, ¿tienes incoming_email_prefer_html establecido en true (marcado)?
Gracias @Flominator. Veo que el texto en negrita se ha convertido en cursiva, por lo que definitivamente no está utilizando el HTML directamente, pero de alguna manera está detectando el énfasis. Me pregunto si la parte text/plain del correo electrónico recibe algún tipo de marcado/agregado. ¿Podrías enviarme por mensaje privado el código fuente del correo como la última vez?
Hola @Flominator, gracias por el correo electrónico sin procesar. Al examinar la parte alternativa text/plain del correo, efectivamente coloca asteriscos alrededor del texto que está en negrita en la parte text/html. La mayoría de los renderizadores de Markdown (como el de Discourse) interpretan esto como texto en cursiva. Aquí está el segmento text/plain copiado y pegado por separado:
Bild in die Mitte dann wieder Text von dem ein Teil sogar fett
geschrieben ist
Gruß
Flo
lo cual se ve idéntico a tu captura de pantalla.
Por lo tanto, creo que lo que está ocurriendo es que el segmento text/html está siendo rechazado como HTML no válido (probablemente debido al nombre de atributo no estándar moz-do-not-send en las etiquetas a). Esto requerirá un parche para cambiar la forma en que se verifica el HTML válido (posiblemente simplemente eliminando esos atributos) y tengo menos confianza en lo estable que será sin que se integre en el código principal. Lo revisaré cuando tenga algo de tiempo.
Esto significa que el parche adjunto en un comentario anterior fallará (probablemente no de forma “espectacular” pero podría requerir una reconstrucción para que las actualizaciones vuelvan a funcionar) cuando actualices para incluir este nuevo commit (probablemente tu próxima actualización).
Si lo tienes aplicado automáticamente (por ejemplo, con un git applycmd en tu app.yml como se describió anteriormente), deberías eliminarlo antes de tu próxima actualización. De hecho, podría ser conveniente una reconstrucción, ya que ese commit podría fallar al aplicarse, dado que el lugar en receiver.rb donde se aplicará la diferencia del commit ya ha sido modificado por el parche.
Voy a 1) eliminar el git applycmd de app.yml, 2) reconstruir la aplicación, 3) actualizar (si no se ha hecho ya en la reconstrucción). Te informaré de cómo va…
[10 minutos después…]
Al final, hice lo siguiente en su lugar porque no requiere tiempo de inactividad durante la reconstrucción.
eliminar el git apply para el parche de app.yml (solo es necesario hacerlo antes de la próxima reconstrucción del contenedor de la aplicación)
revertir el archivo parcheado con:
i) launcher enter app
ii) (ahora en el contenedor de la aplicación) cd /var/www/discourse git checkout ./lib/email/receiver.rb exit
actualizar discourse usando la actualización web de administración
