Cela peut n’être qu’une faiblesse personnelle, mais je suis un peu confus par certains des rapports d’erreur que je reçois après avoir configuré la réponse par e-mail.
Lorsqu’une personne répond à un message depuis une adresse e-mail non associée à son compte, le message d’erreur (sur une instance Discourse auto-hébergée) est-il peut-être le mauvais ? Il semble que ce soit le message que l’on devrait recevoir si l’on envoyait vers une adresse incorrecte, plutôt que depuis une adresse non reconnue.
Le message que je reçois dans ce cas a pour objet Problème d’e-mail – Adresse “À:” inconnue, et le corps ressemble à ceci :
Nous sommes désolés, mais votre message e-mail à [“SNIP”] (intitulé Re: Aide s’il vous plaît) n’a pas fonctionné.
Aucune des adresses e-mail de destination n’est reconnue, ou l’en-tête Message-ID de l’e-mail a été modifié. Veuillez vous assurer que vous envoyez à la bonne adresse e-mail fournie par le personnel.
Changer l’adresse de l’en-tête From: dans mes réponses pour qu’elle corresponde à celle associée au compte semble résoudre le problème.
Existe-t-il un moyen simple de modifier ce comportement ? Ai-je mal configuré quelque chose ?
(Je devrais peut-être préciser que ce que j’espérerais vraiment, ce serait une option pour ignorer complètement l’en-tête From: et utiliser simplement la clé de réponse comme discuté ici ; y a-t-il une chance pour cela ?).
Ah, peut-être est-ce parce qu’il s’agit d’une réponse à un MP plutôt que d’un sujet public, et que Discourse pense donc que la personne envoyant l’e-mail (qu’il ne reconnaît pas comme un utilisateur valide) ne devrait pas pouvoir envoyer à cette adresse ?
Cela pourrait expliquer pourquoi il signale l’adresse dans le champ « À » comme invalide, plutôt que celle du champ « De » ?
En attendant, j’ai modifié le texte de ce message pour préciser qu’il pourrait s’agir d’un problème lié au champ « De » ou au champ « À ».
Cela s’expliquerait par le fait que l’erreur de permission est convertie en une erreur « non trouvée » quelque part dans la pile, et que le code d’envoi d’e-mail utilise ensuite le message associé à « non trouvé »…
On pourrait soutenir que l’reply_id (qui semble mapper à la fois un sujet et la personne qui répond) est un identifiant suffisant, et que falsifier un reply_id est plus difficile que de falsifier une adresse e-mail. Ainsi, cela serait tout aussi efficace, avec ou sans provenance de la bonne adresse e-mail.
Mais je ne cherche pas réellement à soutenir cela. Ce que vous dites ici a tout à fait du sens. Et, après réflexion, je réalise que ce qui mène à ce comportement est définitivement un cas limite (nous avons un SSO qui crée un compte avec des adresses e-mail universitaires, mais les gens les transfèrent parfois vers d’autres adresses, depuis lesquelles ils répondent).
Ma vraie question porte sur le contenu de l’e-mail d’erreur que les personnes reçoivent dans ce cas, qui semble susceptible d’être trompeur. Le vrai problème, ou du moins ce sur quoi la personne recevant l’e-mail d’erreur a le contrôle dans ce cas, est l’adresse « De » (et l’adresse associée à son compte), et non l’adresse « À », du moins à ce que je sache.
Quoi qu’il en soit, j’ai déjà une solution de contournement en :
modifiant le contenu de ce message (j’adore que Discourse soit si personnalisable !) et
indiquant aux gens de changer leur adresse e-mail s’ils souhaitent utiliser la réponse par e-mail
mais je me demande simplement s’il est judicieux de modifier quelque chose concernant les messages d’erreur envoyés dans quelles situations, compte tenu de cette confusion potentielle.
Si la réponse à cela est « Non, tout est bien tel quel », cela me convient parfaitement.
Nous avons déjà un support préliminaire pour les adresses e-mail alternatives par utilisateur.
Je me demande, @sam et @eviltrout, quand allons-nous formaliser un peu plus cela afin que les utilisateurs puissent ajouter une adresse e-mail secondaire ? Cela devrait-il être ajouté à la feuille de route 2.5 ?
Je pense que nous devrions commencer par rendre cela visible sur la page de gestion des utilisateurs dans l’administration, afin que vous puissiez voir et ajouter des adresses e-mail pour la 2.5. Ensuite, nous pourrions ajouter une interface utilisateur basique dans les pages d’administration pour fusionner les utilisateurs, maintenant que nous disposons d’une tâche rake bien testée.
Je peine toujours à comprendre pourquoi Discourse fait confiance/valide l’en-tête From:, alors qu’il peut être si facilement falsifié ?
L’en-tête de l’ID de la réponse fournit une validation utile, car il est impossible à deviner ou à connaître pour les malveillants.
Valider l’en-tête From: provoque simplement des rejets confus pour les utilisateurs légitimes qui tentent de publier par e-mail, s’ils répondent depuis une adresse e-mail différente (un cas limite plus courant qu’on ne le pense).
J’ai beaucoup d’adresses e-mail, et certains de mes utilisateurs aussi.
Je ne cherche sincèrement pas à provoquer une dispute ici. Je suis juste un peu blessé par ce problème, car il a contribué au fait qu’un membre très important de l’un de mes forums ait choisi de ne plus y contribuer.
Dans ce cas, vous devriez militer pour une évolution concernant la possibilité d’utiliser plusieurs adresses e-mail par utilisateur. Remontez un peu et faites donc quelques lectures, peut-être ?
Malheureusement, je ne sais pas si la fonctionnalité proposée résoudra le problème rencontré sur mon instance Discourse.
Dans mon cas, l’utilisatrice est la présidente d’une association civique. Elle possédait deux adresses e-mail et deux comptes Discourse (un pour chaque adresse). Un compte représentait son identité personnelle, tandis que l’autre était destiné aux publications « officielles » au nom de l’association civique.
Lorsqu’elle répondait par e-mail, elle le faisait souvent depuis la « mauvaise » adresse, ce qui entraînait le rejet de ses réponses.
Je suppose que la fonctionnalité évoquée ci-dessus impliquerait plusieurs adresses e-mail par compte Discourse, mais interdirait (naturellement) plusieurs comptes Discourse par adresse e-mail. Par conséquent, elle ne résoudrait malheureusement pas mon cas d’usage.
Ne pourriez-vous pas simplement fusionner les comptes afin que l’une des adresses e-mail devienne secondaire ?
Si ce n’est pas possible, il n’existe malheureusement aucun outil dans Discourse pour aider les utilisateurs à se rappeler quel « chapeau » ils portent.
Je le pourrais, d’un point de vue technique, mais il est intentionnel que l’utilisateur puisse publier sous deux identités distinctes (personnelle / au nom de la société civile).
Oui. Parfois, les gens se retrouvent bloqués dans ce scénario, mais je dirais plutôt qu’il s’agit d’un cas particulier plutôt que d’un cas limite
Ai-je bien compris que cette personne a en réalité deux identités, mais que toutes deux se retrouvent dans le même compte e-mail pour une raison quelconque ? Si c’est le cas, il semble qu’elle rencontre ce problème dans plus d’endroits que Discourse. Peut-être qu’il s’agit d’un problème mieux adapté à une résolution au niveau du client de messagerie ?
J’ai des alias professionnels dans mon compte e-mail professionnel, mais le client fait correspondre l’adresse « expéditeur » pour les réponses à l’adresse vers laquelle le message a été envoyé…
Je suis d’accord, c’est un cas particulier, et si elle n’était pas une utilisatrice aussi connue, cela n’aurait pas été un si grand problème.
Pour créer deux comptes Discourse, nous avons utilisé le gmail dot hack afin qu’elle puisse créer deux adresses e-mail pour sa boîte Gmail, lui permettant ainsi de créer deux comptes Discourse.
Lorsqu’elle répond par e-mail à un message sur le forum, Gmail n’utilise pas nécessairement la même variante d’adresse e-mail que Discourse attend.
À mon avis, tant que l’ID de réponse est valide, Discourse devrait accepter la réponse.
Le dot hack est extrêmement fragile, et ils auraient probablement beaucoup plus de plaisir avec l’adressage par plus à la place.
Si les deux comptes utilisent une adresse avec un plus et qu’aucun compte n’utilise l’adresse nue, l’interrupteur d’adresse « De : » fonctionnera parfaitement. Oublier de le régler signifiera simplement que l’e-mail sera rejeté au lieu d’être soumis sur le mauvais compte.
Utiliser + au lieu de points apporte également beaucoup de clarté à vos filtres, aussi
