Un problème étrange est apparu dans ma configuration de test où je copie des e-mails vers mon serveur Discourse et exécute import_mbox.sh pour intégrer ces e-mails. Les e-mails d’origine proviennent d’une liste de diffusion.
J’ai constaté que si des personnes utilisent des téléphones Samsung et répondent à un e-mail précédent de la liste de diffusion, si j’essaie d’importer cet e-mail résultant dans Discourse, il n’extrait pas le nouveau contenu mais affiche simplement un doublon de l’e-mail d’origine, mais étiqueté comme si la personne qui a répondu l’avait écrit.
Si je copie/colle l’e-mail brut problématique dans la boîte de test avancée des e-mails, le même problème est présent. Si je tronque l’e-mail et supprime plusieurs parties ajoutées par Samsung, cela semble fonctionner.
Je ne peux pas mettre ici des copies des e-mails qui déclenchent ce problème car ils sont confidentiels. Les e-mails qui ne s’importent pas contiennent des sections comme celles-ci (et il n’y a aucun contenu lisible par l’homme - tout est codé en base64) :
Vous devrez donc modifier import_mbox.sh pour tronquer l’e-mail et supprimer les absurdités de Samsung.
Cela pourrait être un problème qui pourrait être résolu dans le cœur du système, car ces messages échouent probablement lorsqu’ils sont traités par e-mail (mais je n’ai pas regardé le code récemment, donc je ne sais pas). Dans tous les cas, la solution la plus rapide sera probablement de modifier le script d’importation pour ces messages.
Ou peut-être que quelqu’un reconnaîtra cela comme un problème dans le cœur du système et le corrigera.
Après avoir approfondi, il semble que l’application de messagerie Samsung encode un texte brut et une partie HTML, chacun codé en base64. J’ai constaté qu’en ajoutant une ligne vide entre les deux encodages, le filtre de messagerie fonctionne correctement. Il se peut que Samsung n’ajoute pas de ligne vide là où il le devrait, ou il se peut que le filtre de messagerie ne localise pas correctement la partie texte brut/texte HTML et ne réalise pas qu’une fois qu’il a trouvé la partie HTML, il sait où se termine l’en-tête de celle-ci et où commence le contenu du message.
J’ai essayé de copier l’e-mail d’origine de Gmail (via afficher l’original) et également d’exporter le même message depuis Thunderbird, avec les mêmes résultats.
Les e-mails générés par Samsung semblent avoir ceci en bas des en-têtes :
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[le message texte brut encodé en base64 va ici]
et cela se termine par
[plus de données encodées en base64 ici]19fDQo=
----_com.samsung.android.email_396413402758380
Content-Transfer-Encoding: base64
Content-Type: text/html; charset=UTF-8
PGh0b[encodage en base64 à nouveau, cette fois encodant la version HTML du même message]
et cela se termine par
[plus de données encodées en base64]NCg==
----_com.samsung.android.email_396413402758380--
Maintenant, si je modifie la partie du milieu en ajoutant une ligne vide (après le bit “email_396413402758380”), tout fonctionne parfaitement !
[plus de données encodées en base64 ici]19fDQo=
----_com.samsung.android.email_396413402758380
Content-Transfer-Encoding: base64
Content-Type: text/html; charset=UTF-8
PGh0b[encodage en base64 à nouveau, cette fois encodant la version HTML du même message]
Eh bien, dans ce cas, je dirais que c’est soit un bug dans le gem mail que nous utilisons pour analyser les e-mails, soit un bug dans l’application Samsung. Après un rapide coup d’œil aux RFC, je dirais que c’est probablement un bug dans l’analyseur.
Pourriez-vous par hasard fournir un exemple complet d’un tel e-mail problématique ? Peut-être pourriez-vous demander à l’un des auteurs de vos e-mails confidentiels de vous envoyer un e-mail non confidentiel ?
J’ai essayé de concevoir un e-mail en décodant le base64, en modifiant le libellé, puis en le réencodant et j’ai trouvé quelque chose d’autre d’intéressant.
La suppression d’un espace au milieu du message original peut permettre d’extraire correctement la réponse qui a été écrite au-dessus.
Dans cet exemple, au milieu du message HTML encodé en base64, si je trouve une ligne contenant un [espace] avant un slash div et que je le supprime, donc changer
21 20:17 (GMT+00:00) </div><div>To: LIST@LISTS
en
21 20:17 (GMT+00:00)</div><div>To: LIST@LISTS
par la suppression de l’espace avant le /div, puis réencoder en base64 et le remettre dans la zone de test des messages dans les paramètres d’administration, alors le filtre fonctionne.
Puis-je envoyer un e-mail par message direct si cela peut aider ?
Voici un e-mail artificiel que j’ai créé et qui, je pense, illustre le problème. Si vous regardez la partie HTML, elle contient une réponse à un message précédent. L’importateur ne semble pas pouvoir voir où le message original a commencé.
Ce problème semble également affecter les messages provenant d’autres clients de messagerie, je le découvre maintenant. Je ne peux pas publier publiquement les e-mails qui génèrent les fautes pour que tout le monde puisse les examiner, mais je serais heureux de laisser quelqu’un les voir en privé.
Ma configuration actuelle est que j’ai installé Discourse sur un serveur domestique, les e-mails envoyés à une liste de diffusion sont envoyés à mon adresse (qui va à un compte Gmail). Si un filtre « À : » correspond au nom de la liste de diffusion, j’ai configuré Gmail pour qu’il transfère une copie de l’e-mail à mailinglist@mydiscoursedomain.org.uk. Discourse a une catégorie configurée pour refléter une liste de diffusion qui recherche cet e-mail.
Le même problème survient également lorsque j’utilise le script import_mbox.sh après avoir copié manuellement les e-mails, donc cela doit être la partie du code qui recherche la nouvelle partie du message qui est confuse.
Existe-t-il un moyen de faire en sorte que Discourse parcoure tous les e-mails importés précédemment stockés et essaie de les reformater en utilisant la partie texte brut des e-mails d’origine, au cas où ce serait une solution temporaire au problème ci-dessus ? Avant l’importation, il était configuré pour utiliser la partie HTML. En jetant un coup d’œil via ‘rails c’, je peux voir que chaque message semble contenir le texte intégral des messages entrants stockés (y compris les en-têtes d’e-mail). J’ai essayé d’exécuter ‘rake posts:rebuild’ après avoir désactivé l’option HTML et, bien qu’il parcoure lentement tous les messages, je ne suis pas sûr que quelque chose ait changé, par exemple, j’ai essayé d’activer et de désactiver l’option d’affichage du contenu tronqué, mais la petite boîte avec trois points semble toujours être là sur les messages après la fin du rake.