Je travaille avec un utilisateur pour résoudre un problème de non-réception d’e-mails et j’ai découvert l’action « révoquer l’e-mail » enregistrée pour son compte. Comment puis-je annuler ou annuler cette action ?
De plus : si l’e-mail d’un utilisateur est révoqué, cela est-il reflété dans les journaux E-mails envoyés ou E-mails ignorés ? Ou uniquement dans l’action Révoquer l’e-mail ?
L’action de révocation d’e-mail est déclenchée lorsque plusieurs e-mails envoyés à un utilisateur rebondissent (échec de la livraison). À chaque fois qu’un e-mail rebondit, le « score de rebond » de l’utilisateur est incrémenté selon la valeur définie par le paramètre soft bounce score ou hard bounce score de votre site. Une fois que le score de rebond d’un utilisateur atteint la valeur du paramètre bounce score threshold de votre site (par défaut 4), l’action de révocation d’e-mail est déclenchée.
Vous pouvez annuler cette action en accédant à la page d’administration de l’utilisateur et en cliquant sur le bouton « Réinitialiser » situé dans la ligne « Score de rebond » près du haut de la page.
Si vous ne cliquez pas sur le bouton Réinitialiser, Discourse effacera automatiquement le score de rebond de l’utilisateur après la période définie par le paramètre reset bounce score after days. Ce paramètre est défini par défaut à 30 jours. Après cette période, Discourse tentera à nouveau d’envoyer des e-mails à l’utilisateur.
Si un e-mail n’est pas envoyé à un utilisateur ayant dépassé le bounce score threshold du site, une entrée sera ajoutée aux journaux Ignorés. La raison de l’ignorance sera définie sur « Dépassement du seuil de score de rebond ».
Merci. Donc, si je vois « Exceeded bounce_score_threshold » dans le journal des sauts pour un message récent envoyé à l’utilisateur X, je peux supposer qu’une action « révoquer l’e-mail » a été effectuée pour cet utilisateur auparavant, et inversement ?
Le contexte est le suivant : l’un de mes utilisateurs ne reçoit pas d’e-mails de notre instance Discourse. Il est très compétent, je fais donc confiance à ses déclarations selon lesquelles il a vérifié son dossier de courriers indésirables, etc. J’avais réinitialisé son score de rebond il y a quelque temps, mais je n’ai découvert l’entrée « Révoquer l’e-mail » dans son journal qu’aujourd’hui.
C’est intéressant. J’avais supposé que le score de rebond serait réinitialisé pour ceux dont les e-mails n’avaient pas encore été désactivés (comme le fait Mailman). Je suppose que la solution la plus proche consisterait à régler ce paramètre à environ 10 ans !
À ma connaissance, Discourse réinitialise toujours le score de rebond d’un utilisateur, puis tente de renvoyer les e-mails à cet utilisateur. La seule différence entre la gestion des rebonds temporaires et permanents est que les rebonds permanents augmentent le score de rebond d’une valeur par défaut de 2 (définie par le paramètre du site hard bounce score) au lieu d’une valeur par défaut de 1 (définie par le paramètre du site soft bounce score).
Cela fonctionnerait, mais pourrait avoir des conséquences imprévues. Par exemple, les utilisateurs qui ont dépassé le seuil de score de rebond en raison de la récente panne de Gmail devraient attendre 10 ans pour que leur score de rebond soit automatiquement réinitialisé.
Mailman 2 a des valeurs par défaut plus élevées pour les paramètres/seuils de rebond, mais une fois ce seuil atteint, vous êtes désabonné. Je comprends les arguments dans les deux sens. Édit : Je ne me souviens plus des détails, mais je pense qu’à un moment donné, on vous propose de répondre à un e-mail administratif, ce qui réinitialiserait votre score de rebond et vous maintiendrait sur la liste.
Beaucoup de personnes qui hébergent Discourse en auto-hébergement utilisent probablement Mailgun, qui conserve l’adresse e-mail sur sa liste de suppression après un seul « échec permanent » et ignorera donc l’approche plus tolérante de Discourse.
Il semblerait qu’il soit possible d’obtenir cette liste de suppression via l’API Mailgun, et je suppose qu’il pourrait également être possible de la synchroniser avec les paramètres de Discourse.
J’ai reçu un e-mail de Google aujourd’hui indiquant de manière sans équivoque que quelqu’un avait obtenu mon mot de passe — « Google a pris connaissance du fait qu’une autre personne connaît votre mot de passe » — je me demande donc si cela est lié à la « panne »…
Il s’agit de la suppression du paramètre bounce_score_threshold_deactivate. Je me demande si ce n’était pas une erreur. Si le paramètre par défaut était difficile à atteindre, la solution aurait été de le réduire.
Une conséquence imprévue de cette suppression pour un grand forum serait d’essayer d’envoyer des e-mails à un nombre croissant d’adresses invalides régulièrement sur plusieurs années. Cela pourrait soit causer des problèmes avec un service externe (comme Mailgun, qui bloque une adresse après un seul rebond de type permanent fail), soit nuire à la réputation de l’adresse IP.
Dans l’état actuel des choses, sauf si j’ai mal compris, Discourse pense envoyer des e-mails que Mailgun refuse simplement d’expédier en raison de sa liste de blocage, et il n’est pas possible de synchroniser l’approche de Discourse avec celle de Mailgun.
J’avais oublié cela. Je ne suis pas sûr que le paramètre bounce_score_threshold_deactivate ait fonctionné pour empêcher Discourse de tenter d’envoyer des e-mails à des adresses invalides. Le problème est que, une fois qu’un utilisateur atteint le seuil de score de rebond, Discourse cesse de lui envoyer des e-mails jusqu’à ce que la période définie par le paramètre réinitialiser le score de rebond après jours soit écoulée. À ce moment-là, le score de rebond de l’utilisateur est réinitialisé et le processus recommence.
Je ne sais pas quelle serait la meilleure solution pour cela. Si je comprends bien les choses, il semble qu’avec le temps, un site Discourse tentera d’envoyer des e-mails à un nombre croissant d’adresses invalides.
Il y a au moins deux facettes à cette question. L’une concerne la meilleure politique pour Discourse, en supposant que l’expéditeur des e-mails (par exemple localhost) accepte cette approche. L’autre concerne la synchronisation avec un service d’envoi d’e-mails qui ne s’y prêtera pas (par exemple Mailgun).
Je pense qu’il existe déjà un message dans Discourse du type : « Veuillez vérifier votre adresse e-mail, car nous avons rencontré des problèmes lors de l’envoi vers celle-ci. » Peut-être que Discourse doit adopter une approche plus agressive pour désactiver les e-mails rebondis, combinée à une notification de site non dismissible concernant l’absence d’envoi d’e-mails.
La synchronisation avec des expéditeurs externes serait plus complexe. Mailgun indique qu’il est possible de récupérer leur liste de suppression via leur API mais je ne sais pas encore s’il est également possible de supprimer des adresses via l’API. Si les deux opérations sont possibles, alors Discourse pourrait désactiver une adresse dès qu’elle entre dans la liste de suppression, et la retirer de cette liste lorsqu’une action manuelle est effectuée dans Discourse par l’administrateur ou l’utilisateur (par exemple, en répondant à un e-mail de confirmation). L’autre problème lié à cela est que chaque fournisseur a probablement des règles différentes.