Il semble y avoir de nombreux cas étranges où un e-mail ne devrait pas être rejeté, mais l’est quand même. Cela signifie que parfois, les utilisateurs envoient des e-mails de support que nous ne voyons jamais.
Par exemple, les e-mails envoyés à notre adresse de support depuis des adresses mac.com sont souvent rejetés pour absence de corps (Email::Receiver::NoBodyDetectedError). Ces e-mails contiennent pourtant souvent du texte dans le corps, ce qui suggère un problème d’analyse.
Mais outre la correction de la cause de ces rejets erronés, je serais ravi que nous puissions être alertés dès qu’un nouveau rejet se produit, afin que nous puissions l’examiner et vérifier si le rejet était justifié.
Cela pourrait prendre la forme d’une option pour envoyer des alertes au personnel pour tous les rejets, ou d’une option pour simplement mettre en copie (CC) tous les e-mails de rejet au personnel.
Sinon, si nous ne voulons manquer aucun e-mail de support entrant, nous devons interroger continuellement la liste des e-mails rejetés dans le back-end de Discourse. C’est fastidieux et inutile.
Je pense qu’il vaut mieux se concentrer sur l’exemple spécifique. Vous avez dit « souvent » rejetés, remarquez-vous des modèles dans le contenu des e-mails ? Si c’était un problème constant, je m’attendrais à ce que tous les e-mails provenant de mac.com échouent.
Eh bien… ‘souvent’ dans le sens de ‘assez souvent pour être un peu agaçant’. Notre principale préoccupation est que nous ne voulons pas que les gens s’énervent face à une absence perçue de réponse de la part de notre équipe de support.
J’ai cherché des modèles dans les cas que j’ai remarqués. Au départ, je pensais qu’il pourrait y avoir un problème avec la façon dont mac.com gère les e-mails, mais j’ai depuis déterminé que nous avons environ 30 utilisateurs avec des adresses mac.com qui ne présentent aucun problème.
J’ai aussi pensé que si mac.com disposait d’un client webmail, il pourrait gérer les e-mails HTML d’une manière non standard. Mais je ne suis même pas sûr qu’il existe un client webmail pour mac.com.
J’ai cru avoir résolu le mystère lorsque j’ai réalisé que l’incident le plus récent concernait un e-mail ne contenant que des lignes citées dans son corps, mais des tests ultérieurs ont montré que Discourse traite correctement ce type d’e-mails.
Je vais examiner les journaux pour voir à quelle fréquence ce genre de chose s’est produit et, bien sûr, chercher des modèles. Je pensais simplement que tant que la possibilité existe que Discourse commette occasionnellement de telles erreurs, un e-mail d’alerte semble être une mesure de protection simple.
Les adresses e-mail Mac.com sont en réalité des comptes iCloud.com. Apple a migré les comptes Mac.com et me.com vers iCloud il y a cinq ou six ans, en les préservant de plein droit.
Merci pour la clarification. Donc, en gros, tout problème lié aux e-mails provenant d’adresses mac.com devrait également toucher les adresses me.com et autres adresses iCloud.
Il n’y a pas de modèle réel. Il y a 21 cas où la raison du rejet n’est pas tout à fait claire ou semble erronée.
1 x « Impossible de traiter l’e-mail : Le corps est trop similaire à ce que vous avez publié récemment »
8 x « Impossible de traiter l’e-mail : Email::Receiver::BadDestinationAddress » – ces cas sont quelque peu mystérieux ; pourquoi les adresses sont-elles invalides ?
3 x « Impossible de traiter l’e-mail : Email::Receiver::NoBodyDetectedError » – deux semblent avoir un corps de message qui paraît normal ; l’un indique simplement « pas de corps »
1 x « Impossible de traiter l’e-mail : Email::Receiver::TooShortPost »
6 x « Impossible de traiter l’e-mail »
1 x « Impossible de traiter l’e-mail : Désolé, les nouveaux utilisateurs ne peuvent inclure qu’une seule image dans un message. »
1 x « Erreur non capturée : Erreur de syntaxe, expression non reconnue : #xxxxxx-email:product at company dot com »
Plusieurs de ces cas concernaient des tentatives légitimes de communication de la part de clients. Il reste incertain si l’e-mail de rejet envoyé par Discourse a atterri dans le dossier spam du destinataire ou a simplement été ignoré.
Ils ont envoyé à une adresse que vous ne gérez pas, comme support.
Pour moi, seul le « no body » (corps vide) là où vous indiquez qu’il y en a un ressemble à un bug potentiel. Une possibilité est que cela soit lié à l’utilisation d’un ancien client de messagerie défectueux.
J’ai vérifié plusieurs de ces cas (Email::Receiver::BadDestinationAddress), et beaucoup semblent être des réponses légitimes de clients, avec le destinataire sous cette forme : replies+longidentifiant@discourse.site.com. L’email d’alerte envoyé par Discourse au expéditeur suggère que leur email a été envoyé depuis une adresse différente de celle associée au sujet concerné, ce qui est probablement l’explication, mais dans un cas comme celui-ci, je souhaiterais toujours que le personnel soit alerté.
Cela ressemble effectivement à un bug, mais bien que j’aimerais voir cela corrigé, je pense qu’il y aura toujours des cas comme celui-ci. Ainsi, en plus de traquer les éventuels bugs d’analyse des emails, une alerte par email au personnel nous permettrait de fournir un support rapide dans l’intervalle.
C’est ce à quoi je pensais. La prochaine fois que je rencontrerai ce problème, je demanderai au client quel client de messagerie il utilise.
Ce que je veux dire, c’est que lorsque des e-mails sont rejetés, il s’agit parfois simplement de personnes cherchant à obtenir de l’aide, et non d’actes malveillants.
Bien sûr, dans certains cas, les e-mails rejetés par Discourse doivent effectivement être rejetés, mais nous ne voulons pas risquer de manquer un e-mail de support, nous sommes donc contraints de sonder la liste des rejets.
En attendant, les expéditeurs confus sont obligés de trouver d’autres moyens de nous joindre, comme le formulaire de contact sur notre site web.
Pour les sites plus grands, les alertes de rejet d’e-mails pourraient être trop nombreuses à gérer, mais pour nous, il serait beaucoup plus facile de les traiter que de faire face à des clients mécontents.
De plus, bien que Discourse envoie un e-mail de rejet à l’expéditeur avec des informations potentiellement utiles, je pense que ces e-mails finissent parfois dans les dossiers de spam, ce qui ajoute encore à la confusion des clients concernés.
C’est ennuyeux. Je pense que la solution à certains de ces problèmes pourrait se trouver ici : IMAP support for group inboxes.
Je ne suis pas sûr de savoir comment résoudre le problème des réponses envoyées depuis la mauvaise boîte mail, cependant. (Et quelle haine j’éprouve pour les formulaires de contact, peu importe de quel côté je me trouve !)
Si un utilisateur répond depuis une adresse différente de celle vers laquelle l’e-mail a été envoyé, c’est normal.
Si nous autorisions des réponses à ces e-mails depuis une autre adresse e-mail, nous exposerions les comptes à des abus via e-mail, où d’autres personnes se feraient passer pour un autre utilisateur. Nous rencontrons parfois ce problème dans nos propres messages de support ici sur Meta.
Si des formulaires de contact par e-mail sont utilisés, ils envoient généralement depuis une adresse e-mail et définissent l’en-tête Reply-To, ce qui signifie que nous rencontrons le même problème que celui mentionné ci-dessus.
Je ne vois pas personnellement de très bonne solution ici — peut-être que quelqu’un d’autre dans l’équipe a une idée.
Oui, comme je l’ai dit, il est logique de rejeter ces cas. Cependant, je souhaiterais toujours être alerté lorsque cela se produit.
J’ai mentionné les formulaires de contact uniquement parce que, lorsque les clients ne peuvent pas nous joindre via l’adresse e-mail de support (que Discourse traite), ils sont obligés de chercher des alternatives, ce qui n’est pas idéal.
Je ne suis pas tout à fait sûr de savoir comment procéder exactement. Vous pouvez surveiller /admin/email/rejected, mais pour obtenir une véritable alerte, vous auriez actuellement besoin d’un plugin.
Moi non plus, c’est pourquoi j’ai publié cela en tant que demande de fonctionnalité.
Oui, compris. Mais aller sur cette page et actualiser toutes les quelques minutes semble plutôt inefficace.
Un plugin irait très bien, mais je ne comprends pas pourquoi cette fonctionnalité ne pourrait pas simplement être ajoutée à Discourse. Pour moi, cela semble être une évidence. Discourse envoie déjà diverses alertes aux administrateurs et au personnel du site. Rendre le paramètre (alerte en cas de rejet d’e-mail) désactivé par défaut, ce qui, je suppose, conviendrait à de nombreux sites.
Autre exemple : un client a envoyé un e-mail à l’adresse du support pour signaler un problème rencontré avec son achat. Discourse a rejeté son e-mail : [Email::Receiver::InactiveUserError].
Je comprends qu’il soit logique que Discourse rejette les e-mails provenant d’utilisateurs inactifs, mais si notre équipe de support était alertée en même temps, elle pourrait immédiatement contacter le client pour lui expliquer ce qui s’est passé et quelles solutions sont possibles.
Sinon, sauf si nous interrogeons fréquemment la liste des rejets, le client se retrouve maintenant confronté à deux problèmes, tous deux résultant de systèmes automatisés, et dont notre équipe de support resterait ignorante. Une intervention humaine à ce stade est importante, mais des retards dans le temps de réponse peuvent survenir, car nous dépendons encore de la vérification manuelle de la liste des rejets.
Y a-t-il une raison technique pour laquelle les administrateurs ne peuvent pas être alertés des rejets d’e-mails ?
