Ha surgido un problema extraño en mi configuración de pruebas, donde estoy copiando correos electrónicos a mi servidor Discourse y ejecutando el script import_mbox.sh para incorporar esos correos electrónicos. Los correos electrónicos originales provienen de una lista de correo de listas de distribución.
He descubierto que si las personas usan teléfonos Samsung y responden a un correo electrónico anterior de la lista de distribución, si intento importar ese correo electrónico resultante a Discourse, no extrae el contenido nuevo, sino que simplemente muestra un duplicado del correo electrónico original, pero etiquetado como si lo hubiera escrito la persona que respondió.
Si copio y pego el correo electrónico sin procesar que es problemático en el cuadro de Pruebas Avanzadas de Correos Electrónicos, el mismo problema está presente. Si trunco el correo electrónico y elimino varias partes añadidas por Samsung, parece funcionar.
No puedo poner copias de los correos electrónicos que desencadenan esto aquí, ya que son confidenciales. Los correos electrónicos que no se importan tienen secciones como esta (y no hay contenido legible por humanos, todo está codificado en base64):
Así que necesitarás modificar import_mbox.sh para truncar el correo electrónico y eliminar las tonterías de Samsung.
Podría ser un problema que se podría resolver en el núcleo, ya que esos mensajes probablemente fallan cuando se procesan al enviarlos por correo electrónico (pero no he mirado el código últimamente, así que no lo sé). En cualquier caso, la solución más rápida probablemente será modificar el script de importación para esos mensajes.
O tal vez alguien reconozca esto como un problema en el núcleo y lo solucione.
Habiendo investigado un poco más, parece que la aplicación de correo de Samsung codifica una parte de texto plano y una parte de HTML, cada una codificada en base64. He descubierto que si agrego una línea en blanco entre las dos codificaciones, el filtro de correo funciona correctamente. Puede ser que Samsung no esté agregando una línea en blanco donde debería, o puede ser que el filtro de correo no esté localizando correctamente la parte de texto plano/HTML y no se dé cuenta de que, una vez que ha encontrado la parte HTML, sabe dónde termina la cabecera de esta y comienza el contenido del mensaje.
He intentado copiar el correo electrónico original de Gmail (a través de ver original) y también exportar el mismo mensaje desde Thunderbird, con los mismos resultados.
Los correos electrónicos generados por Samsung parecen tener esto al final de las cabeceras:
Content-Type: multipart/alternative;
boundary="--_com.samsung.android.email_396413402758380"
----_com.samsung.android.email_396413402758380
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset=UTF-8
WWVz[aquí va el mensaje de texto plano codificado en base64]
y esto termina con
[más datos codificados en base64 aquí]19fDQo=
----_com.samsung.android.email_396413402758380
Content-Transfer-Encoding: base64
Content-Type: text/html; charset=UTF-8
PGh0b[codificación base64 de nuevo, esta vez codificando la versión HTML del mismo mensaje]
y esto termina con
[más datos codificados en base64]NCg==
----_com.samsung.android.email_396413402758380--
¡Ahora, si cambio la parte central agregando una línea en blanco (después de la parte “email_396413402758380”), todo funciona perfectamente!
[más datos codificados en base64 aquí]19fDQo=
----_com.samsung.android.email_396413402758380
Content-Transfer-Encoding: base64
Content-Type: text/html; charset=UTF-8
PGh0b[codificación base64 de nuevo, esta vez codificando la versión HTML del mismo mensaje]
Bueno, en ese caso, diría que es un error en la gema mail que usamos para analizar correos electrónicos o un error en la aplicación Samsung. Después de un vistazo rápido a los RFC, diría que probablemente sea un error en el analizador.
¿Podrías, por casualidad, proporcionar un ejemplo completo de un correo electrónico tan problemático? ¿Quizás podrías pedirle a uno de los autores de tus correos electrónicos confidenciales que te envíe un correo electrónico no confidencial?
He intentado elaborar un correo electrónico decodificando la base64, cambiando la redacción y luego volviendo a codificar y he encontrado algo más interesante.
La eliminación de un carácter de espacio a mitad del mensaje original puede hacer que extraiga correctamente la respuesta que se escribió anteriormente.
En este ejemplo, en medio del mensaje HTML codificado en base64, si encuentro una línea que contiene un [espacio] antes de un div y la elimino, así cambio
21 20:17 (GMT+00:00) </div><div>To: LIST@LISTS
a
21 20:17 (GMT+00:00)</div><div>To: LIST@LISTS
mediante la eliminación del carácter de [espacio] antes del /div, luego vuelvo a codificar a base64 y lo coloco de nuevo en el cuadro de prueba del mensaje en la configuración de administración, entonces el filtro funciona.
¿Podría enviar un correo electrónico por mensaje directo si ayuda?
Aquí tienes un correo electrónico artificial que he creado y que creo que demuestra el problema. Si observas la parte HTML, tiene una respuesta a un mensaje anterior. El importador no parece ser capaz de ver dónde comenzó el mensaje original.
From someone@gmail
Delivered-To: someone@gmail
Importance: Normal
MIME-Version: 1.0
Message-ID: <E1mt6gg-00H2OV-6N@relay01.mail.eu.clara.net>
Date: Fri, 3 Dec 2021 11:25:05 +0000
From: someone <someone@somewhere.net>
Subject: Re: Example e-mail
To: <LIST@LISTSERV>
In-Reply-To: <007301d7e834$c268a3e0$4739eba0$@sslmc.co.uk>
Precedence: list
Content-Type: multipart/alternative;
boundary="--_com.samsung.android.email_7076959834053910"
----_com.samsung.android.email_7076959834053910
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset=UTF-8
Sí, y estamos recibiendo muchas cosas en ABC y atención urgente, junto con efectos secundarios de la vacuna contra la gripe + refuerzo. Aparentemente, DEF111 no puede lidiar con este tipo de consulta. Se ve bien para Navidad y la semana de Año Nuevo 2222
Sam
Dr Sam Smithy
----
Mensaje original
----
De: South Souths XYZ <enquiry@SSXYZ.CO.UK>
Fecha: 03/12/2021 10:59 (GMT+00:00)
Para: LISTS@LISTSERV.ABC.ORG.UK
Asunto: ¡Todo vuelve a nuestra puerta!
Las prácticas informan de que reciben 2 o 3 consultas/día de pacientes que se refieren a problemas de vacunación contra la gripe que han sido remitidos a su GP por XYZ 123 o el NHS. Estas consultas incluyen la programación de dosis para Pts inmunosuprimidos, así como cuestiones farmacéuticas.
----_com.samsung.android.email_7076959834053910
Content-Transfer-Encoding: base64
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"></head><body dir="auto"><div dir="auto">Sí y we are getting lots in ABC and urgent care, along with vaccination side effects from flu + booster. Apparently DEF111 can't deal with this sort of query. Looking good for Xmas and NY week 2222</div><div dir="auto"><br></div><div dir="auto">Sam</div><div dir="auto"><br></div><div id="composer_signature" dir="auto"><meta http-equiv="Content-Type" content="text/html; charset=UTF-8">Dr Sam Smithy </div><div dir="auto"><br></div><div><br></div><div align="left" dir="auto" style="font-size:100%;color:#000000"><div dir="auto">---- - Mensaje original - ----</div><div dir="auto">De: South Souths XYZ <enquiry@SSXYZ.CO.UK> </div><div>Fecha: 03/12/2021 10:59 (GMT+00:00) </div><div>Para: LISTS@LISTSERV.ABC.ORG.UK </div><div>Asunto: ¡Todo vuelve a nuestra puerta! </div><div><br></div></div><div class="WordSection1"><p class="MsoNormal"><span style="font-family:'Arial','sans-serif';">Prácticas informando de que reciben 2 o 3 queries/day de pacientes que se refieren a issues de vacunación contra la gripe who have been referred to their GP by XYZ 123 or the NHS. These queries include scheduling doses for immunosuppressed pts as well as pharmaceutical questions. </span></p></div></body></html>
----_com.samsung.android.email_7076959834053910--
Este problema parece afectar también a los mensajes de otros clientes de correo, según estoy descubriendo. No puedo publicar los correos electrónicos que generan las fallas para que todos los vean públicamente, pero estaría encantado de que alguien los viera en privado.
Mi configuración actual es que he instalado Discourse en un servidor doméstico, los correos electrónicos a una lista de distribución de correo se me envían (lo que va a una cuenta de Gmail). Si un filtro ‘Para:’ coincide con el nombre de la lista de distribución, he configurado Gmail para que reenvíe una copia del correo electrónico a mailinglist@mydiscoursedomain.org.uk. Discourse tiene una categoría configurada para reflejar una lista de distribución que busca este correo electrónico.
El mismo problema surge si también utilizo el script import_mbox.sh después de haber copiado manualmente los correos electrónicos, por lo que debe ser la parte del código que busca la nueva parte del mensaje la que se confunde.
¿Hay alguna forma de hacer que Discourse revise todos los correos electrónicos importados previamente almacenados e intente reformatearlos usando la parte de texto plano de los correos electrónicos originales en caso de que sea una solución temporal al problema anterior? Antes de la importación, se configuró para usar la parte HTML. Al echar un vistazo usando ‘rails c’, puedo ver que cada publicación parece tener almacenado el texto completo de los mensajes entrantes (incluidos los encabezados de correo electrónico). He intentado ejecutar ‘rake posts:rebuild’ después de desactivar la opción HTML y, aunque avanza lentamente a través de todos los mensajes, no estoy seguro de si algo ha cambiado, por ejemplo, intenté activar y desactivar la opción de mostrar contenido recortado también, pero el pequeño cuadro con tres puntos todavía parece estar allí en las publicaciones después de que el rake ha terminado.