Return-Path 标头与实际的电子邮件退回收件人有何不同？

Posted 2023-03-14

技术标签:

【中文标题】Return-Path 标头与实际的电子邮件退回收件人有何不同？【英文标题】：How can the Return-Path header be different than the actual email bounce recipient? 【发布时间】：2013-09-08 01:01:16 【问题描述】：

我最近将我的交易电子邮件发送到Mailgun

到目前为止效果很好，但是我想知道返回路径标头。

考虑这封电子邮件（出于隐私目的，我删除了不相关的标题并替换了电子邮件/域）

Received-SPF: ...stripped...
DomainKey-Signature: ...stripped...
Mime-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Subject: ...stripped...
From: my-website <support@my-website.com>
To: RECIEVER@gmail.com
Message-Id: <20130904120442.1488.88532@my-website.com>
Date: Wed, 04 Sep 2013 12:04:43 +0000
Sender: support@my-website.com
Content-Transfer-Encoding: base64

...email body...

这是从 gmail 收件箱中的实际邮件中显示的原始电子邮件。如您所见，Return-Path 标头包含一个以 @my-website.com 结尾的电子邮件地址

但我只为外发电子邮件（spf、domainkey 等）设置了 dns 记录。不适用于传入的电子邮件。这意味着，我的 MX 记录仍然指向其他地方的邮件服务器（在我的情况下是谷歌应用程序）。

那么退回邮件怎么可能到达 mailgun 服务器？

我本来希望在Return-Path 标头中看到以@some-mailgun-server.com 结尾的电子邮件地址！

我之前一直在使用 Amazon SES，他们的 Return-Path 标头以 amazonses.com 结尾

我询问了 mailgun 支持并得到了以下回复：

Nick：你的设置是正确的，Mailgun 仍然会自动处理即使您的 mx 记录指向其他地方，也会出现反弹

他们只是向我保证一切都很好，但没有给我任何解释（这没关系，因为他们的工作不是教我不知道的东西，而是提供可靠的电子邮件服务......）

所以我希望有人能给我解释一下。

我希望这一点很清楚，如果没有，请询问，我会尽力澄清我的问题。

编辑：

我的一个理论是，退回的电子邮件确实被发送到谷歌邮件服务器并被丢弃。但是，这是多余的，因为在此过程中（当它打开与目标邮件服务器的 tcp 连接时）错误响应也会发送到发送邮件服务器。

为了测试这个理论，并且由于 Return-Path 电子邮件采用bounce+SOMETHING@my-website.com 的形式，并且无论+ 字符后面的内容如何，谷歌都会将所有电子邮件发送给它前面的用户，我去了提前并在谷歌应用程序上创建了帐户bounce@my-domain.com。

我也尝试发送电子邮件至bounce+a801a1.c2b37-RECIEVER=gmail.com@my-website.com。

它进入了我的收件箱。

现在我希望在我的收件箱中收到退回流量。所以我向一个不存在的 hotmail 地址发送了一封电子邮件。我的谷歌应用收件箱没有收到电子邮件，mailgun 成功跟踪了退回邮件。

所以...看来它确实有效。我只是不明白为什么。

我的另一个理论是，退回电子邮件所发送到的邮件服务器永远不会使用其 MX 记录来解析。而是始终选择交付服务器，在这种情况下选择luna.mailgun.net。以Return-Path地址结尾的域只是服务器上邮箱的名称，但域与邮件实际投递的服务器无关。

那么这样做也很有意义，因为如果From 和Return-Path 地址的域匹配，它可能会提高交付能力。

但这只是一个理论。这也意味着能够接收退回邮件的邮箱必须位于用于发送的同一台服务器上。

换句话说，除了发送邮件的实际服务器之外，不可能有一个邮箱来接收托管在其他地方的退回电子邮件地址。但这听起来对我来说也很奇怪......

希望有人能赐教。

【问题讨论】：

关于这个问题的近距离投票，原因是：This question does not appear to be about programming within the scope defined in the help center. -- 请详细说明。恕我直言，这个问题是关于正确实现 RFC 2821、3834 和 4409 中定义的协议。如果没有实际的源代码，它还能获得多少编程？我的猜测是弹跳服务器错误地使用了from 地址。您有退回电子邮件的原始标题吗？嘿@pekka，我终于发现了这一切背后的原因。您的假设是有效的，但事实证明情况有所不同。我会马上写下这个问题的答案。 【参考方案1】：

原来有不同类型的反弹。

当出现退回邮件时，它们通常会返回到发送电子邮件的服务器，并且不遵循 MX 记录。

这就是它们被发送到 mailgun 服务器并到达那里的原因。

但是，也有所谓的“延迟退回”，它们使用域中的 MX 记录发送到声明为邮件服务器的服务器。

这些延迟的退回通常很难处理，并且有意见认为它们违反了 RFC。

然而，这些反弹非常非常罕见。这就是mailgun不处理它们的原因。他们在返回路径地址中使用客户域的原因是他们可以将其分配给正确的帐户。他们只是这样编码......

事实上，当我在我的谷歌应用邮件上设置我的邮箱以进行退回时，我收到了一封这样的延迟退回邮件。

正是这封电子邮件使正确的调试成为可能，从而导致了对这个问题的理解。

总结一下：

是的，地址不正确。这对于大多数退回邮件来说都没有问题，因为服务器不使用 MX 记录来发送它们，而是将它们直接发送到已启动连接的服务器。

但是在延迟反弹的情况下，有时也会发生这种情况，反弹确实会转到返回路径地址中指定的域的 mx 记录后面的服务器。

这些电子邮件在 mailgun 服务器上未被正确识别为退回邮件。