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

Question

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

到目前为止它工作得很好,但我想知道返回路径标题.

考虑这封电子邮件(为了隐私目的,我删除了不相关的标题并替换了电子邮件/域

Delivered-To: RECIEVER@gmail.com
Received: by 10.76.154.104 with SMTP id vn8csp478308oab;
        Wed, 4 Sep 2013 05:04:44 -0700 (PDT)
X-Received: by 10.50.22.105 with SMTP id c9mr1537992igf.36.1378296283817;
        Wed, 04 Sep 2013 05:04:43 -0700 (PDT)
Return-Path: <bounce+a801a1.c2b37-RECIEVER=gmail.com@my-website.com>
Received: from so254-63.mailgun.net (so254-63.mailgun.net. [198.61.254.63])
        by mx.google.com with ESMTP id k5si1620852igx.55.1969.12.31.16.00.00;
        Wed, 04 Sep 2013 05:04:43 -0700 (PDT)
Received-SPF: ...stripped...
Authentication-Results: ...stripped...
DKIM-Signature: ...stripped...
DomainKey-Signature: ...stripped...
Received: by luna.mailgun.net with HTTP; Wed, 04 Sep 2013 12:04:42 +0000
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>
X-Mailgun-Sid: WyI5YmI1OSIsICJqb2Vob3BmK2VlZ2VpN2lkMm9pbW9vYm9vZmFpQGdtYWlsLmNvbSIsICJjMmIzNyJd
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记录仍然指向其他地方的邮件服务器(在我的情况下是谷歌应用程序).

那么退回电子邮件到达邮件服务器服务器怎么可能呢？

我原本希望@some-mailgun-server.com在Return-Path标题中看到一个电子邮件地址!

我之前一直在使用Amazon SES,并且在那里有Return-Path标题结尾amazonses.com

我问邮件支持并得到了这个回复:

尼克:你的设置是正确的,即使你的mx记录指向其他地方,Mailgun仍然会自动处理反弹

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

所以我希望有人可以向我解释一下.

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

编辑:

我的一个理论是,退回邮件确实被发送到谷歌邮件服务器,在那里它被删除.但是这是多余的,因为错误响应也会在此过程中(当它打开到目标邮件服务器的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地址匹配,它可能会改善可传递性,这也是有意义的.

然而,这只是一个理论.并且这也意味着能够接收退回的邮箱必须位于用于发送的同一服务器上.

换句话说,没有邮箱可以接收托管电子邮件地址,这些地址是在发送邮件的实际服务器之外的其他地方托管的.但这听起来也很奇怪......

我希望有人能开导我.

Answer 1

事实证明,有不同种类的反弹.

当发生跳出时,它们通常会返回到发送电子邮件的服务器,而不会遵循MX记录.

这就是为什么他们被送到邮件服务器并到达那里.

然而,也有所谓的"延迟反弹"被发送到使用域中的MX记录声明为邮件服务器的服务器.

那些延迟反弹通常很难处理,并且有人认为他们违反了RFC.

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

事实上,当我在我的谷歌应用程序邮件上设置我的邮箱反弹时,我收到了一个这样的延迟反弹.

正是这封电子邮件使得正确的调试成为可能,从而导致了解这个问题.

总结一下:

是的,地址不正确.对于大多数跳出来说这没有问题,因为服务器不使用MX记录来发送它们,而是将它们直接发送到已启动连接的服务器.

但是,如果延迟反弹,有时也会发生反弹,反弹确实会转到返回路径地址中指定的域的mx记录后面的服务器.

这些电子邮件未被正确识别为mailgun服务器上的跳出.