Caractères d'espace manquants dans le texte du résumé d'activité par e-mail

Soutien
1

Je viens de m’envoyer des résumés de prévisualisation, car je ne les reçois normalement pas.

Je constate des espaces manquants aléatoires, mais cohérents, dans les titres et le texte des e-mails. Ces espaces ne manquent pas dans le contenu du forum, mais les mêmes sont systématiquement supprimés dans plusieurs résumés de prévisualisation générés, tels qu’ils apparaissent dans divers clients de messagerie.

J’ai essayé de supprimer et de rajouter les espaces d’origine sans succès.

Extraits :

digest_missing_spaces
digest_missing_spaces465×251 15.9 KB

J’ai examiné les résumés que je reçois de certains autres forums Discourse, et je ne vois cela nulle part ailleurs.

Quelqu’un d’autre a-t-il déjà rencontré ce problème, ou a une idée de ce qui se passe ?

2

Est-ce que cela pourrait être un problème de police / d’affichage ? Avez-vous vérifié le contenu brut sous-jacent ?

3

Hm. Je ne suis pas sûr de la façon de diagnostiquer un problème de police/affichage. Les e-mails s’affichent de la même manière dans plusieurs clients de messagerie et navigateurs sous Windows et Linux.

J’ai ajouté .json aux URL des publications du forum, et il n’y a rien d’anormal dans le contenu « topic_slug » ou « cooked »…

Y a-t-il autre chose que je pourrais vérifier dans le contenu brut ?

1 « J'aime »
4

Vous devrez vérifier l’e-mail brut plutôt que le message.

1 « J'aime »
5

Ok - j’ai regardé l’e-mail brut, et là où la version HTML manque d’espaces, la version texte a les bons espaces. Cependant, la version texte manque d’autres caractères d’espacement. Il n’y a aucune logique.

Peut-être que cela pourrait être un problème de codage de caractères lors de la copie/du collage des sujets affectés à partir d’une plateforme héritée..? EDIT : Non. Cela continue avec les publications actuelles, et aussi avec d’autres e-mails — pas seulement le résumé.

Des résumés Discourse plus récents présentant des publications actuelles n’ont pas le même problème, donc je ne m’inquiéterai pas trop à moins que cela ne continue. EDIT : Cela continue.

(Note annexe : juste pour surveiller ce genre de choses, je souhaite maintenant pouvoir forcer un résumé complet envoyé à mon compte administrateur sur une base quotidienne — indépendamment du fait que je sois constamment connecté.)

6

Pourriez-vous me transférer l’un de ces e-mails en pièce jointe ?

EDIT : fait

7

OK, voici ce que je vois dans le texte brut de l’e-mail :

[La désinformation commence à submerger la civilisation][2]

