J’essaie de comprendre comment faire en sorte que Discourse nettoie les listes d’e-mails, en particulier les e-mails rejetés. Le site utilise un serveur SMTP privé pour envoyer des e-mails, mais la réponse est configurée pour revenir à une adresse Gmail pour un accès POP par Discourse.
Je vois donc des e-mails rejetés dans le tableau de bord des e-mails reçus.
Discourse utilise la reply_key pour associer les rebonds aux e-mails envoyés. Lorsque Discourse envoie des e-mails, il utilise la valeur de reply_by_email_address comme expéditeur de l’enveloppe SMTP.
Vous devez vous assurer que votre reply_by_email_address inclut une {reply_key} afin que votre instance puisse associer les rebonds à l’e-mail envoyé correct.
Par exemple, ici sur meta, elle est définie sur incoming+%{reply_key}@meta.discoursemail.com et tout ce qui est envoyé à cette adresse est livré à cette instance.
Merci pour votre réponse. Malheureusement, j’ai dû désactiver la reply_key de la réponse par e-mail car notre serveur de relais d’e-mails ne reconnaît pas l’adressage avec +. Y a-t-il une autre option ?
Votre serveur de relais d’e-mails ne devrait pas avoir d’importance, seulement le serveur final où se trouve la boîte aux lettres. Les localparts d’e-mails sont opaques pour tous les serveurs intermédiaires.
N’est-ce pas Gmail, comme indiqué dans :
Je ne suis pas sûr que nous ayons un autre mécanisme pour détecter de manière fiable les rebonds.
Pour clarifier, le serveur de domaine SMTP de destination qui reçoit l’e-mail rejeté ne reconnaît pas l’adressage avec +, il ne transfère donc les e-mails que sur la base du champ To vers l’adresse gmail qui est récupérée par Discourse via POP. Si le champ To inclut la reply_key, il ne transférera pas cet e-mail au compte gmail utilisé par Discourse.
Je ne peux donc pas mettre la reply_key dans l’adresse e-mail, peut-elle être placée ailleurs ? Dans le champ objet ou le corps du message ou quelque part où Discourse pourrait l’analyser ?
Cela aiderait beaucoup si vous écriviez ce que vous utilisiez réellement pour les paramètres, même légèrement anonymisé.
Vous pourriez également envisager de définir alternative_reply_by_email_addresses.
Je ne crois pas.
Si possible, pour votre configuration, je recommanderais quelque chose comme :
définir reply_by_email_address sur inbound+%{reply_key}@forum.hostname
configurer un serveur de messagerie pour recevoir les e-mails pour forum.hostname et tout transférer vers the.gmail.account@gmail.com
Ici, le serveur de messagerie intermédiaire n’a pas besoin de comprendre l’adressage plus, il lui suffit de transférer tout ce qui concerne le domaine.
L’e-mail envoyé par Discourse provient de discourse@xxx.com via un serveur SMTP dédié configuré pour Discourse (en utilisant l’adresse du domaine Discourse).
Toute réponse ou tout retour d’e-mail est transféré par le serveur SMTP du domaine à discourse.xxxx@gmail.com. Ce serveur SMTP du domaine ne peut pas reconnaître l’adressage avec +, donc si j’inclus la reply_key dans l’adresse e-mail de réponse, elle sera rejetée par le serveur SMTP du domaine. Je ne peux définir que des règles pour transférer des adresses e-mail entrantes discrètes/uniques.
Le forum Discourse utilise ensuite POP via GMail pour accéder à ces réponses/e-mails retournés transférés et les analyse.
Je comprends ce que vous dites. Malheureusement, en raison d’une limitation des règles du serveur SMTP, je ne peux pas configurer de redirection pour les sous-domaines, je peux seulement le configurer pour rediriger des identifiants d’e-mail uniques dans le champ À.
Cependant, j’ai une clarification ici - plutôt une divergence dans la façon dont Discourse semble fonctionner :
Lorsqu’un utilisateur répond à un message par e-mail, il arrive correctement - les réponses semblent fonctionner parfaitement même sans qu’aucun {reply_key} ne soit explicitement configuré quelque part (voir les captures d’écran ci-dessus).
Cependant, lorsqu’un e-mail est rejeté, Discourse le classe sous Reçu plutôt que sous Rejeté.
Les journaux d’erreurs montrent que quelque chose dans Discourse reconnaît qu’il s’agit d’un e-mail rejeté (voir le journal d’erreurs de mon premier message). Donc, si quelque chose dans Discourse reconnaît qu’il s’agit d’un e-mail rejeté, pourquoi n’apparaît-il pas sous Rejeté au lieu de Reçu ?
Alors, pourquoi lorsqu’un utilisateur répond à un message, il est traité correctement par Discourse, mais pas un e-mail rejeté (et il semble également y avoir une déconnexion entre les journaux d’erreurs et le tableau de bord pour les e-mails rejetés). Est-ce que je manque quelque chose dans la configuration ?
J’ai également essayé de configurer les paramètres reply by email address dans Discourse sur discourse.xxx+%{reply_to}@gmail.com, mais lorsque l’e-mail est livré, Gmail semble penser que le domaine yyy.com (domaine SMTP de Discourse) essaie d’usurper le domaine Gmail et il finit par le marquer comme spam. Il semble que la définition d’un domaine de réponse différent du domaine de l’expéditeur déclenche un échec DMARC et SPF.
ARC-Authentication-Results: i=1; mx.google.com;
spf=softfail (google.com: domain of transitioning discussion.xxx+verp-b9c40db917ca04993dd3433cc9748518@gmail.com does not designate y.y.y.y as permitted sender) smtp.mailfrom=discussion.xxx+verp-b9c40db917ca04993dd3433cc9748518@gmail.com;
dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=yyy.com
Return-Path: <discussion.xxx+verp-b9c40db917ca04993dd3433cc9748518@gmail.com>
Vous avez désactivé find related posts with key (j’espère que vous avez lu l’avertissement), donc Discourse utilise l’en-tête d’email in-reply-to pour déterminer à quel sujet/message la réponse doit faire référence.
Il ne peut pas faire cela pour les rejets - Discourse doit connaître le message spécifique qui a été rejeté et cette information n’est garantie de se trouver qu’à un seul endroit - l’adresse To: (qui provient de l’adresse envelope-from du message original).
Pour que cela fonctionne, lorsque Discourse envoie un message, il doit recevoir la réponse à l’adresse d’où il provient. Discourse recherche cela dans l’en-tête To: (pas l’envelope-to).
usurpe le domaine gmail
Si vous voulez envoyer des e-mails depuis une adresse gmail, vous devez les envoyer via leurs serveurs. Mais ils n’aiment pas ça.
Il ne semble pas que vous ayez configuré DKIM pour yyy.com; vous devriez le faire. Si vous y parvenez, DMARC devrait passer.
Oui, c’est configuré et l’e-mail « envoyé » par Discourse via le serveur SMTP yyy.com passe SPF, DKIM et DMARC sans problème (du moins depuis la page « Envoyer un e-mail de test » dans la console d’administration).
Ce problème survient si je définis une adresse Gmail comme reply_by_email_address vers une adresse gmail.com au lieu de l’adresse yyy.com. Y a-t-il quelque chose que je puisse faire pour cette configuration afin que DMARC ne échoue pas lorsqu’il est défini sur reply_by_email_address vers une adresse Gmail tout en conservant le serveur sortant comme yyy.com ?
Ne peut-il pas analyser le reste du contenu/des pièces jointes dans l’e-mail renvoyé pour en extraire ces informations s’il ne trouve pas ce dont il a besoin à l’endroit « évident » (ou du moins fournir une option dans les paramètres pour le faire avec les avertissements nécessaires concernant l’usurpation d’identité)
L’alignement DMARC échoue car l’adresse reply_by_email_address est utilisée comme adresse envelope-from dans cette situation.
Pratiquement la seule chose garantie d’être intacte lors d’un rebond est l’adresse.
Peut-être le sujet, mais il ne serait pas pratique de mettre ces informations là.
Je vois que certains systèmes incluent le message original en pièce jointe… il est théoriquement possible que nous puissions vérifier les rebonds pour une pièce jointe afin d’obtenir plus d’informations si elles existent.
Si je comprends bien, l’reply_by_email_address devrait être défini dans le champ reply-to de l’enveloppe envoyée par Discourse (depuis yyy.com). Ainsi, lorsque l’utilisateur répond, il répond à l’e-mail reply-to (gmail.com) plutôt qu’à l’adresse d’origine (yyy.com). Donc, dans l’enveloppe de réponse de l’e-mail, l’adresse from devrait être l’adresse e-mail de l’utilisateur et le to l’adresse gmail.com.
Pourquoi l’reply_by_email_address serait-il utilisé comme adresse from ?
le reply_by_email_address n’est pas utilisé comme adresse d’expéditeur mais comme envelope-from, spécifiquement pour que les retours fonctionnent.
Voici une image qui montre comment chaque adresse est utilisée. Les adresses elles-mêmes sont spécifiques à notre hébergement, mais devraient suffire pour un exemple.
Donc, en gros, reply_by_email_address est utilisé dans l’en-tête from afin qu’il revienne à cette adresse e-mail en cas de rebond. Et la même adresse e-mail est également définie dans l’en-tête reply-to si les réponses par e-mail sont activées.
Donc, si ma compréhension ci-dessus est correcte, alors si Discourse peut avoir un paramètre distinct (reply_to_email) pour l’en-tête reply-to, cela résoudrait le problème de l’échec DMARC. Lors de l’utilisation du domaine yyy.com (tiré de reply_by_email_address) pour from lors de l’envoi et de gmail.com pour le reply-to (tiré d’un nouveau paramètre reply_to_email). Si l’e-mail rebondit, il sera toujours renvoyé à reply_by_email_address, mais si l’utilisateur répond, il ira à reply_to_email.
Pour réussir DMARC, soit SPF (qui valide l’envelope-from en combinaison avec l’IP d’envoi), soit DKIM (qui valide l’en-tête From et les sommes de contrôle du message) doivent s’aligner.
Il semble que le but de cet exercice soit d’avoir une adresse de réponse « jolie », à laquelle les utilisateurs répondent ?
Vous voulez quelque chose comme ça ?
envelope-from: outgoing+12309847801923840923502389423@yyy.com
…
From: notifications@yyy.com
To: user@contoso.com
Reply-to: my_sweet_forum+12309847801923840923502389423@gmail.com
Vous devez avoir cet envelope-from comme ceci, sinon les rebonds ne fonctionneront pas.
Oui, c’est exact. L’idée est d’avoir l’envelope-from différent du reply-to.
Comme le domaine envelope-from et l’adresse IP d’envoi correspondent, le SPF devrait passer, mais en même temps, la réponse peut aller à GMail pour traiter les réponses et si l’e-mail doit être rejeté, il retournera au serveur du domaine d’origine qui pourra alors renvoyer le rejet vers la boîte de réception GMail également.
Cela ressemblerait en fait à ceci :
envelope-from: outgoing@yyy.com
…
From: notifications@yyy.com
To: user@contoso.com
Reply-to: my_sweet_forum+12309847801923840923502389423@gmail.com
Dans ma configuration, l’envoi n’aura pas de VERP car mon SMTP entrant ne prend pas en charge le VERP (c’est-à-dire que le rejet ne contiendra pas d’adresse VERP), c’est pourquoi le reply-to est envoyé à GMail car il prend en charge le VERP. Cela ne devrait pas causer un échec DMARC comme c’est le cas actuellement.
