Opening a new feature request here, currently discourse only allows for a single email address which is used for both envelope-from and reply-to. If a site would like to use their own domain STMP for sending emails but wants the email replies to be sent to a different domain (e.g. gmail), then the sent emails will fail DMARC. By separating these two header fields it will avoid a DMARC failure and also not lose the ability to handle bounced emails.
More details on this topic
I don’t see how bounces will be handled in this scenario. Bounces go to the envelope from, not the address in the Reply-To. So if your envelope from isn’t capable of handling VERP-tagged email, you’ll still be in the soup.
In the topic you reference, you don’t explain why DKIM signing against the domain in the From: header doesn’t work. That should provide DMARC alignment, even if SPF fails. That is the approach I would take, if I were in your position (either that, or take to the admins of the yyy.com incoming SMTP server with a pitchfork; what kind of MTA doesn’t support any kind of detail addressing?!?)
It’ll work because the MTA supports catch all. While it doesn’t support VERP, it can be configured to forward all unspecified emails to a specific email, so the bounce replies won’t be lost.
Also, if we separate envelope-from and reply-to, envelope-from doesn’t need to contain a VERP address. It can be simple address like discourse@yyy.com. So when it bounces back it returns to discourse@yyy.com which won’t fail SPF.
The reply-to can have a different email which supports VERP like discourse-yyy+sdfkj33@gmail.com so if delivered successfully when the user replies it comes to the gmail server which supports VERP and it wont’ fail DMARC since the from is still yyy.com.
I agree but we don’t make 'em. Because they have catch-all addressing, they won’t support VERP. Unfortunately that the situation, I’m hoping that through a little tweak discourse will be able to support a more diverse ecosystem. A lot of smaller sites who’re using gmail to handle replies would be in this situation.
If your MTA supports a catch all, why can’t you forward replies with the same feature, and drop gmail altogether?
The envelope from is the address that has to support VERP, because the only way to reliably identify the cause of a bounce is via information in the original email’s envelope from address, as Michael previously explained.
I have my doubts about that assertion. Using a gmail address for replies is janky, and always has been janky; the mail-receiver is a much more straightforward, reliable, and low-jank way to handle replies (and bounces).
Even for those small sites using gmail, the really tiny ones are probably ignoring the ToS and using gmail to relay outbound as well, and the vast majority of the rest probably aren’t beholden to an MTA that doesn’t support detail addressing.
Because it’s a catch all for the domain, only one email is being used for discourse.
Not necessarily, I’m currently using it without VERP and it’s working. My issue is that I can’t have have the user respond directly to gmail without a SPF / DMARC failure due to the way discourse sets the envelope-from and reply-to addresses. Instead I have to have the MTA forward it to gmail. If I could have it reply directly to gmail (without a DMARC/SPF failure) then I can use VERP for securing the responses but yes the VERP will be ignored for bounced email. It’s still more secure than the current implementation.
That’ not an option as I explained here. It’s only practical to use gmail it for inbound. Setting up your own direct inbound MX when you already have a MX from your hosting provider can be challenging for the uninitiated. Direct gmail replies is far easier and less error prone.
Maybe I’m missing something in your line of thought. I can only see upsides to separating the envelope-from and reply-to addresses, it supports more diverse ecosystems and it’s more secure while helping to avoid SPF/MARC failures.
My line of thought is that the correct answer to your problem, as expressed so far, is to setup DKIM. Making the mail configuration even more complicated and prone to error is not warranted by your use case, IMO.
DKIM is already setup, the issue is SPF failing.
Adding an extra field to separate envelope-from and reply-to addresses will provide a lot of flexibility and enable SPF to pass as well (which it will not pass if one has SMTP server that forwards emails or doesn’t support VERP). The field can be hidden on the UI or even set to the match envelope-from and reply-to addresses unless the admins specifically decides to override. The description can point to this page. However I don’t see how it’ll make it more worse, it can ONLY get better - they’re either the same (in which case SPF will fail in any scenarios described here) or it’ll improve deliverability.