Le côté sombre de l'IA générative est qu'elle permet la production de mésinformation (en raison de la confabulation) et de désinformation (c'est-à-dire la production délibérée de fausses nouvelles pour atteindre un objectif) à l'échelle industrielle. Le rendu des pages Web dans le style de sources faisant autorité est simple, et les progrès en matière de deep fakes faciliteront les compléments d'histoires vidéo. Mis à part les nuages de fausses informations de Vinge pour cacher des informations (Rainbows End), qui, je ne crois pas, ont posé une solution, des auteurs de SF ont-ils pensé à cela et comment cela pourrait-il être abordé ?

note :

  • to overwhelm :white_check_mark:
  • a paperback :white_check_mark:
  • Renderingof :x:
  • Asidefrom :x:

et dans la version HTML :


<a href="https://forum.tasat.org/t/mis-disinformation-starts-to-overwhelm-civilization/66" style="text-decoration: none; font-weight: bold; color: #006699;; font-weight:400;line-height:1.3;margin:0;padding:0;text-decoration:none">
<strong >La désinformation commence à submerger la civilisation</strong>
…
Le rendu des pages Web dans le style de sources faisant autorité est simple, et les progrès en matière de deep fakes faciliteront les compléments d'histoires vidéo. Mis à part

note :

  • tooverwhelm :x:
  • apaperback :x:
  • Rendering of :white_check_mark:
  • Aside from :white_check_mark:

sous sa forme la plus brute (c’est-à-dire encodée), ces erreurs sont toujours là :

[La désinformation commence à submerger la civilisation][2]

Le côté sombre de l'IA générative est qu'elle permet la production de mésinformation (=
en raison de la confabulation) et de désinformation (c'est-à-dire la production délibérée de faus=
ses nouvelles pour atteindre un objectif) à l'échelle industrielle. Le rendu des pages Web dan=
s le style de sources faisant autorité est simple, et les progrès en matière de deep f=
akes faciliteront les compléments d'histoires vidéo. Mis à part les nuages de fausses informations de Vinge=
pour cacher des informations (Rainbows End), qui, je ne crois pas, ont posé une solution, des auteurs de SF ont=
-ils pensé à cela et comment cela pourrait-il être abordé ?
Ken


<a href=3D"https://foru=
m.tasat.org/t/mis-disinformation-starts-to-overwhelm-civilization/66" style
=3D"text-decoration: none; font-weight: bold; color: #006699;; font-weight:=
400;line-height:1.3;margin:0;padding:0;text-decoration:none"
>
=
                         <strong >La désinformation commence à submerger la civi=
lisation</strong>

ceux-ci ne sont pas dans le brut/cuit :

000000d0: 5265 6e64 6572 696e 6720 6f66 2077 6562  Rendu de web
000000e0: 2070 6167 6573 2069 6e20 7468 6520 7374   pages dans le st
000000f0: 796c 6520 6f66 2061 7574 686f 7269 7461  yle de autorita
00000100: 7469 7665 2073 6f75 7263 6573 2069 7320  tives sources est
00000110: 7374 7261 6967 6866 6f72 7761 7264 2c20  simple,
00000120: 616e 6420 7072 6f67 7265 7373 2069 6e20  et progrès dans
00000130: 6465 6570 2066 616b 6573 2077 696c 6c20  deep fakes va
00000140: 6d61 6b65 2076 6964 656f 2073 746f 7279  faire des histoires vidéo
00000150: 2063 6f6d 706c 656d 656e 7473 2065 6173   compléments facile
00000160: 6965 722e 2020 4173 6964 6520 6672 6f6d  r.  Mis à part

Non pas que je ne vous croyais pas :smiley:

Donc… des espaces sont occasionnellement supprimés du corps de l’e-mail, que ce soit la partie texte ou la partie HTML. Et pas aux mêmes endroits !

Je postule que ces erreurs pourraient avoir été introduites à l’un des quatre endroits :

  • dans Discourse, lors de la génération de l’e-mail
  • lors de la transmission de l’e-mail à un serveur de soumission d’e-mails
  • lors de la transmission de l’e-mail à un serveur intermédiaire/final
  • lors de la livraison dans la boîte aux lettres de l’utilisateur

Il est probablement plus facile de commencer par le début.

Pouvez-vous faire en sorte que Discourse soumette le courrier à un MTA local où vous pouvez l’inspecter dans la file d’attente avant que le MTA ne l’envoie à votre serveur de livraison d’e-mails « réel » ?

8

Merci pour l’analyse, Michael !

Je ne suis pas un administrateur de messagerie avancé — j’utilise l’auto-installation typique recommandée, avec l’envoi de courrier sortant via MailerSend.net, et j’ai soigneusement configuré DKIM/DMARC etc. pour qu’ils fonctionnent. D’après ce que je lis, l’intégration d’un MTA local comme sendmail ou Postfix est une démarche avancée qui est déconseillée dans la plupart des cas… Je suis un peu réticent à tripoter et potentiellement perturber un pipeline fonctionnel. :grimacing:

Existe-t-il une implémentation MTA facilement réversible, de type dépannage, que je pourrais envisager ?

9

Comme indiqué dans les modifications ci-dessus, ce problème persiste avec le contenu actuel publié par les utilisateurs, pas seulement le contenu copié-collé par l’administrateur — et est maintenant observé avec les e-mails de résumé, user_replied et user_posted.

Le support de MailerSend a confirmé que les espaces manquent lorsqu’ils reçoivent la requête de Discourse — il semblerait donc que l’erreur provienne de la génération de l’e-mail par Discourse… ?

Pour information, les espaces ne manquent pas lors de l’aperçu d’un résumé généré — seulement lorsqu’ils sont reçus par e-mail.

Dans le même temps, j’ai ce problème avec les e-mails de résumé, signalé par d’autres depuis février :

Ces publications répétées sont présentes dans les aperçus de résumé générés.

EDIT 2024-04-26 : le problème des résumés répétés a été identifié. En attendant une correction, j’ai atténué le problème via des modifications de paramètres, mais cela ne semble pas lié à ce sujet. Les e-mails sortants ont toujours des espaces manquants.

J’ai effectué une mise à jour et une reconstruction en ligne de commande pour voir si cela résoudrait certains problèmes, mais cela n’a eu aucun effet.

Si ces choses n’arrivent pas à tous ceux qui sont à jour sur la branche tests-passés, que pourrais-je vérifier dans ma configuration ?

10

Si vous pouvez désactiver temporairement TLS entre votre serveur et mailersend, cela vous permettra d’inspecter le trafic réel sur le réseau et vous montrera si Discourse envoie les espaces ou non, réglant ainsi cette question une fois pour toutes.

Si vous ne pouvez pas, vous pourriez essayer le MITM (Man-in-the-Middle) du trafic, mais c’est plus compliqué.

Si aucune des solutions ci-dessus ne fonctionne, dans ce cas, je configurerais un postfix local, mais pas pour une livraison directe, plutôt pour qu’il envoie son e-mail à votre compte mailersend de la même manière que Discourse.

De cette façon, vous pouvez faire en sorte que Discourse envoie par l’une ou l’autre méthode et vous pouvez inspecter le courrier dans la file d’attente postfix avant qu’il ne soit envoyé.

11

Merci Michael – Je suis nouveau dans l’“inspection sur le fil”, mais voici ce que j’ai trouvé.

MailerSend nécessite TLS et le port 587. Donc :

  • J’ai créé un fichier app.yml alternatif pour envoyer à un compte gratuit mailtrap.io sur le port 2525
  • J’ai défini DISCOURSE_SMTP_ENABLE_START_TLS = false
  • J’ai appliqué le changement avec :
cd /var/discourse
./launcher destroy app
./launcher start app
  • J’ai configuré Wireshark pour surveiller le trafic distant via tcpdump

Les paquets de contenu d’e-mail dans Wireshark et les e-mails non chiffrés reçus à Mailtrap n’ont, jusqu’à présent, aucun caractère d’espace manquant. Des résumés de test spécifiques exécutés dos à dos avec chaque configuration ont des espaces manquants avec ma configuration d’origine et pas avec la version mailtrap. Cela pourrait-il indiquer que le problème est introduit par le chiffrement TLS ?\n\nEDIT : Il m’est venu à l’esprit que je n’avais pas pleinement utilisé la configuration de test de Mailtrap. J’ai depuis exécuté plusieurs résumés d’aperçu chiffrés vers Mailtrap — sur le port 587 avec TLS activé — et je n’ai pas constaté de caractères d’espace manquants. Je pense maintenant que, bien que MailerSend m’ait dit que les problèmes étaient présents dans les requêtes reçues, cela pourrait se produire de leur côté après tout ? Je ne sais pas quoi leur demander de vérifier, mais je prévois de leur soumettre ces conclusions.

2 « J'aime »
12

(Au cas où cela pourrait aider : j’ai jeté un coup d’œil rapide à ma configuration et je n’ai pas vu de problème. Je me demandais donc si vous aviez un thème ou un plugin qui affecte votre configuration. Ce que j’ai fait, c’est visiter mail-tester.com pour obtenir une destination temporaire, puis utiliser Admin->Emails->Preview Summary pour envoyer un résumé à la destination temporaire, puis cliquer sur mail-tester pour afficher les versions HTML et texte brut. Cela pourrait valoir la peine d’essayer la même tactique pour voir si quelque chose est différent pour vous.)

13

Merci, Ed – pour accéder à mail-tester, mes e-mails devraient passer par mon relais MailerSend, ce que j’essayais de retirer de la chaîne. Mais votre commentaire m’a incité à revenir à Mailtrap et à effectuer des tests avec le chiffrement TLS, et j’ai modifié mon message précédent.

1 « J'aime »
14

Je trouve cela probable aussi.

Pour un test solide, je prendrais ensuite l’un des e-mails en texte brut que vous avez capturés et je le soumettrais manuellement via votre compte MailerSend en utilisant openssl s_client.