Ouverture d’une nouvelle demande de fonctionnalité ici, actuellement Discourse ne permet qu’une seule adresse e-mail qui est utilisée à la fois pour envelope-from et reply-to. Si un site souhaite utiliser son propre SMTP de domaine pour envoyer des e-mails mais souhaite que les réponses par e-mail soient envoyées à un domaine différent (par exemple, Gmail), les e-mails envoyés échoueront DMARC. En séparant ces deux champs d’en-tête, cela évitera un échec DMARC et ne perdra pas la capacité de gérer les e-mails rejetés.
Je ne vois pas comment les rejets seront gérés dans ce scénario. Les rejets vont à l’enveloppe d’origine, pas à l’adresse dans le Reply-To. Donc, si votre enveloppe d’origine n’est pas capable de gérer les e-mails balisés VERP, vous serez toujours dans le pétrin.
Dans le sujet auquel vous faites référence, vous n’expliquez pas pourquoi la signature DKIM par rapport au domaine dans l’en-tête From: ne fonctionne pas. Cela devrait fournir un alignement DMARC, même si SPF échoue. C’est l’approche que je prendrais, si j’étais à votre place (soit cela, soit aller voir les administrateurs du serveur SMTP entrant de yyy.com avec une fourche ; quel type de MTA ne prend pas en charge une forme quelconque d’adressage détaillé ? ! ?)
Cela fonctionnera car le MTA prend en charge le “catch all”. Bien qu’il ne prenne pas en charge VERP, il peut être configuré pour transférer tous les e-mails non spécifiés vers un e-mail spécifique, de sorte que les réponses de rebond ne seront pas perdues.
De plus, si nous séparons envelope-from et reply-to, envelope-from n’a pas besoin de contenir une adresse VERP. Il peut s’agir d’une simple adresse comme discourse@yyy.com. Ainsi, lorsqu’il y a un rebond, il revient à discourse@yyy.com qui ne fera pas échouer SPF.
Le reply-to peut avoir une adresse e-mail différente qui prend en charge VERP comme discourse-yyy+sdfkj33@gmail.com, donc si la livraison réussit, lorsque l’utilisateur répond, cela arrive au serveur gmail qui prend en charge VERP et cela ne fera pas échouer DMARC puisque le from est toujours yyy.com.
Je suis d’accord, mais nous ne les fabriquons pas. Parce qu’ils ont un “catch-all addressing”, ils ne prendront pas en charge VERP. Malheureusement, c’est la situation, j’espère qu’avec quelques ajustements, discourse sera capable de prendre en charge un écosystème plus diversifié. Beaucoup de petits sites qui utilisent gmail pour gérer les réponses se retrouveraient dans cette situation.
Si votre MTA prend en charge un « catch all », pourquoi ne pouvez-vous pas transférer les réponses avec la même fonctionnalité et abandonner complètement Gmail ?
L’adresse de l’enveloppe (envelope-from) est celle qui doit prendre en charge le VERP, car la seule façon d’identifier de manière fiable la cause d’un rebond est via les informations contenues dans l’adresse de l’enveloppe de l’e-mail d’origine, comme Michael l’a expliqué précédemment.
J’ai des doutes sur cette affirmation. L’utilisation d’une adresse Gmail pour les réponses est bancale, et l’a toujours été ; le récepteur de courrier est une méthode beaucoup plus simple, fiable et moins bancale pour gérer les réponses (et les rebonds).
Même pour les petits sites qui utilisent Gmail, les plus petits ignorent probablement les conditions d’utilisation et utilisent Gmail pour relayer également les e-mails sortants, et la grande majorité des autres ne sont probablement pas liés à un MTA qui ne prend pas en charge l’adressage détaillé.
Parce que c’est un catch-all pour le domaine, un seul e-mail est utilisé pour le discours.
Pas nécessairement, je l’utilise actuellement sans VERP et cela fonctionne. Mon problème est que je ne peux pas faire en sorte que l’utilisateur réponde directement à Gmail sans échec SPF / DMARC en raison de la façon dont Discourse définit les adresses envelope-from et reply-to. Au lieu de cela, je dois faire en sorte que le MTA le transfère à Gmail. Si je pouvais faire en sorte qu’il réponde directement à Gmail (sans échec DMARC/SPF), alors je pourrais utiliser VERP pour sécuriser les réponses, mais oui, VERP sera ignoré pour les e-mails rejetés. C’est toujours plus sûr que l’implémentation actuelle.
Ce n’est pas une option car j’ai expliqué ici. Il n’est pratique d’utiliser Gmail que pour les entrées. La configuration de votre propre MX d’entrée directe alors que vous avez déjà un MX de votre fournisseur d’hébergement peut être difficile pour les non-initiés. Les réponses directes de Gmail sont beaucoup plus faciles et moins sujettes aux erreurs.
Peut-être que je manque quelque chose dans votre raisonnement. Je ne vois que des avantages à séparer les adresses envelope-from et reply-to, cela prend en charge des écosystèmes plus diversifiés et c’est plus sûr tout en aidant à éviter les échecs SPF/MARC.
Mon raisonnement est que la réponse correcte à votre problème, telle qu’exprimée jusqu’à présent, est de configurer DKIM. Rendre la configuration de messagerie encore plus compliquée et sujette aux erreurs n’est pas justifié par votre cas d’utilisation, à mon avis.
DKIM est déjà configuré, le problème est que SPF échoue.
L’ajout d’un champ supplémentaire pour séparer les adresses envelope-from et reply-to apportera beaucoup de flexibilité et permettra également à SPF de passer (ce qui ne passera pas si l’on a un serveur SMTP qui transfère les e-mails ou ne prend pas en charge VERP). Le champ peut être masqué dans l’interface utilisateur ou même défini pour correspondre aux adresses envelope-from et reply-to à moins que les administrateurs ne décident spécifiquement de le remplacer. La description peut renvoyer vers cette page. Cependant, je ne vois pas comment cela pourrait empirer les choses, cela ne peut qu’améliorer la situation : soit elles sont identiques (auquel cas SPF échouera dans tous les scénarios décrits ici), soit cela améliorera la délivrabilité.