# Séparer les adresses e-mail envelope-from et reply-to pour éviter les échecs DMARC
**URL:** https://meta.discourse.org/t/separate-envelope-from-and-reply-to-email-addresses-to-avoid-dmarc-failure/295211
**Category:** Feature
**Tags:** email
**Created:** [Février 13, 2024, 2:43 UTC](https://meta.discourse.org/t/separate-envelope-from-and-reply-to-email-addresses-to-avoid-dmarc-failure/295211 "2024-02-13T14:43:12Z")
**Posts on this page:** 7
**Page:** 1
### Author:  [@RBoy](https://meta.discourse.org/u/RBoy)
#### Post date: [Février 13, 2024, 2:43 UTC](https://meta.discourse.org/t/separate-envelope-from-and-reply-to-email-addresses-to-avoid-dmarc-failure/295211/1 "2024-02-13T14:43:12Z")
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.
Plus de détails sur ce sujet
> [@Bounced emails not being detected](https://meta.discourse.org/t/bounced-emails-not-being-detected/293518/19):
>
> Yes, that’s correct. The idea to have the envelope-from different from the reply-to. Since the envelope-from domain and the sending IP match, the SPF should pass but at the same time the reply can go to GMail to process responses and if the email should bounce it’ll head back to the original domain server which can then forward the bounce back to the GMail inbox as well. It would actually look like this: envelope-from: outgoing@yyy.com … From: notifications@yyy.com To: user@contoso.com Reply…
---
### Author:  [@mpalmer](https://meta.discourse.org/u/mpalmer)
#### Post date: [Février 14, 2024, 12:19 UTC](https://meta.discourse.org/t/separate-envelope-from-and-reply-to-email-addresses-to-avoid-dmarc-failure/295211/2 "2024-02-14T00:19:44Z")
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](http://yyy.com) avec une fourche ; quel type de MTA ne prend pas en charge une forme quelconque d’adressage détaillé ? ! ?)
---
### Author:  [@RBoy](https://meta.discourse.org/u/RBoy)
#### Post date: [Février 14, 2024, 5:03 UTC](https://meta.discourse.org/t/separate-envelope-from-and-reply-to-email-addresses-to-avoid-dmarc-failure/295211/3 "2024-02-14T17:03:40Z")
> [@mpalmer](#):
>
> Donc, si votre enveloppe d’envoi n’est pas capable de gérer les e-mails marqués VERP, vous serez toujours dans le pétrin.
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](mailto:discourse@yyy.com)_. Ainsi, lorsqu’il y a un rebond, il revient à _[discourse@yyy.com](mailto: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](mailto: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](https://serverfault.com/a/1047684/370699) puisque le `from` est toujours _[yyy.com](http://yyy.com)_.
> [@mpalmer](#):
>
> quel genre de MTA ne prend pas en charge une forme quelconque d’adressage détaillé
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.
---
### Author:  [@mpalmer](https://meta.discourse.org/u/mpalmer)
#### Post date: [Février 14, 2024, 10:03 UTC](https://meta.discourse.org/t/separate-envelope-from-and-reply-to-email-addresses-to-avoid-dmarc-failure/295211/4 "2024-02-14T22:03:54Z")
> [@RBoy](#):
>
> Cela fonctionnera car le MTA prend en charge le « catch all ». Bien qu’il ne prenne pas en charge le 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 soient pas perdues.
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 ?
> [@RBoy](#):
>
> 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](mailto:discourse@yyy.com)_. Ainsi, lorsqu’il y a un rebond, il revient à _[discourse@yyy.com](mailto:discourse@yyy.com)_, ce qui ne fera pas échouer SPF.
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](https://meta.discourse.org/t/bounced-emails-not-being-detected/293518/12?u=mpalmer).
> [@RBoy](#):
>
> Beaucoup de petits sites qui utilisent Gmail pour gérer les réponses seraient dans cette situation.
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](https://meta.discourse.org/t/configure-direct-delivery-incoming-email-for-self-hosted-sites/49487) 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é.
---
### Author:  [@RBoy](https://meta.discourse.org/u/RBoy)
#### Post date: [Février 16, 2024, 2:34 UTC](https://meta.discourse.org/t/separate-envelope-from-and-reply-to-email-addresses-to-avoid-dmarc-failure/295211/5 "2024-02-16T02:34:40Z")
> [@mpalmer](#):
>
> Si votre MTA prend en charge un catch-all, pourquoi ne pouvez-vous pas transférer les réponses avec la même fonctionnalité ?
Parce que c’est un catch-all pour le domaine, un seul e-mail est utilisé pour le discours.
> [@mpalmer](#):
>
> L’expéditeur de l’enveloppe est l’adresse qui _doit_ prendre en charge VERP,
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.
> [@mpalmer](#):
>
> en utilisant également Gmail pour relayer les sorties
Ce n’est pas une option car j’ai [expliqué ici](https://meta.discourse.org/t/setting-up-discourse-using-gmail-smtp-settings/291749/5?u=rboy). 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.
---
### Author:  [@mpalmer](https://meta.discourse.org/u/mpalmer)
#### Post date: [Février 16, 2024, 2:53 UTC](https://meta.discourse.org/t/separate-envelope-from-and-reply-to-email-addresses-to-avoid-dmarc-failure/295211/6 "2024-02-16T02:53:46Z")
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.
---
### Author:  [@RBoy](https://meta.discourse.org/u/RBoy)
#### Post date: [Mars 4, 2024, 6:45 UTC](https://meta.discourse.org/t/separate-envelope-from-and-reply-to-email-addresses-to-avoid-dmarc-failure/295211/7 "2024-03-04T18:45:00Z")
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é.