在此开启一个新的功能请求，目前 Discourse 只允许使用单个电子邮件地址，该地址同时用于 envelope-from 和 reply-to。如果一个站点希望使用自己的域 SMTP 发送电子邮件，但希望电子邮件回复发送到另一个域（例如 Gmail），那么发送的电子邮件将因 DMARC 失败。通过分离这两个标头字段，可以避免 DMARC 失败，也不会丢失处理退回邮件的能力。
关于此主题的更多详细信息：
在此场景中，我不知道如何处理退信。退信会发送到 envelope from，而不是 Reply-To 中的地址。因此，如果您的 envelope from 无法处理 VERP 标记的电子邮件，您仍然会遇到麻烦。
在您引用的主题中，您没有解释为什么针对 From: 标头中的域进行 DKIM 签名不起作用。即使 SPF 失败，这也应该提供 DMARC 对齐。如果我处于您的位置，我会采取这种方法（要么是这样，要么是拿着干草叉去找 yyy.com 入站 SMTP 服务器的管理员；什么样的 MTA 不支持任何形式的详细寻址？！）。
它会起作用，因为 MTA 支持通配符地址。虽然它不支持 VERP，但可以配置为将所有未指定的电子邮件转发到特定邮箱，这样退信回复就不会丢失。
另外，如果我们区分 envelope-from 和 reply-to，envelope-from 就不需要包含 VERP 地址。它可以是一个简单的地址，如 discourse@yyy.com。这样当它退回时，会返回到 discourse@yyy.com，这不会导致 SPF 失败。
reply-to 可以有一个不同的邮箱，支持 VERP，如 discourse-yyy+sdfkj33@gmail.com，这样如果成功送达，当用户回复时，会发送到支持 VERP 的 gmail 服务器，并且不会因为 from 仍然是 yyy.com 而导致 DMARC 失败。
我同意，但我们不生产它们。因为它们支持通配符地址，所以它们不支持 VERP。不幸的是，情况就是这样，我希望通过一些小调整，discourse 能够支持更多样化的生态系统。很多使用 gmail 处理回复的小型网站都会遇到这种情况。
如果您的 MTA 支持通配符，为什么不能使用相同的功能转发回复，而完全放弃 Gmail？
envelope from 是必须支持 VERP 的地址，因为可靠识别退信原因的唯一方法是通过原始电子邮件 envelope from 地址中的信息，正如 Michael 之前解释的那样。
我对这个说法表示怀疑。使用 Gmail 地址进行回复一直都很麻烦；邮件接收器 是处理回复（和退信）的一种更直接、更可靠、更少麻烦的方式。
即使对于那些使用 Gmail 的小型网站，真正非常小的网站可能正在违反服务条款，并且也使用 Gmail 来中继出站邮件，而绝大多数其他网站可能并不依赖不支持详细寻址的 MTA。
1 个赞
因为它是域的“全部接收”，只有一个电子邮件用于 Discourse。
不一定，我目前在没有 VERP 的情况下使用它，并且它运行正常。我的问题是，由于 Discourse 设置 envelope-from 和 reply-to 地址的方式，我无法让用户直接回复 Gmail 而出现 SPF / DMARC 失败。我必须让 MTA 将其转发到 Gmail。如果我能让它直接回复 Gmail（没有 DMARC/SPF 失败），那么我就可以使用 VERP 来保护回复，但是的，VERP 将被忽略用于退回的电子邮件。它仍然比当前的实现更安全。
正如我在此处解释的那样，这不是一个选项。仅在实际情况中使用 Gmail 进行入站邮件。当您已经有来自托管提供商的 MX 时，设置自己的直接入站 MX 对于新手来说可能很困难。直接 Gmail 回复要容易得多，也不容易出错。
也许我遗漏了您想法中的某些内容。我只能看到分离 envelope-from 和 reply-to 地址的优点，它支持更多样化的生态系统，并且更安全，同时有助于避免 SPF/MARC 失败。
我的想法是，到目前为止，您问题的正确答案是设置 DKIM。IMO，根据您的用例，使邮件配置更加复杂且容易出错是不必要的。
DKIM 已设置好，问题在于 SPF 验证失败。
添加一个额外的字段来区分 envelope-from 和 reply-to 地址将提供极大的灵活性，并使 SPF 验证也能通过（如果 SMTP 服务器转发邮件或不支持 VERP，SPF 将无法通过）。该字段可以在 UI 中隐藏，或者设置为匹配 envelope-from 和 reply-to 地址，除非管理员明确决定覆盖。描述可以指向此页面。然而，我看不出它会变得更糟，它只会变得更好——它们要么相同（在这种情况下，SPF 将在此处描述的任何场景中失败），要么它将提高邮件送达率。